Why Is Docker.raw So Huge on My Mac—and Is It Wearing My SSD?

Docker Desktop stores its Linux containers, images, volumes, and other Docker-managed data in one alarming-looking sparse disk image. The mistake is treating its provisioned size, occupied space, Docker data, and SSD writes as one number.

By CoreGuard · Jul 23, 2026 · 22 min read

Why is Docker.raw so huge on my Mac?

Docker.raw is Docker Desktop’s sparse virtual disk: its apparent size is the provisioned capacity of the Linux VM disk, not necessarily the amount of Mac storage currently occupied. Docker’s own Mac FAQ distinguishes the disk image’s maximum size from the actual space it consumes.

Four numbers get collapsed into “Docker is using 100 GB”:

1. the virtual disk’s apparent or maximum size;
2. the host blocks currently allocated to Docker.raw;
3. Docker’s current images, containers, volumes, and build cache inside the VM;
4. host writes recorded by the backing drive’s SMART counter — Data Units Written on NVMe, a vendor-specific attribute on SATA.

Only the fourth is an endurance-relevant cumulative write counter—and even that is whole-device host traffic, not Docker attribution or physical NAND writes. A large-looking Docker.raw proves none of those things by itself.

One host file contains Docker’s Linux world

Docker Desktop cannot run Linux containers directly on the macOS kernel. It runs a Linux VM using one of the virtual-machine managers supported by the current Docker Desktop release, and the Docker engine runs inside that VM. Docker documents the current choices in its Mac virtual-machine manager guide.

The VM’s Docker-managed filesystem—image layers, container writable layers, build cache, internal metadata, and Docker-managed volumes—is represented on macOS by one large disk-image file. Docker calls the current raw-format file Docker.raw.

That “one file” design changes what the Mac can see. Linux may see thousands of files changing inside containers, while macOS sees the Docker Desktop VM process writing regions of one host file.

There is an important exception: a bind mount exposes a real macOS path to a container. Writes to a bind-mounted project, database, or output directory land in that host directory rather than becoming ordinary retained data inside Docker.raw. They still reach the host storage, and Docker’s file-sharing machinery may still participate, but the path evidence is different.

Do not guess the disk-image location from an old forum post. Docker Desktop shows the current path under Settings → Resources → Advanced → Disk image location. A common location documented by Docker is:

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

The location can be changed, and Docker explicitly warns against moving the file directly in Finder.

The four numbers: what each answers and what it cannot

1. Apparent size: the provisioned virtual-disk capacity

Copy the current path from Docker Desktop, then run:

DOCKER_RAW='/paste/the/path/from/Docker-Desktop/Docker.raw'
ls -lh "$DOCKER_RAW"

The size column in ls -l is the file’s logical length. Apple’s ls(1) source manual describes the long format as displaying the number of bytes in the file.

For Docker.raw, that logical length corresponds to the provisioned virtual-disk capacity. It answers:

How large may this virtual disk appear to filesystems and software that read its logical length?

It does not answer how many host blocks are currently allocated, how much Docker data exists, how many bytes Docker has written over time, or how much SSD endurance has been consumed.

A sparse file can have a large logical address space without allocating host storage for every address. Unmaterialized regions behave like holes. Reading them produces zeros, but they do not require corresponding data blocks on the host.

2. Occupied host space: currently allocated blocks

Read the same file with du:

du -h "$DOCKER_RAW"

Apple’s du(1) source manual says the command displays filesystem block usage; its separate -A option switches to apparent size specifically for cases such as sparse files. Without -A, du -h is the useful view here.

This number answers:

How much host filesystem allocation is currently charged to this file?

It is current occupancy. It is not cumulative writes. A block can be written, overwritten repeatedly, and still occupy one block’s worth of space. Other blocks may later be reclaimed. Neither history is recoverable from one du reading.

This is why ls -lh and du -h can both be correct while disagreeing dramatically.

3. Docker’s view: retained objects inside the engine

Ask the Docker daemon what it currently accounts for:

docker system df
docker system df -v

Docker documents docker system df as showing disk usage by the daemon. Its detailed view breaks out images, containers, local volumes, shared and unique image data, and build cache.

This number answers:

What Docker-managed objects does this daemon currently retain, and which of them does it consider reclaimable?

It still is not “bytes Docker has ever written.” It is current logical occupancy from the engine’s perspective.

