“No space left on device” on a Docker host: find what’s consuming the disk (images, logs, volumes, build cache) and clean each safely.
Why Docker hosts fill up
Full disks are the most common cause of outages on single-server Docker hosts, more common than crashes or traffic spikes. The mechanics are mundane: every deploy leaves image layers behind, every build adds cache, and every log line a container prints is appended to an unbounded JSON file. None of it cleans itself up, and "no space left on device" takes down everything at once: new deploys fail, databases cannot write, and even the commands to fix it can fail.
Diagnose before deleting anything
Two commands show exactly where the space went, always run them first:
docker system df -v # images, containers, volumes, build cache
df -h / # overall disk picture
du -sh /var/lib/docker/containers/*/ 2>/dev/null | sort -h | tail
# ^ per-container log sizes: the silent killer
Clean each consumer, in safety order
From completely safe to requires-thought:
- Dangling and unused images: docker image prune -af, safe, worst case the next deploy pulls layers again
- Build cache: docker builder prune -af, safe, the next build is slower, nothing is lost
- Stopped containers: docker container prune -f, safe if you do not intentionally keep stopped containers around
- Container logs: truncate oversized ones (truncate -s 0 /var/lib/docker/containers//-json.log), then fix rotation permanently (next section)
- Volumes: docker volume prune is DANGEROUS, "unused" only means no running container references it right now; a stopped database’s data volume qualifies. List them, identify each one, and remove only what you can name
Cap log growth permanently
The default json-file log driver has no size limit; a single chatty container can write gigabytes a week. Set global limits in the daemon config and this problem never returns:
/etc/docker/daemon.json
{
"log-driver": "json-file",
"log-opts": { "max-size": "20m", "max-file": "3" }
}
# then: systemctl restart docker
# note: applies to newly created containers; recreate old ones to adopt it
Automate the hygiene
One-off cleanups buy weeks; automation buys forever. Schedule a weekly prune of images, stopped containers and build cache, and alert on disk crossing 80% so you act before 100%. Peon exposes exactly this as a server cleanup action (on demand or scheduled) and shows per-server disk meters in the dashboard, deploy-heavy hosts stay healthy without anyone remembering to SSH in and prune.
Top comments (0)