no space left on device

Before you start

• A terminal on the Docker host as root or a docker group member (root-equivalent), with sudo to run du inside Docker's data directory.
• The location of Docker's data directory from docker info --format '{{.DockerRootDir}}', which is /var/lib/docker by default on Linux.
• A list of the volumes holding data you must keep, and a backup of any you are unsure about, before you run any prune command.
• Permission and a maintenance window to restart the Docker daemon if you change daemon.json. Docker applies new log settings only after a restart, and only to containers created afterwards.
• On Docker Desktop, access to Settings > Docker Engine, which is where daemon.json is edited.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Check it with a tool

• Image vs container — where the space actually goes→
• Check the Dockerfile for build hygiene→
• Docker volume vs bind mount: where the data lives→

Or diagnose it manually

In this order. The first command usually contains the whole answer.

1. Step 1

   docker system df

   One command that attributes the usage across images, containers, volumes and build cache, with a reclaimable figure for each.

   Look for The largest RECLAIMABLE value. That is where the space is, and it is usually build cache or volumes.

2. Step 2

   df -h $(docker info --format '{{.DockerRootDir}}')

   Confirms the full filesystem is Docker's before you delete anything.

   Look for Use% at or near 100 on the filesystem holding Docker's data root.

3. Step 3

   docker system df -v | head -40

   The per-object breakdown, which names the specific volumes and images consuming the space.

   Look for Individual volumes or images large enough to explain the shortfall.

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

docker system df

docker builder prune -a

# Then cap it, in daemon.json:
# { "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } } }

docker images -f dangling=true --format 'table {{.ID}}	{{.Size}}' | head -20

docker image prune

docker volume ls -qf dangling=true | wc -l && docker system df -v | head -30

# Look first.
docker volume ls -f dangling=true

# Then, if you are sure (--all includes named volumes):
docker volume prune --all

sudo sh -c 'du -sh /var/lib/docker/containers/*/*-json.log' 2>/dev/null | sort -h | tail -10

# daemon.json
{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }

df -h $(docker info --format '{{.DockerRootDir}}') && df -h /

How to know it is actually fixed

• ✓docker system df shows the reclaimable figure substantially reduced.
• ✓df -h shows the filesystem back below its threshold.
• ✓The build or run that failed now completes.

Stopping it happening again

• Cap the build cache in the daemon config. This is the single highest-value setting on a build host, and it removes the most common cause entirely.
• Configure log rotation before you need it. The default is unbounded, which is fine for a laptop and not for anything long-lived.
• Prune on a schedule rather than in response to a failure — a weekly docker system prune on a build host keeps cache, dangling images and stopped containers in check (volumes and logs need their own handling).
• Treat volume pruning as a separate, deliberate act with the list read first. It deletes the most, but it is not the only loss: docker system prune also removes every stopped container and anything written inside it.

Security considerations

• docker volume prune --all and docker volume rm delete data permanently. Docker's documentation says volumes are never removed automatically "because to do so could destroy data". List the candidates with docker volume ls -f dangling=true and back up anything you cannot recreate first.
• docker system prune removes every stopped container, and with it anything written inside those containers. Check docker ps -a for containers you meant to restart or inspect before you run it.
• Be careful with -f in scheduled prune jobs: it skips the confirmation prompt that warns what will be removed. Never schedule docker volume prune --all -f, and protect volumes you keep with a label and --filter "label!=keep", as Docker's pruning guide shows.
• Do not edit or truncate files under Docker's containers directory by hand. Docker's json-file documentation says these files are for the daemon only and that other tools can interfere with its logging. Set rotation and recreate the container instead.
• Container logs hold whatever the application printed, which can include tokens or personal data. Setting max-size and max-file also limits how much of that history stays on disk.