Docker "No Space Left on Device" Error Fix

Docker's "no space left on device" error almost always means Docker's own storage — accumulated images, stopped containers, unused volumes, and build cache — has filled up the disk, even when the actual host machine appears to have free space in normal directories.

The Problem

Commands like docker build, docker pull, or even starting a container fail with:

no space left on device
write /var/lib/docker/...: no space left on device

Running df -h on the host might show plenty of free space in /home or other directories, which is confusing until you realize Docker stores everything in its own dedicated location, separate from typical user disk usage.

Why It Happens

Docker accumulates disk usage in several categories that aren't automatically cleaned up over time:

• Old, unused images from previous builds that were never removed, especially with frequent rebuilds during development creating a new image layer each time
• Stopped containers that still exist on disk (Docker doesn't delete a container automatically when it stops, only when explicitly removed)
• Dangling images — intermediate layers left behind from builds, particularly common with multi-stage builds or repeated builds that overwrite a tag without cleaning up the previous version
• Build cache, which can grow substantial over time, especially with frequent builds during active development
• Unused volumes, which persist even after the containers that created them are removed, since Docker doesn't assume volume data is safe to delete automatically

The Fix

First, check how much space Docker itself is actually using, broken down by category:

docker system df

This shows separate totals for images, containers, volumes, and build cache, making it clear which category is the biggest contributor before you start cleaning anything.

Remove stopped containers that are no longer needed:

docker container prune

Remove dangling images (untagged intermediate layers) safely, since these are almost never needed after a build completes:

docker image prune

To also remove unused images that aren't currently referenced by any container (not just dangling ones), use the more aggressive flag — but be aware this removes any image not actively in use, including ones you might want to keep for quick reuse later:

docker image prune -a

Clear build cache, which can grow significantly over time with frequent builds:

docker builder prune

For volumes specifically, be more careful — unlike images and containers, volumes often contain actual data (database contents, uploaded files) that you genuinely want to keep. Review what exists before removing anything:

docker volume ls
docker volume prune

docker volume prune only removes volumes not currently attached to any container, but confirm you're not about to delete something important before running it, especially in a production environment.

For a comprehensive cleanup across all categories at once, once you've reviewed what exists:

docker system prune -a --volumes

This is the most aggressive option — it removes all unused images, stopped containers, unused networks, and unused volumes in one command. Use it deliberately, not as a routine habit, since it can remove things you intended to keep around for later reuse.

Still Not Working?

If Docker's own cleanup doesn't free enough space, check whether Docker's storage driver is configured to use a specific disk partition that's smaller than you expect, separate from the rest of the host's storage — common in cloud VM setups where the root disk and a separate data disk exist, and Docker was configured (or defaulted) to use the smaller one. Checking docker info for the "Docker Root Dir" path and then running df -h specifically against that path (not just the general root filesystem) confirms whether Docker is genuinely constrained to a smaller allocation than the rest of the machine.