Where Are Docker's Files on a Mac? (Inspecting the Virtual Disk Image)

On Linux, Docker stores its images, containers, and volumes at /var/lib/docker/, and you can cd into it like any other directory. On macOS, you can't. Docker Desktop runs Linux in a VM, and everything Docker has — every image layer, every named volume, every container's writable layer, every byte of build cache — lives inside a single virtual disk image on your Mac filesystem. There is no /var/lib/docker on your Mac.

This causes confusion in three places: people can't find their volume data on disk, docker system prune doesn't seem to free Mac disk space, and tutorials written for Linux don't translate. Here's the actual story.

Where the virtual disk lives

Docker Desktop on macOS stores its VM disk image under your user's Library:

~/Library/Containers/com.docker.docker/Data/vms/0/data/

Files you'll see in there have evolved across Docker Desktop versions:

• Docker.raw — older virtio block driver format (qcow-style raw disk).
• Docker.qcow2 — even older (pre-VirtioFS).
• ext4.tar.lz4 + vms/0/data/Docker.raw — VirtioFS era. The Linux VM mounts a filesystem packaged differently from old releases.

The exact filename and format don't matter day-to-day. What matters: it's one (large) file, and it grows over time as you pull images and create volumes.

du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/
# 24G    /Users/you/Library/Containers/com.docker.docker/Data/vms/0/data/

That's where your 24 GB of Docker went.

Why docker system prune doesn't free Mac disk space

docker system prune runs inside the VM. It frees space inside Docker's filesystem. But the wrapper virtual disk image on your Mac doesn't shrink automatically — it stays the size it was at peak usage.

So after a prune, you might see:

docker system df
# TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
# Images          5         5         3.2GB     0B (0%)

Inside the VM: 3.2 GB used. Plenty of free space inside.

du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/
# 24G

On Mac: still 24 GB on disk. The wrapper file is sparse internally but the file itself wasn't compacted.

To reclaim Mac disk space, you have to either compact the disk image or shrink Docker Desktop's max disk size.

Fix: compact the virtual disk

Docker Desktop → Settings → Resources → Advanced → Disk image size has a slider. Drag it smaller than the current usage, click Apply & Restart, and Docker Desktop compacts the virtual disk to roughly the new size. Then you can drag it back up if you want headroom for future use.

Sequence:

1. docker system prune -a first (frees space inside the VM so it can actually shrink).
2. Docker Desktop → Settings → Resources → Advanced.
3. Drag "Disk image size" slider down to something close to your current actual usage from docker system df.
4. Apply & Restart. Wait — compaction takes 1-5 minutes.
5. Drag the slider back up to your preferred max if needed.

Your Mac disk gets the space back.

Fix: nuke and start fresh

Docker Desktop → Troubleshoot → Clean / Purge data wipes everything Docker has stored and creates a fresh virtual disk. All images, volumes, containers, build cache — gone. Sometimes that's exactly what you want; sometimes it's not.

Inspecting what's inside the VM

You can't cd to volumes from your Mac terminal, but you can shell into the Docker VM:

docker run -it --rm --privileged --pid=host alpine nsenter -t 1 -m -u -i -n sh

That breaks out of any container's namespaces and gives you a shell on the VM itself. From there:

ls /var/lib/docker/
# buildkit/   containers/   image/   network/   overlay2/   plugins/   runtimes/   swarm/   tmp/   volumes/

ls /var/lib/docker/volumes/
# my-named-volume/   another-volume/

ls /var/lib/docker/volumes/my-named-volume/_data/
# (the contents of your named volume)

That's the Linux view. Useful when something's broken at a level below Docker's API.

exit to leave the VM shell.

(Same trick on Windows for the Docker VM there; the syntax is the same.)

Volumes specifically: where are their bytes?

Inside the VM at /var/lib/docker/volumes/<volume-name>/_data/. From your Mac, you can't directly access them. The two ways to get at them:

Through a temporary container:

docker run --rm -it -v my-volume:/data alpine sh
# ls /data

Via the VM shell as shown above.

For backup or migration, the recommended path is a tar via a throwaway container:

docker run --rm -v my-volume:/source:ro -v "$(pwd):/backup" alpine \
  tar czf /backup/my-volume.tar.gz -C /source .

That copies the volume contents into a tarball on your Mac. Restore the reverse direction with the same shape.

Windows is similar

On Windows with WSL2-backed Docker Desktop, Docker's storage lives inside the WSL2 distro that Docker Desktop manages. The file:

%LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx

Same idea: a single virtual hard disk file. Same du/docker system df mismatch problem. Same fix in Docker Desktop's settings.

What stays on the Mac filesystem (vs inside the VM)

Bind mounts are the exception — those are direct mappings to host paths.

Common pitfalls

• Looking for /var/lib/docker on macOS. Doesn't exist. Use the VM shell trick above.
• docker system prune doesn't free Mac disk space. Right — it frees VM disk space. Compact the virtual disk in Docker Desktop's Settings → Resources → Advanced.
• Disk image grows but never shrinks. That's the default behavior. Manual compaction is the fix.
• Deleting the virtual disk file directly. Don't. Use Docker Desktop's Clean / Purge if you really want to nuke it; deleting the file behind Docker Desktop's back can corrupt its state.

What to do next

• docker system prune: Free Disk Space — the prune side of disk management.
• Why Bind Mounts Are Slow on Mac and Windows — the related performance story driven by the same VM design.
• Docker Volumes vs Bind Mounts — the volume storage story.

FAQ