Fix Docker "no space left on device" Error

The Error

You're building an image, pulling from a registry, or spinning up a container — and Docker just stops:

no space left on device

Sometimes it's buried inside a longer message:

Error response from daemon: failed to create rootfs for container: ...: no space left on device
failed to solve: failed to read dockerfile: error from sender: write /tmp/...: no space left on device
Error pulling image: write /var/lib/docker/...: no space left on device

Docker is a hoarder. Cached layers, stopped containers, dangling images, unused volumes — they accumulate silently until the disk hits its limit. That's what you're dealing with.

Check What's Actually Eating Space

Don't start deleting things blindly. Run these two commands first:

# Docker's own usage breakdown
docker system df

# Overall disk usage on the host
df -h

docker system df output looks something like this:

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          42        5         18.4GB    15.1GB (82%)
Containers      12        2         1.2GB     1.1GB (92%)
Local Volumes   8         3         4.3GB     2.1GB (48%)
Build Cache     -         -         3.8GB     3.8GB

Focus on the RECLAIMABLE column. That's how much you can recover without touching anything currently running.

Step-by-Step Fix

Step 1 — The quick fix (safe)

Docker's all-in-one cleanup command. It removes stopped containers, unused networks, dangling images, and build cache:

docker system prune

Docker shows you exactly what it's about to remove and asks for confirmation. Skip the prompt with -f:

docker system prune -f

Safest option — only touches things not currently in use. Start here.

Step 2 — Remove unused images (bigger savings)

By default, system prune only removes dangling images — untagged layers with no name. To also remove images not referenced by any container:

docker image prune -a

This can free several gigabytes on an active dev machine. The downside: base images get deleted too. They'll re-download next build, which is fine unless you're on a slow or metered connection.

Step 3 — Clean up volumes

Volumes are intentionally excluded from system prune — they might hold database data or config you actually care about. Remove unused ones explicitly:

docker volume prune

Or fold them into the all-in-one command:

docker system prune --volumes

Step 4 — Nuclear option

Want to wipe everything Docker-related in one shot? Here's the command:

docker system prune -a --volumes -f

Running containers and their images stay untouched. Everything else goes. Good for CI machines or dev environments where nothing needs preserving.

Step 5 — If the host disk is still full

Docker isn't always the culprit. Old logs, core dumps, and build artifacts pile up too. Hunt them down:

# Largest directories on the system
du -sh /* 2>/dev/null | sort -rh | head -20

# Files larger than 500MB
find / -size +500M -type f 2>/dev/null

Common offenders: /var/log bloated with app logs, core dumps in /tmp, leftover build artifacts from CI jobs.

Step 6 — Move Docker's data directory

If your root partition is small but you have a bigger mounted disk, point Docker there instead. Edit /etc/docker/daemon.json:

{
  "data-root": "/mnt/large-disk/docker"
}

Then restart Docker:

sudo systemctl restart docker

You'll need to re-pull images after the move. But if you keep hitting the limit, this fixes the root cause — not just the symptom.

Verify the Fix

Check that space came back:

df -h
docker system df

Then retry what was failing:

docker pull nginx:latest
# or
docker build -t myapp .
# or
docker run --rm hello-world

No error? You're done.

Prevent It From Happening Again

• Schedule a weekly prune on CI/build servers. A cron job running docker system prune -f once a week stops the buildup before it becomes a problem.
• Cap build cache size in /etc/docker/daemon.json:

{
  "builder": {
    "gc": {
      "enabled": true,
      "defaultKeepStorage": "10GB"
    }
  }
}

• On Docker Desktop — Settings → Resources → bump the disk image size limit. Or use the Dashboard: Troubleshoot → Clean / Purge data.
• Alert at 80%, not 100%. By the time the disk is full, builds are already failing. Set monitoring thresholds early.
• Use --no-cache when cache is stale. Old layers get replaced rather than stacked on top of each other, keeping image sizes honest.