Docker build failing: no space left on device

docker build failed while writing under Docker's data directory:

ERROR: failed to solve: write /var/lib/docker/tmp/...: no space left on device

The root filesystem still appeared to have space, so I checked Docker's actual storage location, its objects, and inode usage before deleting anything.

Diagnose the full filesystem

# Docker's data root may not be /var/lib/docker
docker info --format '{{.DockerRootDir}}'
 
# Filesystem capacity and inode capacity are separate limits
df -h
df -ih
 
# Docker's estimate, including reclaimable data
docker system df -v

A filesystem can report free gigabytes and still fail if it has exhausted inodes. Docker can also use a separate mount or partition that is full while / is not.

Reclaim only what you understand

If build cache is the main consumer, prune the builder cache first:

docker builder prune

Docker shows what it plans to remove and asks for confirmation. On a disposable CI runner, an age filter is safer than erasing the entire cache:

docker builder prune --filter 'until=168h'

If unused images are the problem, inspect them and then remove only unused images:

docker image ls
docker image prune -a

docker image prune -a removes images not referenced by any container. The next build or deployment may need to pull them again, so confirm that is acceptable first.

Be careful with system prune

docker system prune has a broader scope: stopped containers, unused networks, dangling images, and build cache are candidates. -a expands image removal to all unused images.

docker system prune

Do not add --volumes by habit. Docker intentionally does not prune volumes by default because volumes can contain persistent data. The --volumes option also makes unused anonymous volumes eligible for deletion.

On a shared host, I would not automate docker system prune -a --volumes. Prefer a dedicated runner, BuildKit garbage-collection policy, registry retention, or a narrowly scoped builder-cache cleanup.

Verify the recovery

df -h
df -ih
docker system df
docker build --progress=plain -t my-app:test .

If space disappears again quickly, identify the growing object rather than scheduling increasingly aggressive deletion. Common causes include an unlimited local image history, very large build contexts, package-manager caches copied into layers, and application logs stored under Docker's data root.

For image-size reduction, see reducing a Docker image with multi-stage builds. For CI cache behavior, use the Docker build cache troubleshooting fix.

Sources

• Docker: system prune reference
• Docker: builder prune reference
• Docker: system disk usage reference