Docker: No Space Left on Device (tested)

This error means whatever filesystem your container is writing to — its writable layer, a bind mount, a volume, or a size-limited tmpfs — has run out of room. It's rarely about total host disk space; it's almost always one specific thing (often Docker's own image/build cache, or an unbounded log/volume) that filled up.

1. Reproduced: a real write failure

We mounted a tmpfs capped at 10 MB and tried to write 50 MB into it — this is bounded to RAM, so it's safe to run without risking real disk:

docker run --rm --tmpfs /data:size=10m alpine sh -c "dd if=/dev/zero of=/data/file bs=1M count=50"

dd: error writing '/data/file': No space left on device
11+0 records in
10+0 records out
10485760 bytes (10.0MB) copied, 0.011571 seconds, 864.2MB/s

Notice dd wrote exactly up to the 10 MB limit (10+0 records out) before failing on the 11th block — the write didn't fail instantly, it filled the available space first. The same shape of error happens on a full bind mount, full named volume, or full host disk; only the underlying cause differs.

2. Find out what's actually full: don't assume it's the whole disk

In the real-world version of this error, it's almost never the entire host disk — it's Docker's own storage. docker system df breaks down exactly where Docker's disk usage is going, with no guessing:

docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          32        22        17.27GB   3.228GB (18%)
Containers      22        21        94.15MB   4.096kB (0%)
Local Volumes   8         2         80.59MB   80.59MB (100%)
Build Cache     59        1         1.196GB   1.193GB

The RECLAIMABLE column is the key number: on this host, 3.2 GB of images and 1.2 GB of build cache could be freed without affecting anything currently running. Local Volumes shows 100% reclaimable because those 8 volumes aren't attached to any running container right now.

3. Fix 1: raise the limit (when the limit itself was wrong)

If the mount's size limit was simply set too small for legitimate use, raising it is the direct fix — we confirmed the identical write succeeds once the tmpfs is large enough:

docker run --rm --tmpfs /data:size=100m alpine sh -c "dd if=/dev/zero of=/data/file bs=1M count=50 && echo OK"

50+0 records in
50+0 records out
52428800 bytes (50.0MB) copied, 0.037491 seconds, 1.3GB/s
OK

4. Fix 2: reclaim space instead of raising a limit

If the real problem is Docker's accumulated images/cache (the common host-disk case, not a deliberately-sized mount), reclaim it instead of expanding anything:

# safe: only removes resources not in use by any container
docker system prune

# more aggressive: also removes unused (not just dangling) images
docker system prune -a

# just the build cache, often the single biggest reclaimable chunk
docker builder prune

Run docker system df again afterward to confirm the reclaim actually freed what you expected — don't assume the prune worked without checking the new numbers.

5. The real host disk is a different check

If docker system df shows nothing unusually large, the host filesystem itself (often /var/lib/docker's partition) may be full from something outside Docker entirely — application logs, other services, a growing database file. Check that separately with df -h on the host; Docker's own accounting only covers what Docker itself manages.

Frequently asked questions

Does this mean my whole disk is full?

Not necessarily. We demonstrated the error with a 10 MB tmpfs limit that had nothing to do with overall disk space. docker system df is the right first check: it shows Docker's own breakdown (images, containers, volumes, build cache) before you assume it's the host disk.

What's the single biggest thing to check first?

Build cache and unused images, in our experience and per Docker's own system df output above (3.2 GB and 1.2 GB reclaimable respectively on a typical dev host) — these accumulate silently from repeated docker build runs and rarely get cleaned automatically.

Is docker system prune safe to run?

docker system prune only removes resources Docker considers unused (stopped containers, dangling images, unused networks, unused build cache) by default; it won't touch anything attached to a running container. docker system prune -a is more aggressive and also removes unused (not just dangling) images, so check docker system df before and after to see exactly what it reclaimed.

Why did dd write some data before failing?

We observed this directly: dd wrote exactly up to the available space (10 of the requested 50 MB) before erroring on the write that exceeded it. The filesystem doesn't reject the write upfront; it fails partway through once space actually runs out.

My host disk itself is full, not just Docker's share — what then?

Check df -h on the host directly. Docker's system df only accounts for what Docker manages (images, containers, volumes, build cache); application logs, other services, and unrelated files on the same partition can fill the disk without showing up in Docker's own accounting at all.

Written with AI assistance. Measured on 2026-10-03 with Docker Engine 29.8.1 on Linux. The write failure below is real, reproduced output from a size-limited tmpfs mount (bounded to 10 MB of RAM, not real disk) so it's safe to run anywhere; the diagnosis commands (docker system df) are run against a real host. PlainHeaders is our extension; Docker is free.