Why docker system df doesn't explain your full disk, and why prune frees less than it says

Description and use

Docker’s built‑in disk usage commands omit container logs, shared build cache, and image layer overlaps, causing underestimation of disk usage and ineffective pruning. By manually inspecting logs, build cache, and image layers, and using tools like dockdu, users can accurately measure and reclaim disk space.

Problem

docker system df reports disk usage that does not account for container logs, shared build cache, overlapping image layers, or Docker Desktop sparse files, leading to misleading disk usage and ineffective pruning.

Outcome

Docker’s built‑in disk usage commands omit container logs, shared build cache, and image layer overlaps, causing underestimation of disk usage and ineffective pruning. By manually inspecting logs, build cache, and image layers, and using tools like dockdu, users can accurately measure and reclaim disk space.

Workflow

• Identify missing log files: run du -ch /var/lib/docker/containers/*/*-json.log to see log size.
• Check build cache: run docker buildx du --verbose and compare with docker builder prune -af output.
• Inspect image size overlap: use docker image ls and docker system df -v to see shared vs unique sizes.
• On macOS, examine Docker.raw with ls -ks and run docker run --rm -v /var/lib/docker:/var/lib/docker:ro alpine du … to access VM logs.
• Compare filesystem allocation: run df -h /var/lib/docker and sudo du -sxh /var/lib/docker to see actual blocks.
• Use dockdu for a single‑command summary of all checks.

Evidence

docker system df has four rows (Images, Containers, Local Volumes, Build Cache), and log files are in none of them.

Source

Measured: one container wrote 500 MiB to stdout.

Source

docker system prune does not touch them: in the same setup it reclaimed 0B, because the containers were running.

Source

BuildKit marks a cache record Shared when its data is also part of an image.

Source

On overlay2, expect docker builder prune to free roughly the private part only.

Source

On the containerd image store, expect somewhere between the private part and the printed total.

Source

docker image ls shows each image's full size. Two images built FROM the same base each include that base, so adding up image sizes counts the base more than once.

Source

On macOS, all of Docker lives in one VM disk file.

Source