How to Fix "docker no space left on device" Error on Linux

The "docker no space left on device" error happens when Docker exhausts all available disk space or run out of available inodes on the underlying Linux filesystem. Docker accumulates unused build caches, stopped containers, dangling images, and anonymous volumes under /var/lib/docker over time. Reclaiming disk space requires running targeted system pruning commands or relocating Docker's storage root directory.

The Problem

During operations such as docker pull, docker build, or creating new containers, execution fails abruptly. The engine prints one of these exact disk allocation errors:

ERROR: failed to solve: write /var/lib/docker/buildkit/containerdmodules/...: no space left on device

Or during a container execution or image pull:

Error response from daemon: write /var/lib/docker/tmp/GetImageBlob123456789: no space left on device

failed to register layer: Error processing tar file(exit status 1): write /usr/local/bin/node: no space left on device

Why It Happens

Docker does not automatically clean up unused runtime artifacts. Over time, heavy container churn causes storage depletion in several areas:

• Dangling Images & Layers: Un-tagged <none>:<none> intermediate build images accumulate in /var/lib/docker/overlay2.
• BuildKit Cache: Modern Docker builds store large build caches in /var/lib/docker/buildkit without automatic size caps.
• Orphaned Volumes: Stopped containers leave anonymous volumes behind containing unused database data or build artifacts.
• Exhausted Inodes: Hundreds of thousands of tiny files created by node_modules or package managers consume 100% of available file system inodes, even if physical disk gigabytes remain.

The Fix

You can reclaim space immediately by performing a deep system cleanup and removing accumulated Docker artifacts.

Step 1: Check overall disk and inode usage

Verify if the issue is raw disk capacity or inode exhaustion:

df -h /var/lib/docker
df -i /var/lib/docker

Step 2: Perform a comprehensive Docker system prune

Run docker system prune with the -a (all unused images, not just dangling) and --volumes flags to purge unused containers, networks, images, and anonymous volumes:

docker system prune -a --volumes -f

Step 3: Clear BuildKit cache explicitly

The standard system prune command does not always clear all BuildKit caches. Run this command to purge build cache objects specifically:

docker builder prune -a -f

Step 4: Truncate oversized container log files

Huge stdout/stderr log files in /var/lib/docker/containers/ often consume gigabytes of storage silently. Truncate all JSON log files across active containers without stopping them:

sudo sh -c 'truncate -s 0 /var/lib/docker/containers/*/*-json.log'

To prevent logs from filling your disk in the future, set log limits in /etc/docker/daemon.json:

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

Still Not Working?

If your root partition (/) is too small to handle Docker data long-term, relocate Docker's default data root from /var/lib/docker to a larger secondary disk or partition (e.g., /mnt/data/docker).

1. Stop the Docker service:

sudo systemctl stop docker

2. Edit or create /etc/docker/daemon.json to add the new data-root location:

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

3. Copy existing Docker data to the new location and restart the service:

sudo rsync -aP /var/lib/docker/ /mnt/data/docker/
sudo systemctl start docker