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

```text
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.