It is not necessarily a complete accounting of the VM disk either. Container logs, filesystem overhead, Docker Desktop internals, data deleted inside a running container, and files reached through bind mounts can create differences between docker system df, the Linux filesystem’s view, and host-side du.

Do not expect the guest and host numbers to match byte for byte. They sit on opposite sides of a virtual block device, filesystem allocation, sparse-file mapping, and possible reclamation.

4. Host NVMe writes: the endurance-relevant odometer

Bracket the physical device that BACKS Docker.raw — usually the internal SSD, but Docker Desktop lets you move the disk image to another drive (Settings → Resources → Advanced shows its location), and bind mounts can live on yet another. Do not assume: map each path to its device first. On APFS that takes one extra hop — df hands you a synthesized volume node, not the drive:

df "$DOCKER_RAW"              # e.g. /dev/disk3s1 — a synthesized APFS volume, not the drive
diskutil info /dev/disk3s1    # read its "APFS Physical Store" line(s), e.g. disk0s2
diskutil info /dev/disk0s2    # its "Part of Whole" is the physical disk, e.g. disk0
smartctl -a /dev/disk0        # the whole physical disk

diskutil info on the volume reports one or more APFS Physical Stores such as disk0s2; running diskutil info on that store shows its Part of Whole — the physical disk (disk0) that smartctl actually reads. Do not just strip the partition suffix: a Fusion- or RAID-backed container lists more than one store (diskutil apfs list enumerates them), and a store is not guaranteed a diskXsY-style id — resolve each store to its whole disk and bracket every one, or say no complete bracket is available. Repeat the whole chain for every bind mount you care about — they can sit on a different drive. smartctl comes from smartmontools and is not built into macOS; if a read fails for lack of permission, rerun only that command with sudo.

One hard limit: Data Units Written is an NVMe field — it lives in the NVMe SMART/Health log, which is why one raw unit is 512,000 host bytes. Do not decide that from the diskutil protocol name: Apple Silicon reports Apple Fabric and Intel/T2 Macs often report PCI-Express, and both are the internal NVMe SSD. Let smartctl answer it — you are on NVMe if its output contains a SMART/Health Information (NVMe Log 0x02…) section with a Data Units Written line. A SATA SSD exposes a different, vendor-specific host-write attribute instead — smartctl may decode it as Total_LBAs_Written, Host_Writes_GiB, or in 32 MiB units, depending on what its drive database knows about that model. Use the units smartctl reports for your drive, label the number with them, and never assume the ×512-byte LBA conversion: if the units are unknown, treat it as no trustworthy byte bracket rather than inventing one. The ×512,000 arithmetic in this article is NVMe-only. A USB enclosure or bridge may block SMART pass-through entirely; where nothing comparable is exposed there is no trustworthy host-write bracket for that drive, so say so and stop rather than substituting a number from a different device. And a delta only ever upper-bounds the drive it came from.

Record the raw Data Units Written value before and after a known Docker-heavy window:

approximate host-byte delta =
(Data Units Written after - Data Units Written before) × 512,000

The NVM Express specification archive defines this field in thousands of 512-byte units, rounded up. One raw unit therefore represents 512,000 host bytes, not 512.

This number answers:

How much host data reached this NVMe controller during the observation window?

It does not name Docker. It includes the browser, swap, Spotlight, builds outside containers, downloads, sync, logs, and every other writer using that device.

It also is not physical NAND traffic. SNIA’s endurance paper defines write amplification as NAND writes divided by host writes. Garbage collection, wear levelling, and other controller work remain hidden below Data Units Written.

Why a “100 GB Docker.raw” is usually not 100 GB occupied

If Finder or ls -lh shows a roughly 100 GB Docker.raw, the first hypothesis should be provisioned capacity—not current occupation and certainly not cumulative writes.

Check du -h. If it is much smaller, the difference is the sparse part of the file: logical address space that has no corresponding current host allocation.

If du is also large, that proves only that substantial host storage is presently allocated to the disk image. It still does not reveal whether those blocks were written once, overwritten thousands of times, or occupied by data that Docker still needs.

The reverse matters too. A small Docker.raw is not proof of low Docker write traffic. A database can repeatedly overwrite a bounded working set; build cache can turn over; temporary layers can be created and removed. Occupancy measures what remains. Endurance records the write demand that occurred.

That is the same trap covered in Free space is a lie: how a small file ate a drive: storage is a current balance, while writes are a one-way odometer.

Why pruning changes space but never refunds endurance

Start with the detailed inventory:

docker system df -v

