You pull one image, run it for an afternoon, and four months later your Mac is out of space even though docker ps shows nothing running. The culprit is Docker.raw — the file Docker Desktop uses as its virtual hard disk.
It only ever grows, and nothing you do with docker rmi shrinks the file. Here's the actual mechanism and the safe ways to reclaim the gigabytes.
What Docker.raw is
Docker Desktop on Apple Silicon runs Linux VMs inside a single dynamic disk file. Every image, container, volume, and build layer you've ever had is stored in that one file:
-
~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw(Apple Silicon) - Inside Docker Desktop's
Data/vms/0/data/directory (x86, usually.rawtoo)
Docker.raw is a sparse/dynamic disk: it grows when you use space, but by design it doesn't reclaim space when you delete a container. The freed blocks stay reserved inside the file. So even after docker system prune -af, your disk is still full — Docker thinks you're fine because inside its VM the space is free.
Confirm it's your problem
du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
docker system df shows the VM image's size, but du on the .raw file shows the actual on-disk footprint. If Docker.raw is 40 GB while docker image ls is 3 GB — that's the black hole.
The safe shrink (no data loss, Docker-way)
1. Prune what's actually cruft
docker system prune -af
docker builder prune -af
docker volume prune -f
This frees space inside the VM. The .raw file still won't shrink yet.
2. Reclaim the file (the part people miss)
In Docker Desktop settings there's the manual lever: Docker Desktop → Settings → Resources → Advanced → Disk image size.
Option A — resize/recreate the VM (effective): change the Disk image size to a smaller value → Apply & Restart. Docker recreates Docker.raw at the new size (often shrinking the file). Or remove the file while Docker is fully quit and let Docker recreate it empty — but that destroys your images, containers, and volumes.
Option B — the direct one-liner for the brave: quit Docker fully, then:
# only if Docker Desktop is QUIT, and you accept images/volumes are recreated
rm -f ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
Again: this deletes the VM contents. Re-pulling images rebuilds the file.
3. Do not fall for "docker system prune" alone
docker system prune -af frees space inside the VM. It doesn't shrink Docker.raw. The file only shrinks via the disk-image-size control, or by recreating the VM. Layering these two is what actually returns gigabytes to your Mac.
Prevent it next time
- Set a hard disk-image cap in Docker Desktop settings that's smaller than "maximum".
-
Prune regularly:
docker system prune -af && docker builder prune -afweekly-ish. -
Remove big unused images:
docker images→ untagged ones (<none>) hold the most. - Remember Homebrew isn't the only thing that grows — DerivedData and node_modules grow too.
See it on the map first
The most satisfying way to fix a silent 40 GB before it becomes an "out of space" crisis: see your disk as folders, sorted by bytes. DiskInsight renders that — every folder, every cache, hidden or not — so Docker.raw shows up as a giant block you can click and inspect before touching anything. Everything is staged to the Trash for your review; nothing is deleted behind your back. 100% local, no telemetry.
Bottom line
Docker.raw is a dynamic disk that grows and never shrinks by itself. docker system prune frees space inside it. To actually get gigabytes back on your Mac:
docker system prune -af && docker builder prune -af- Reduce Disk image size in Docker Desktop settings (or recreate the VM if you accept images are gone).
- Keep the cap low so it stops re-bloating.
DiskInsight is a local macOS disk analyzer with nine visualizers; scanning is free forever, and a one-time Pro unlock adds duplicate cleanup, a dev cache cleaner (Xcode, npm, CocoaPods, Gradle) and a full app uninstaller. Nothing is uploaded, no account, no telemetry.
More: https://diskinsight.com
Top comments (0)