# Shrinking Docker.raw on a Mac without losing your images

> What to do when Docker.raw stays huge after a prune: why the Mac still counts blocks freed inside the VM, how a trim hands them back, when a full quit helps, and how to purge safely with a volume backup first.

Canonical: https://bytesweep.app/blog/docker-raw-shrink.html
Last updated: 2026-10-16

## Docker.raw grew to 60 GB and pruning did nothing

`docker system prune` says it reclaimed 30 GB and the Mac has exactly as much free space as before. That’s because Docker on a Mac keeps nothing as files you can see. Every image layer, container and named volume lives inside one disk image that belongs to a Linux virtual machine, and freeing space inside that disk doesn’t automatically make the file smaller.

- By [Shajeen Ahamed](https://bytesweep.app/about.html#author)
- Published 25 September 2026
- Last updated 16 October 2026
- 4 min read
- Part of [Docker disk space on a Mac](https://bytesweep.app/docker-disk-space-mac.html)
- [How we write](https://bytesweep.app/about.html#how-we-write)

### Find the file and measure it properly

Docker Desktop keeps it here, on Apple silicon and Intel alike:

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

Older installations may have `Docker.qcow2` in the same directory instead. Either way, one file is the whole store.

Measure it with `du`, not the Finder or `ls -l`:

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

`Docker.raw` is a sparse file. `ls -l` and the Finder’s Get Info show its apparent size, which is the maximum the disk may grow to. `du` shows the blocks it really occupies on your SSD. If the two differ a lot, the big number was never real disk use.

Don’t delete this file to get space back unless you mean to lose every image, container and volume on the machine. It isn’t a cache. Named volumes with database data live inside it, and nothing outside it has a copy.

### Why deleting images leaves the file the same size

*Pruning frees blocks inside the Linux file system; only a trim hands them back to macOS.*

Pulling an image makes the virtual machine write layers to its ext4 file system inside `Docker.raw`, and the file grows on the Mac to hold them. Deleting the image makes ext4 mark those blocks free, but macOS still sees them as part of the file. They come back to macOS only when the VM tells the host which blocks are unused (a trim, or discard) and the host punches holes in the file.

In the meantime Docker reuses the free blocks for the next pull, so the file can sit at one size for months and then jump again after a large pull.

### Getting the space back

Prune first. On current Docker Desktop releases the disk is trimmed after space is freed inside it, so this alone often brings the file down.

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

Read [what each prune flag actually deletes](https://bytesweep.app/blog/docker-system-prune-guide.html) before running that second line. `-a` removes every image not used by a container. `--volumes` removes unused anonymous volumes on Docker Engine 23.0 and later; on older engines it removed named volumes too, which is where a local database lives.

If `du` still shows the old size, Docker’s documented way to trigger reclamation is `docker run --privileged --pid=host docker/desktop-reclaim-space`. Failing that, quit Docker Desktop completely from the menu bar whale and open it again. Closing the dashboard window isn’t enough, as the VM keeps running.

The disk size limit under Settings, Resources, Advanced caps future growth. Don’t lower it to get space back: reducing it deletes the current disk image, and every image, container and volume with it.

When nothing else works, the last resort is Settings, Troubleshoot, “Clean / Purge data”. It deletes the disk image and creates an empty one. You get every byte back and you lose everything inside, so back up named volumes first:

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

### What’s taking the space inside

The verbose form of `docker system df` lists every item, which is what you want when one thing is 40 GB and the rest is noise:

```
docker system df -v
```

On a working machine three things usually dominate. Images come first, mostly repeated base layers. Then the build cache, which BuildKit keeps growing until it hits a garbage-collection limit; [the BuildKit build cache and how to bound it](https://bytesweep.app/blog/docker-build-cache.html) covers setting one. Then volumes: [orphaned volumes are where the data actually is](https://bytesweep.app/blog/docker-volumes-orphaned.html) explains which ones a careless prune destroys.

If the file keeps creeping up week after week, the build cache is the usual cause. Multi-stage builds write a lot of intermediate data.

### If this keeps happening

Then the storage model is the thing to change, not the cleanup routine. Colima and OrbStack handle their disks differently, and OrbStack in particular returns space to macOS as you delete things. How Docker Desktop, Colima and OrbStack differ on disk compares them on exactly that point.

### Questions

#### Why does Docker Desktop say 10 GB when my Mac says 60?

Docker reports what’s in use inside the virtual machine. The Mac reports the file that machine lives in, including blocks that were freed inside but not yet trimmed. Check with `du` too: if the Mac’s number came from the Finder, part of it may be the sparse file’s apparent size.

#### Is it safe to delete Docker.raw?

Docker will create a new one and keep working. But every image, container and named volume is inside it, including database data that exists nowhere else, so use “Clean / Purge data” after a volume backup rather than deleting the file by hand.

### Let Bytesweep clear this for you

Skip the commands. Bytesweep finds this for you, rates every item safe, review first or keep, and clears what you choose. Most of what it removes can be put back for seven days. See what it finds on your own disk, free for 3 days, then pay once with no subscription.

[Try it free for 3 days](https://bytesweep.app/download.html) [Buy · $29.99](https://bytesweep.app/pricing.html)

Related in Bytesweep: [Developer tools](https://bytesweep.app/dev-servers.html)

### Keep reading

- [**docker system prune: what each flag actually deletes** The difference between prune, prune -a and prune --volumes is the difference between freeing a few gigabytes and losing a local database. A precise account of what each form removes, with the safe order to run them in.](https://bytesweep.app/blog/docker-system-prune-guide.html)
- [**The BuildKit cache grows until something bounds it** BuildKit keeps intermediate layers from every build, and whether anything caps them depends on your builder. How to see the cache's real size, prune it by age, and set a limit that holds.](https://bytesweep.app/blog/docker-build-cache.html)
- [**Orphaned Docker volumes are where the data actually is** A named volume outlives the container that created it and carries no label saying what it was for. How to inspect one before deleting it, how to find the genuinely orphaned ones, and how to back one up in a single command.](https://bytesweep.app/blog/docker-volumes-orphaned.html)