Then decide what you genuinely no longer need. If that decision includes stopped containers, unused networks, dangling images, and unused build cache, Docker provides:

docker system prune

Docker’s system prune reference is explicit about the deletion set and shows a confirmation prompt. The -a flag widens image deletion beyond dangling images. The --volumes flag widens deletion to unused anonymous volumes. Do not add either flag from habit.

Pruning is a deletion operation with consequences. A stopped container can contain work in its writable layer. Build cache can save a costly rebuild. A volume can contain the only copy of a development database.

After the deletion, docker system df may fall because fewer Docker objects remain. du -h Docker.raw may also fall if freed guest blocks are returned through the virtual disk to the host sparse file.

That last boundary is where “docker system prune not freeing space on Mac” reports get messy. Docker’s current Mac FAQ says host space for Docker.raw should be reclaimed within seconds after images are deleted, but it separately says that deleting files inside running containers does not automatically release host space. Exact timing and behavior have varied across disk formats, VM backends, and Docker Desktop versions, so I would verify the result with du rather than assuming a particular mechanism ran.

If du remains high, check the boring explanations first:

• the data is still active or not considered reclaimable;
• it lives in a volume that ordinary system prune did not remove;
• it is container log or internal VM data rather than the objects you deleted;
• it was written to a bind-mounted macOS path, not Docker.raw;
• or guest blocks were freed without yet producing equivalent host-side reclamation.

For that last case Docker documents an explicit trigger: docker run --privileged --pid=host docker/desktop-reclaim-space returns already-freed guest blocks to the host file, and it deletes no images, containers, or volumes. Re-read du -h afterwards — if the number moves, host-side reclamation was the answer; if it does not, the space is still held by something you have not identified yet.

None of these changes the endurance result. Deleting an image today cannot subtract from yesterday’s Data Units Written. A smaller disk image tomorrow does not refund the host writes used to pull, extract, build, run, log, and later delete its contents.

The virtual-disk cap is separate again. Docker Desktop exposes it under Settings → Resources → Advanced. Lowering that cap changes a maximum, not present usage—and Docker’s current Mac FAQ warns that reducing it deletes the existing disk image and loses the local Docker data it contains. Do not destroy a working environment merely to make ls display a prettier number.

Deleting Docker.raw manually is the same class of action, only blunter. The file contains Docker-managed state. Docker’s backup and restore guide treats copying it as a way to preserve that state when Docker Desktop cannot launch. Removing it without a verified backup discards local images, containers, and Docker-managed volume data.

What genuinely writes heavily with Docker

Docker is a development workload, not an SSD anomaly by definition. Large writes are often legitimate. The useful question is whether the rate matches the work.

Image pulls and layer extraction

A pull downloads compressed layers, verifies them, and stores their extracted content for use by the engine. A large new base image therefore creates real network and disk traffic even if the final image list looks compact through layer sharing.

If the same layers are pulled repeatedly, ask why they keep disappearing. Pruning useful images after every session can force more downloads and extraction later — shared content-addressed layers may survive, so it is a risk you take on, not a certainty. Remove images because you no longer need them, not as a write-reduction ritual.

Builds, cache invalidation, and --no-cache

Every rebuilt layer can create filesystem output, package-manager data, intermediate snapshots, and build-cache records. --no-cache deliberately prevents layer reuse; it is a diagnostic or reproducibility choice, not a harmless default.

Docker’s build-cache guide recommends placing stable, expensive steps before frequently changing source, keeping the build context small, and using cache mounts for package-manager data. The endurance-relevant benefit is simple: work that is validly reused does not need to be downloaded and materialized again.

Do not confuse “retain useful cache” with “retain everything forever.” Inspect the detailed build-cache view, understand what is reusable, and remove stale data deliberately.

Databases and other durability-heavy services

A database in a container can issue frequent journal, WAL, checkpoint, and fsync operations because durability is its job. If its data lives in a named volume, those writes normally land within Docker’s managed VM storage. If it uses a bind mount, the data lands in the mounted macOS directory.

Do not disable durability merely to make a write chart quieter. For a disposable test database whose contents may vanish on every stop, a bounded tmpfs can be appropriate. For persistent data, use persistent storage and accept the writes required by the durability guarantee.

Docker’s tmpfs documentation states both sides clearly: the data is temporary and is removed when the container stops, but tmpfs memory may itself be written to swap. It removes ordinary persistent-file writes for that path; it is not a universal promise of zero host SSD traffic.

