"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: Add a step that shows disk usage with df -h, delete the big things you do not need (docker images, Android SDK, .NET, npm or pip caches), and rerun. If it still does not fit, move the job to a larger runner. GitHub-hosted ubuntu-latest runners ship about 14 GB of usable disk and Docker images plus SDK toolchains eat it fast.

No space left on device

The fix

1. Add a diagnostic step at the top of the job to see where the space went:

   df -h /
   sudo du -sh /usr/share/dotnet /usr/local/lib/android /opt/hostedtoolcache 2>/dev/null | sort -rh

   Expected: Filesystem shows the free space on / and the three biggest preinstalled dirs.

2. Delete what you do not need before the heavy step. A typical reclaim:

   sudo rm -rf /usr/share/dotnet
   sudo rm -rf /usr/local/lib/android
   sudo docker image prune --all --force
   df -h /

   Expected: df shows several GB freed.

3. If your own build produces the bulk (node_modules, target/, .gradle), clean caches between steps: npm cache clean --force, cargo clean, or stop gradle and remove the build cache.
4. Rerun the job and confirm the df line shows headroom; the failing step should pass unchanged. If the job genuinely needs more disk (large containers, Android emulator images), move it to a larger GitHub-hosted runner instead of fighting the small one.

When this applies

• a previously green job fails with No space left on device
• build or docker build steps die with ENOSPC or write errors
• you added dependencies, caches, or artifacts and the job started failing

When it does NOT apply

• the error is in your application code writing to a path that does not exist - that is a code bug, not disk
• self-hosted runners - resize or mount more disk on the host instead

Compatibility

GitHub-hosted ubuntu-latest (about 14 GB usable); the reclaim step below is Linux-only, adjust paths on Windows and macOS images.

Variants of this error

ENOSPC: no space left on device, write

The errno form the same failure takes in Node and build tools.

write /dev/stdout: no space left on device

What a shell step prints when the disk fills mid-write.

Why it happens

The runner image comes with preinstalled toolchains (dotnet, Android, GHC, hostedtoolcache) that most workflows never use. Each docker pull and each cached dependency dir adds on top. When free space hits zero, the step writing at that moment throws - the error names the symptom, not the hog.

Edge cases and pitfalls

• docker image prune only helps if the job actually pulls images; for pure language builds the SDK deletes matter more.
• Caches restore the same big cache every run - if a cache dir holds gigabytes of stale layers, delete and re-save the cache.
• Windows runners have more disk but slower deletes; do the cleanup before the heaviest step anyway.

Fixed in timfarmr/bar-replay@0032abb4: a job failed with No space left on device; the fix reclaims runner disk before the heavy step.