Docker.raw is huge on a Mac, and how much of it is real
· 6 min read
Docker.raw is a virtual disk: a single file that holds the entire Linux virtual machine where your images, containers and volumes live. Finder and ls usually report the size that disk is allowed to grow to, not the space it currently occupies on your Mac. The real number comes from du, and it is often a fraction of the alarming one.
The second thing to know is that the file only ever grows on its own. Deleting images inside the virtual machine frees space inside the virtual disk, but getting that space back to macOS takes a deliberate step.
Find the file
Its location has moved between versions, so search rather than guess:
find ~/Library/Containers/com.docker.docker -name "Docker.raw" 2>/dev/null
On current installations it typically sits at ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw. If nothing comes back, you may be running a different container runtime, in which case the equivalent file lives under that tool’s own support folder and everything below still applies in principle.
Apparent size versus real size
Run both of these against the path you found:
ls -lh "$HOME/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw"
du -h "$HOME/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw"
ls prints the logical size, the size the file claims to be. du prints what is actually allocated on disk. On APFS the file is sparse, meaning blocks that were never written take no space, so a virtual disk with a 64 GB ceiling and 9 GB of images written to it reports 64 GB to ls and 9 GB to du. Finder’s Get Info window shows the logical figure, which is why the panic usually starts there.
If you want both numbers side by side:
stat -f "logical: %z bytes allocated blocks: %b" <path>
Blocks are 512 bytes each, so multiply by 512 to compare.
The number that matters for a full disk is the du figure. If du is small, there is nothing to fix and the file is behaving correctly. If du is genuinely large, read on.
See what is actually inside
With Docker running:
docker system df
docker system df -v
The first gives you a summary across images, containers, local volumes and build cache. The second itemizes it. Build cache is very often the largest line and the one people forget exists, because it is invisible in every list of images.
Volumes deserve a second look before you touch them. A named volume is where a container’s database usually lives, and it is the one category here that is not disposable.
Reclaim space inside the virtual disk
Work from least to most destructive:
docker builder prune # build cache only
docker container prune # stopped containers
docker image prune -a # images with no container using them
docker volume prune # unused volumes: read the warning above
docker system prune -a --volumes does all four at once. It is fine on a machine where you can re-pull everything and nothing local matters, and it is a bad afternoon on a machine where a project’s database lived in a volume you had forgotten about.
After a prune, run du again. On recent versions of Docker Desktop the freed blocks are returned to macOS automatically, sometimes after a short delay or a restart of the virtual machine. On older versions they are not: the space is free inside the virtual disk, ready to be reused by the next image you pull, but the host file stays at its high-water mark forever.
Forcing the host file to shrink
If du is still large after pruning, there are two honest options and both destroy the contents.
The supported one is in Docker Desktop itself. Its settings include a Resources section with the virtual disk’s size and location, and a troubleshooting screen with a purge or reset option. The exact wording moves between versions, so look in both places. Purging deletes every image, container and volume and recreates the disk file at its minimum size.
The blunt one: quit Docker Desktop completely, delete Docker.raw, and start it again. It creates a fresh disk. Same outcome, same loss, no dialog to confirm you meant it.
Either way, budget for re-pulling your base images afterwards, which is bandwidth rather than work.
Lowering the disk size limit in settings is worth doing if you have set it high, because it caps the high-water mark that can develop later. Depending on the version, applying a smaller limit may itself require recreating the disk, so treat it as the same operation.
Backups and the same trap elsewhere
A multi-gigabyte file that changes every day is an awkward thing for Time Machine. Some versions of Docker Desktop mark it as excluded already; you can confirm and add your own exclusion in System Settings, General, Time Machine, Options, using the plus button to add the containers folder. Excluding it costs you nothing you would want to restore, since the contents are rebuilt from registries and Dockerfiles anyway.
Virtual machines of any kind behave the same way: a disk image file that grows, never shrinks, and reports a reserved size rather than a used one. If your Mac’s storage numbers still do not add up after checking this one, the other usual suspects are developer build folders and old device backups. Xcode is eating the disk covers the first, and old iPhone backups the second.
If you would rather not run any of this by hand, an auditing tool such as Crumb reports Docker.raw real versus apparent size as one line of a read-only whole-Mac audit, which at least settles the question of whether the file is your problem before you start pruning.
Questions
Is it safe to just delete Docker.raw? Technically yes, with Docker quit. It is the entire virtual machine disk, so you lose every image, container and volume on that machine, and anything a container wrote that was not committed or bind-mounted to a folder on your Mac. Code in a bind-mounted directory is on the Mac’s own disk and is unaffected.
Why does the Storage pane not show Docker separately? macOS categorizes by location and type, not by which developer tool created something. A container runtime’s virtual disk generally lands in Applications or System Data depending on where it was installed. That is one of the reasons the Storage pane’s categories rarely explain a full disk on a developer’s machine.
Does a prune inside a container tool free space on the Mac?
It frees space inside the virtual disk immediately, and on the Mac only if your version passes the discarded blocks back to the host file. Check with du before and after: it is the only reliable answer, and it differs by version and by which virtualization backend is in use.
Do bind mounts count toward the file’s size? No. A bind-mounted folder stays on the Mac’s filesystem and is visible in Finder, so it never consumes space inside the virtual disk. Named volumes do live inside it, which is why the two look similar in a Compose file and behave very differently when the disk fills up.