Bind-mounted build trees

A container compiling into a bind-mounted project can produce object files, dependency trees, generated sources, test databases, and temporary results directly on the Mac filesystem. Those writes may barely affect Docker.raw, which is why watching only the disk image misses them.

Use a bind mount when the Mac genuinely needs direct access to the files. If state only needs to persist for containers, a named volume may be the clearer ownership boundary. If it is disposable scratch state, tmpfs may fit—with the data-loss and swap caveats above.

Container logs

A noisy service can turn stdout and stderr into steady disk traffic. Docker’s logging-driver documentation says the default json-file driver does not rotate logs by default and recommends the local driver for built-in rotation, or explicit size and file limits for json-file.

Check the current driver and the application’s log rate before changing anything:

docker info --format '{{.LoggingDriver}}'
docker inspect -f '{{.HostConfig.LogConfig.Type}}' CONTAINER

Logging changes normally affect newly created containers; existing containers retain the configuration with which they were created. Preserve the logs you actually need, then configure retention according to that need.

Recreating disposable environments without preserving useful cache

Repeatedly tearing down an environment, pruning its reusable layers, and rebuilding from nothing converts an ordinary incremental workflow into repeated pulls, extraction, package installation, and compilation.

My rule is narrow: keep data whose reuse is intentional; remove data only when its value has expired. “Delete everything, then rebuild everything” is easy to explain, but it is not a low-write workflow.

Attribute Docker’s writes on the host

Use the same process → path → device chain as any other Mac write investigation.

First, open Activity Monitor → Disk, show all processes, and compare two Bytes Written readings during a known build, pull, or database workload. Record the exact Docker-related process and PID whose counter is climbing. Process names vary with Docker Desktop release and selected VM manager, so “the Docker Desktop VM process” is safer than hardcoding com.docker.virtualization, HyperKit, or QEMU as universal names.

Then capture a bounded broad trace:

sudo fs_usage -w -f filesys -t 30

Apple documents fs_usage as a root-required live trace of filesystem-related system calls. The filesys filter includes reads, opens, metadata activity, errors, and page activity—not just writes. By default it excludes Terminal and the shells sh, zsh, and tcsh.

Once the broad trace confirms the responsible PID, narrow the next window:

sudo fs_usage -w -f filesys -t 30 12345

Replace 12345 with the observed PID. Read write, writev, and fsync beside nearby open, rename, unlink, and truncate events. A write row may expose a descriptor while a nearby open carries the path.

The path tells you which branch you are on:

…/Docker.raw                          → Docker-managed VM storage
…/your/project-or-data-directory      → bind-mounted host data
another Docker Desktop support path   → Desktop metadata, logs, or VM support data

Now bracket the same controlled workload with the drive’s supported host-write counter. Keep unrelated writers as quiet as practical and record what ran. That delta is a whole-device upper bound for Docker during that window ONLY if Docker.raw and the bind mounts you care about live on this device — and it is never proof that Docker caused every byte.

The complete joining method is in Which App Is Writing to My Mac’s SSD?. If the remaining question is whether the measured rate is unusual, compare like workloads using How much SSD writing is normal on a Mac?.

What these numbers cannot prove

Keep the boundaries intact:

• ls -lh Docker.raw reports logical length, not occupied storage.
• du -h Docker.raw reports current host allocation, not cumulative writes.
• docker system df reports current Docker object usage, not all VM files or lifetime traffic.
• A Docker process counter cannot prove which guest container caused every write.
• Data Units Written cannot identify Docker and cannot reveal physical NAND writes.
• A large Docker burst is not automatically abnormal; pulls, builds, databases, and imports write legitimately.
• An anomaly is changed behavior, not proof of hardware danger.
• This bracket covers the disk image and the bind mounts you chose — not every byte Docker Desktop writes. Its support and log paths (under ~/Library/Containers/com.docker.docker/Data/) can sit on a different drive than Docker.raw, especially once you move the disk image, and work can be spread over several Docker-related processes.
• Pruning, shrinking, or resetting data never reverses endurance already spent.

The practical discipline is to write down the layer beside every number. Most Docker disk arguments disappear once “cap,” “occupied,” “guest data,” and “host writes” stop sharing one unlabeled column.

Where CoreGuard fits

The manual method is complete. Docker Desktop shows the disk-image path and cap; ls and du separate apparent from allocated size; docker system df inventories guest objects; Activity Monitor and fs_usage attribute the host process and paths; two readings of a supported whole-device host-write counter bracket the drive.

