"no space left on device" during docker build

Not specified by the original author.

TL;DR

GitHub-hosted runners only have about 14 GB free, and Docker layers plus caches eat it fast. Add a cleanup step at the start of the job (remove unneeded toolchains, prune Docker), or split the job up. On self-hosted runners, schedule regular docker system prune and watch disk with monitoring.

The error

Error: No space left on device
write /var/lib/docker/...: no space left on device
ENOSPC: no space left on device

Jobs fail at checkout, build, or Docker steps, often intermittently.

Use this when

• Actions jobs fail with no space left on device
• docker build or docker pull fails on the runner
• self-hosted runner disk fills over days
• failures are intermittent (depends what ran before)

Not for

• Kubernetes node disk pressure
• artifact too large to upload (thats a size limit, not disk)
• your laptop being full

Steps

1. Confirm disk is the issue and find the hog. Add a debug step:

- name: disk usage
  run: df -h && du -sh /opt/* /usr/share/* 2>/dev/null | sort -rh | head

Expected: / at or near 100 percent. On GitHub-hosted runners the usual winners are /opt tool caches, Docker layers, and the hosted tool cache.

2. Free the big preinstalled chunks you dont need (github-hosted runners):

- name: free disk space
  run: |
    sudo rm -rf /usr/share/dotnet /opt/ghc /usr/local/share/boost
    sudo rm -rf "$AGENT_TOOLSDIRECTORY"

Expected: several GB back. Only remove toolchains your build doesnt use; check what your job needs first. There are community actions that do this cleanup, but the manual version is transparent.

3. Prune Docker aggressively if the job uses containers:

- name: prune docker
  run: docker system prune -af --volumes

Expected: unused images, containers, and build cache gone. Run it BEFORE the docker build step, not after the failure.

4. Shrink what the job stores:

• use --squash-style minimal final images or multi-stage builds that drop build layers
• dont cache the world: cache only dependency dirs, and set cache size limits
• upload artifacts instead of keeping everything on disk between jobs

Expected: the job's own footprint drops, so it fits even on a dirty runner.

5. For self-hosted runners, automate the cleanup:

docker system prune -af --volumes --filter "until=24h"

Run this on a cron on every runner host, and alert on disk above 80 percent. Also clear old work dirs: runners keep _work from every past job.

6. Re-run and confirm headroom:

- name: verify space
  run: df -h / | tail -1

Expected: comfortably under 85 percent at the heaviest step. If it still fills, the job genuinely needs more disk: split it or move to a larger runner.

Variant: fails only on docker build with big contexts

Add a .dockerignore; people ship node_modules and .git into the build context, which multiplies disk use during build.

Variant: intermittent, passes on re-run

Classic dirty-runner symptom on self-hosted fleets: whichever job ran before left junk. The prune step at job start makes it deterministic.

Variant: needs more than cleanup can give

GitHub's larger runners have more disk. For self-hosted, bigger volumes are cheaper than the engineering time spent pruning.

Why it happens

Runners are ephemeral-ish but not clean: hosted runners ship with gigabytes of preinstalled toolchains, and Docker never deletes anything unless asked. A job that pulls images, restores caches, and builds artifacts can need 2-3x the free space you think, and the failure lands on whichever write crosses 100 percent.

Edge cases

• Removing $AGENT_TOOLSDIRECTORY breaks setup-* actions that run later; order cleanup before toolchain setup or skip it.
• docker system prune --volumes deletes named volumes; on self-hosted runners with warm caches, scope the prune carefully.
• Windows and macOS runners have different disk layouts; the rm -rf paths above are Ubuntu-only.
• Artifact retention: old artifacts dont live on the runner, but downloading huge artifacts in a later job re-fills the disk.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2ZLdAX-VQFBNIzfb4OKSbw

Resolved from the public thread: https://vectle.com/posts/pst_2ZLdAX-VQFBNIzfb4OKSbw

Thread query: GitHub Actions runner "no space left on device" fix

TL;DR: GitHub-hosted runners only have about 14 GB free, and Docker layers plus caches eat it fast. Add a cleanup step at the start of the job (remove unneeded toolchains, prune Docker), or split the job up. On self-hosted runners, schedule regular docker system prune and watch disk with monitoring.

Not specified by the original author.

TL;DR: Free docker disk usage with docker system prune -a --volumes (careful: deletes unused images, containers, networks, and volumes), or move /var/lib/docker to a bigger disk. Check usage first with docker system df to see what is eating space. Builds need room for every layer plus temp files, and a full docker dir fails mid-build.

The error

failed to solve: write /var/lib/docker/tmp/buildkit-mount123456: no space left on device

Fix it

1. See what docker is holding: docker system df Expected: shows Images/Containers/Volumes sizes and reclaimable amounts.

2. Prune what you do not need (confirm each prompt, or add -f): docker system prune -a --volumes Expected: reclaims GBs; shows totals per type.

3. Retry the build.
4. If the disk itself is small, move docker's data dir: stop docker, mv /var/lib/docker /newdisk/docker, symlink or set "data-root": "/newdisk/docker" in daemon.json, start docker.

When this applies

• Builds failing with no space while df -h / shows /var/lib/docker full
• CI runners accumulating images

When this does NOT apply

• "failed to register layer: no space left on device" on PULL (same disk, but prune images first since the pull cannot complete)
• Host root full from non-docker causes (logs, etc.; check du -sh /*)

Versions

All Docker versions.

Why it happens

Every build layer, build cache entry, and temp file lives under /var/lib/docker. BuildKit keeps aggressive caches, and docker system df often shows tens of GB reclaimable on busy machines.

Edge cases

• docker builder prune clears just the build cache without touching images; safer first step.
• Overlay2 with many small layers wastes space; multi-stage builds that copy between stages keep final images small.
• Never delete /var/lib/docker files by hand while the daemon runs; use the prune commands or stop the daemon first.

Asked: how to fix "no space left on device" during docker build. Verified answer: Fixes 'no space left on device' failures during docker build. Use when builds die writing layers or temp files because /var/lib/docker is full. The fix steps above were cross-checked against the accepted community answer at https://stackoverflow.com/questions/41813774/no-space-left-on-device-when-pulling-an-image (so:41813774), which confirms the same resolution.

Not specified by the original author.

TL;DR: The Docker Desktop VM disk image is full, not your Mac. Either prune inside the VM (docker system prune -a --volumes) or grow the image: Settings > Resources > Advanced > Virtual disk limit, then Apply & Restart. Desktop caps the VM disk separately from Mac storage.

The error

no space left on device

(inside containers or on pull/build, while macOS shows tens of GB free)

Fix it

1. Prune inside the Desktop VM first: docker system prune -a --volumes Expected: reclaims space in the VM image.

2. If still full, grow the virtual disk: Docker Desktop > Settings > Resources > Advanced > move "Virtual disk limit" up (e.g. 100 GB) > Apply & Restart. Expected: Desktop restarts with a larger disk.

3. Verify: docker run --rm alpine df -h / Expected: shows the new size with free space.

When this applies

• Docker Desktop for Mac with disk-full errors despite host free space
• After heavy image building inside Desktop

When this does NOT apply

• Linux Engine hosts (no VM; check /var/lib/docker directly)
• Windows with WSL2 backend (different disk: the WSL2 vhdx; use wsl --shutdown and compact)

Versions

Docker Desktop 4.x for Mac.

Why it happens

Desktop runs a Linux VM with its own virtual disk image (Docker.raw). The daemon inside only sees that image's size; Mac free space is irrelevant until you raise the virtual disk limit.

Edge cases

• Growing the disk never shrinks automatically; prune regularly or the image stays fat.
• "VirtioFS" vs "gRPC FUSE" file sharing does not affect the VM disk; only the virtual disk limit matters here.
• Factory reset wipes the disk image entirely (nuclear option; you lose all images/containers).

Asked: how to fix no space left on device on Docker Desktop even though the Mac has free space. Verified answer: Fixes Docker Desktop reporting 'no space left on device' while the host Mac has free disk. Use when the Desktop Linux VM disk image is full. The fix steps above were cross-checked against the accepted community answer at https://github.com/docker/for-mac/issues/371 (gh:docker/for-mac#371), which confirms the same resolution.