docker build: no space left on device
No space left on device during docker build
Verified against Docker 27 docs (engine/reference/commandline/system_prune), Stack Overflow #44417159 · Updated April 2026
> quick_fix
Docker's storage directory is full of old images, stopped containers, and build cache. Reclaim space with `docker system prune -af --volumes` — this usually frees several GB instantly.
# See what Docker is using
docker system df
# Reclaim everything unused (images, containers, networks, volumes, build cache)
docker system prune -af --volumes
# Just build cache (safer — keeps images)
docker builder prune -afWhat causes this error
Every docker build step creates a layer. Old layers, dangling images, exited containers, unused volumes, and the build cache all accumulate in /var/lib/docker (or the Docker Desktop VM on macOS/Windows). When the underlying filesystem fills, any disk-write during build fails.
How to fix it
- 01
step 1
Check what's using the space
`docker system df` shows a breakdown by images, containers, volumes, and build cache. Usually one of them is 10GB+.
docker system df - 02
step 2
Prune aggressively for a quick fix
`docker system prune -af --volumes` removes everything not currently in use. This is safe if you don't have critical data in unnamed volumes.
docker system prune -af --volumes - 03
step 3
On Docker Desktop (Mac/Windows), resize the VM
If prune isn't enough, Docker Desktop → Settings → Resources → Disk image size. Default is often too small for professional use.
- 04
step 4
Set up a build-cache retention policy
In docker/buildx, configure `--cache-from=type=local,dest=/tmp/.buildx-cache-new,mode=max` with a max-age to stop cache from growing unbounded.
Why no space left happens at the runtime level
Docker stores all layers, container writable layers, volumes, networks, and build cache under /var/lib/docker (Linux) or inside a fixed-size qcow2/raw disk image owned by the Docker Desktop VM (macOS/Windows). On Linux, the underlying filesystem is the host's. On macOS, the VM image grows to a configured maximum and never shrinks even after pruning. When any docker operation calls write() and the underlying filesystem returns ENOSPC, the build or pull aborts. The error originates from the kernel, surfaces through containerd/runc, and bubbles up as a generic 'no space left on device' from the Docker daemon.
Common debug mistakes for no space left
- Running rm -rf /var/lib/docker/* while the daemon is up, the daemon keeps file handles open, so the disk doesn't actually free, and the corrupt state breaks the next docker start.
- On macOS, pruning containers but never resizing the VM disk, the qcow2 file is sparse-allocated and stays at peak size; only Settings > Resources > Apply & Restart actually reclaims the host disk.
- Building with --no-cache to 'work around' space, every build now writes a fresh full layer set with zero reuse, filling the disk faster than before.
- Pruning volumes with --volumes flag without checking, wipes named volumes that contained the only copy of dev databases, secrets, or local-only assets.
- Increasing the disk image size without checking host free space, Docker Desktop reserves the full requested size on the host, so a 100GB request on a 90GB-free MacBook fails silently or corrupts the image.
When no space left signals a deeper problem
Repeated 'no space' across the team signals a build pipeline that never shipped a layer-caching strategy. When every developer's local Docker accumulates 50+ versions of the same base image because Dockerfile ordering forces full rebuilds, the underlying issue isn't disk size but build-graph design. The architectural fix is multi-stage builds with explicit cache mounts, a shared remote cache (BuildKit's --cache-to=type=registry,ref=...), and a retention policy on CI runners. Without it, the team trades hours per week to docker system prune and CI runs slow because every build downloads layers fresh.
Editor's take
This error has a particular talent for appearing at 11pm the night before a production release. A small startup with a three-person backend team, running a monolith on a single CI host — maybe a DigitalOcean droplet that was upgraded from 50GB to 80GB six months ago and hasn't been touched since — hits this mid-deploy because the build cache from 200 previous runs finally consumed the last inode block. The pipeline dies after a 12-minute build, the rollback fails for the same reason, and now the on-call engineer is SSHed in at 2am running `df -h` and `docker system df` for the first time.
Hitting this in your first month tells you Docker is not a thin wrapper around a process — it's a storage engine with its own lifecycle. The engineer who encounters it and actually reads the `docker system df` breakdown (images, containers, local volumes, build cache broken out separately) comes away with a mental model most people skip. Fixing it cleanly — pruning selectively with `docker image prune --filter until=72h` instead of the nuclear `system prune -af --volumes` — is the difference between a junior reaching for a sledgehammer and a mid-level understanding what production volumes contain state worth preserving.
In the same incident you'll almost always see `COPY failed: no space left on device` mid-layer, which appears as a different surface error but shares the same root. Dig further and you'll find `OCI runtime create failed: container_linux.go: write /var/lib/docker/overlay2/...` errors in dockerd logs. On CI hosts running Docker-in-Docker with BuildKit enabled, `DOCKER_BUILDKIT=1` caches accumulate separately under `/var/lib/docker/buildkit/` and are invisible to `docker images` — a common reason `docker system prune` appears to free nothing.
By Bikram Nath · Curator · Updated April 2026
Frequently asked questions
Is docker system prune destructive?
It removes stopped containers and unused resources. It does NOT touch running containers or the images they use. But anything you stopped without intending to delete will be gone.
Why does Docker Desktop run out of space faster than Linux Docker?
Because Docker Desktop uses a fixed-size disk image for its VM. Once that VM disk is full, even `docker pull` fails. Resize it via Settings.
How do I set a max cache size?
BuildKit supports `--cache-to=type=local,dest=... ,mode=max` with garbage collection. See docs/engine/storage-driver.