Docker.raw grew to 60 GB and pruning did nothing

On this page

1. Where the file is
2. Why pruning does not shrink it
3. Three ways to get the space back
4. Finding out what is actually inside before you delete
5. A note on the alternatives

Where the file is

Docker Desktop, on Apple silicon and Intel alike:

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

Older installations may use Docker.qcow2 in the same directory, and a VirtioFS or virtiofs-based setup may name it differently. Whatever it is called, one file is the whole store:

du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/*

Never delete this file to reclaim space unless you intend to lose every image, container and volume on the machine. It is not a cache. Named volumes holding database data live inside it, and nothing outside it holds a copy.

Why pruning does not shrink it

The file is sparse, and the growth is one-directional by design:

1. You pull an image. The virtual machine writes layers to its ext4 file system inside Docker.raw, and the host file grows to accommodate them.
2. You delete the image. The Linux file system inside marks those blocks free. The host file does not change size, because as far as macOS is concerned the bytes are still allocated to the file.
3. You pull a new image. Docker reuses the free blocks inside, so the host file stays the same size — which is why the problem looks like it has stopped and then resumes months later after a big pull.

The space is genuinely reusable by Docker. It is simply not returned to macOS until something explicitly punches holes in the file, which is what the methods below do.

Three ways to get the space back

One: prune first, then let Docker compact. Always the first step, and on recent Docker Desktop versions often the only one needed, because it runs fstrim inside the virtual machine after a prune and macOS reclaims the holes.

docker system df                 # see what is actually using the space
docker system prune -a --volumes # careful: -a and --volumes are the destructive flags

Read what each prune flag actually deletes before running that line. -a removes every image not used by a running container, and --volumes removes named volumes not attached to a container, which is where a local database ends up.

Then quit Docker Desktop completely and reopen it. The compaction runs at shutdown; if you only close the window, nothing happens.

Two: ask Docker Desktop to do it. Settings, then Resources, then Advanced. There is a disk image size slider and, on current versions, a button that rebuilds the file at its current used size. This is the supported route and it is slower but safe.

Three: rebuild the file. Settings, then Troubleshoot, then “Clean / Purge data”. This deletes the disk image and recreates it empty. It returns every byte, and it removes everything you have. Back up named volumes first:

docker run --rm -v mydata:/from -v "$PWD":/to alpine \
  tar czf /to/mydata.tgz -C /from .

Finding out what is actually inside before you delete

docker system df gives the summary. The verbose form gives the itemised list, which is what you want when one thing is 40 GB and everything else is noise:

docker system df -v

Three items dominate on a working machine. Images, usually the largest and mostly duplicated base layers. The build cache, which BuildKit keeps indefinitely and which is covered in the BuildKit build cache and how to bound it. And volumes — see orphaned volumes are where the data actually is, because those are the ones a careless --volumes prune destroys.

A note on the alternatives

If this behaviour is a recurring annoyance, the storage model is the thing to change rather than the cleanup routine. Colima and OrbStack both use a different disk strategy, and OrbStack in particular returns space to macOS as containers are removed rather than at shutdown. How Docker Desktop, Colima and OrbStack differ on disk compares them on exactly this point.