Its weakness is timing. A build, runaway log, or container retry loop can stop before you open Activity Monitor. The drive’s host-write counter retains the bytes but forgets the process that caused them.

CoreGuard observes that missing time dimension without touching Docker. In Free, an abnormal-write warning remains free and names the responsible host process—including the Docker Desktop VM process when that is the writer. Basic SSD danger warnings also remain free.

Pro adds the detailed per-app write timeline, longer history, export, and the SSD endurance and wear trend. That can show when the Docker VM process left its prior baseline and whether the event recurred. It cannot automatically identify which container or guest path was responsible; the Docker and fs_usage investigation above remains the honest next step.

CoreGuard never prunes images, removes containers, changes logging drivers, resizes Docker.raw, or deletes Docker data. It observes and explains. The warning and named process stay free; Pro is the longer evidence trail.

How to read Docker’s real disk story on a Mac

1. Compare apparent and occupied size: Copy the disk-image path from Docker Desktop, then run ls -lh "$DOCKER_RAW" and du -h "$DOCKER_RAW". Record both values and label them “logical cap” and “current host allocation”; their difference is the sparse part.
2. Read the guest’s view: Run docker system df and docker system df -v. Record images, containers, local volumes, build cache, and reclaimable values without treating their sum as cumulative writes.
3. Check the provisioned cap: Open Docker Desktop → Settings → Resources → Advanced and record the disk usage limit and disk image location. Remember that the limit is a maximum, and Docker currently documents reducing it as a destructive disk-image replacement.
4. Bracket whole-device writes: Map each path to its PHYSICAL device instead of assuming (on APFS df returns a synthesized volume, so read its “APFS Physical Store” line(s) from diskutil info, then diskutil info that store for its “Part of Whole” physical disk — a Fusion/RAID container has more than one store (diskutil apfs list), so resolve and bracket each): df "$DOCKER_RAW" for the disk image (its location is under Settings → Resources → Advanced, and it can live on an external drive), plus df on any bind mount you care about, then diskutil info /dev/diskN to see the protocol. Take smartctl -a /dev/diskN readings before and after a known pull or build, repeating per device. smartctl comes from smartmontools and is not built into macOS; multiply the raw DUW delta by 512,000 for approximate host bytes. Let smartctl decide the counter, not the diskutil protocol name (Apple Silicon prints Apple Fabric and is still the internal NVMe SSD): NVMe drives report Data Units Written, a SATA SSD reports a vendor-specific host-write attribute instead (Total_LBAs_Written, Host_Writes_GiB, 32 MiB units … — use the units smartctl decodes for that model, never a blanket ×512), and a USB bridge may expose nothing — if nothing comparable is exposed, record that no trustworthy bracket exists for that drive rather than substituting another drive’s number. Each delta upper-bounds only its own drive.
5. Attribute the host process and path: Compare Activity Monitor Disk readings, record the Docker VM process PID, then run sudo fs_usage -w -f filesys -t 30 PID during the workload. Distinguish writes to Docker.raw from writes to bind-mounted macOS paths — and note that Docker Desktop support/log paths (under ~/Library/Containers/com.docker.docker/Data/) are a third class this bracket deliberately does not cover.
6. Delete only data you do not need: Review docker system df -v, then use docker system prune only if its stated deletion set matches your intent. It changes current space accounting, not past endurance; do not casually add -a, --volumes, or delete Docker.raw.
7. Re-read and preserve context: Repeat ls, du, docker system df, and the optional host-write-counter reading. Save the timestamp, workload, Docker action, process, path class, and before/after values so the next measurement has a baseline.

Terms used in this guide

• Docker.raw: Docker Desktop’s raw-format sparse disk-image file containing the Docker-managed filesystem of its Linux VM.
• Sparse file: A file whose logical address space can be larger than the host blocks currently allocated to it; unallocated holes read as zeros.
• Apparent size vs allocated size: Apparent size is the file’s logical length, shown by ls -l; allocated size is current filesystem block usage, shown by du.
• docker system df: A Docker CLI command that reports current daemon-managed images, containers, local volumes, and build-cache usage.
• Build cache: Reusable results and package data retained by Docker’s builders so valid build work does not need to be repeated.
• Data Units Written: The NVMe cumulative host-write counter, reported in thousands of 512-byte units; one raw unit represents 512,000 host bytes, not physical NAND writes.

Frequently asked questions