Recover from Docker “no space left on device”

“No space left on device” can mean exhausted bytes, inodes, a storage quota, or a full Docker Desktop disk image. First locate the failing storage path. Deleting random images may not help if the full filesystem belongs to a bind mount, another builder, or containerd.

Inspect usage and storage location

docker system df -v
docker info --format '{{.DockerRootDir}}'

On the daemon's Linux host, check the relevant filesystem with df -h PATH and df -i PATH, replacing PATH with the verified storage location. With a remote context, run host filesystem checks on that remote host. Docker Desktop stores Linux engine data inside its VM disk rather than at an ordinary host /var/lib/docker directory.

Modern installations using the containerd image store can keep image and snapshot data in a separate containerd location. Docker's data-root does not necessarily cover every byte. Logging-driver files and other host storage can also fall outside the totals you expected from image listings.

Remove the resources you have reviewed

System pruning can remove stopped containers and then images they previously referenced. Do not assume every image used by a stopped container is protected throughout a combined system prune. Current system prune --volumes additionally prunes unused anonymous volumes; it is not a blanket deletion of every unused named volume.

Preserve retained data and images before pruning. If the daemon cannot start, expand capacity or free verified unrelated host files first. Do not manually remove internal Docker or containerd storage objects.

Bound future container logs

A daemon configuration can set JSON-file rotation defaults:

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

Merge these settings into the actual daemon configuration instead of overwriting unrelated keys. Apply the daemon configuration through the supported procedure, then recreate affected containers to use the new defaults. Existing containers do not acquire new logging options merely because the daemon restarts.

Docker explicitly warns against external manipulation of JSON-file logs. Do not truncate or delete *-json.log files behind the daemon. Preserve needed evidence and use a planned container replacement or supported logging configuration. Also control application log files inside volumes separately.

FAQ

Why did df barely change after cleanup?

Content may be shared, deleted files may still be open, or the full path may be elsewhere. On Linux, lsof +L1 can help locate deleted-open files where permissions permit. Restart only the owning workload when appropriate, rather than reflexively restarting the whole engine. Desktop host disk reclamation also has VM-specific behavior.

Should pruning run in cron?

Only with a retention policy, concurrency considerations, and recorded outcomes. A blind weekly system prune can remove intentionally stopped workloads and useful cache.

Can I move Docker to a larger disk?

Yes, through a planned, stopped-service migration using the applicable storage-backend documentation, backups, permissions, and rollback checks. Changing data-root does not automatically migrate all existing data or containerd's separate store.

After recovery, Guance disk metrics can track capacity and inodes on the relevant mount. Set thresholds using growth rate and recovery time, while using Docker and host evidence to identify the actual owner of usage.

See system prune, JSON-file logging, and daemon storage configuration.