Finder often shows Docker.raw as 60 GB or more. Usually it uses far less, because it is a sparse file. Here is how to tell, and how to reclaim the real space.
By MacMonitor · Published · Updated · macOS 26; app requires macOS 14 or later
Short answer: Docker.raw is a sparse disk image: its logical size can be much larger than its allocated storage. Compare du -h with Docker Desktop’s disk information, then use docker system df to inspect Docker objects. Remove only objects you understand and no longer need. Read the prune warnings below before running cleanup commands, and preserve required container or volume data.
~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.rawcd ~/Library/Containers/com.docker.docker/Data/vms/0/data
ls -lh Docker.raw # the size it claims, for example 64G
du -h Docker.raw # the space it really uses, for example 3.5GThe claimed size is the disk limit set in Docker Desktop. Only the second number is space you can get back.
docker system dfdocker system prune-a. Volumes hold data such as databases; prune them only if you are sure, with docker volume prune.A large disk image is the container that holds Docker’s working environment, not a description of one unwanted file. Before pruning, inspect the breakdown of images, containers, volumes and build cache. A database volume, a downloaded base image and a stopped experiment can all occupy storage while having very different retention value.
Run the inspection command from a Terminal connected to the Docker environment you intend to review. If you use multiple contexts or a remote engine, make sure the output belongs to the local Docker Desktop installation. A successful command against another machine does not explain storage on this Mac.
Images provide application layers used to create containers. Containers can have writable changes of their own, even when they are stopped. Volumes often contain data that should survive a container being replaced. Build cache can save repeated build work. None of those names is a blanket instruction to delete everything in that category.
“Unused” is also specific to the tool’s current view of references. An image not attached to a running container may still be one you need offline tomorrow. A stopped container may contain a debugging state you wanted to inspect. Read the command’s confirmation and establish what you can recreate before proceeding.
Imagine a project with a local database volume and several old test containers. This illustrative case explains why a single prune total is not enough. You may be happy to remove an abandoned container while needing to preserve the database, its migrations and the records used to reproduce a problem.
Export or back up the database through a supported database procedure, and verify that you know how to restore it. Copying an unknown disk-image file is not automatically an application-consistent backup. After preserving what matters, remove only the objects you can explain and recreate.
Volumes deserve a deliberate inventory because their purpose is commonly to retain data beyond an individual container. Before removing a volume, identify which project created it and whether it contains a database, uploaded files or another persistent store. A volume with an unfamiliar generated name is not necessarily unimportant.
Read the current command’s help and confirmation for your installed Docker version. Do not add options simply because an online example promises a larger cleanup. Broad prune commands can remove useful resources that are not active at this moment but are still part of your normal workflow.
There are several layers between a file inside a Linux container and available storage on the Mac. Deleting application data, removing a Docker object and reclaiming host disk-image space are related but distinct events. Docker’s own disk-management documentation is the appropriate reference when the host allocation does not change as you expected.
Use Docker Desktop’s displayed actual usage and a host allocated-size measurement as separate checks. Do not interpret a file’s maximum size as space already occupied. Equally, do not assume that removing a certain number of bytes inside a container will immediately add that exact amount to Finder’s available-space figure.
Use Docker Desktop’s supported settings for moving or changing its disk image. Before changing the location, check that the destination is reliable, has enough capacity and is available whenever Docker needs it. An external drive that is often disconnected may be a poor home for an active development environment.
Reducing the configured maximum is a different operation from removing individual unused objects. Docker’s documentation warns that reducing the maximum deletes the current disk image and loses containers and images. Preserve required data and read the current confirmation before making that change. It is not a routine first step for a large Docker.raw file.
If the project rebuilds an image or downloads dependencies again, that is part of the cost of deleting reusable data. Keep that cost in mind before scheduling repeated cache cleanup. A slightly larger development environment can be preferable to rebuilding the same dependencies every morning.
Do not use that as ordinary cleanup. The file can contain the entire local container environment, including persistent data. Use Docker’s management tools, and only choose a full reset when you intentionally want its documented consequences.
New images, build layers and application data can create new usage. Inspect the category that grew rather than assuming the earlier cleanup failed. A recurring pattern is easier to manage when you know which project creates it.
No. It describes what the tool considers removable under its rules, not whether you still want an offline image, stopped debugging environment or local data. Review the purpose of those resources before accepting the operation.
Keep the Docker result separate first. If storage is still constrained, use the System Data guide to inspect other contributors. Changing multiple large categories simultaneously makes the result harder to explain.
Choose a maintenance interval around real project changes, not a desire to minimize the image after every session. Keep the resources needed for active work and review obsolete experiments when they are no longer useful. If build cache grows repeatedly, identify the build workflow and its retention controls rather than relying only on global pruning. Record the rebuild and download cost as part of the decision, especially when you need to work offline or prepare a time-sensitive demonstration.
Large & Old ranks files by the space they really take, so Docker.raw shows its true size instead of 64 GB. Build Caches → Docker shows the same breakdown as docker system df in a table (images, containers, volumes, build cache, reclaimable), lists your containers, and runs a conservative docker system prune that never touches volumes or images still in use.