Fix Docker "No Space Left on Device" Error

Quick Answer

• Conclusion: The "no space left on device" error in Docker is almost always caused by accumulated unused images, containers, volumes, and build caches consuming disk space. The fix is systematic cleanup.
• First checks: Run df -h to confirm disk usage, then docker system df to see how much space Docker resources are consuming.
• Minimal fix: Execute docker system prune -a -f to remove all unused images, containers, and networks. If space is still low, add docker volume prune -f and check container log files.
• Environment: This applies to Docker Engine on any Linux distribution, Docker Desktop on macOS/Windows, and any Docker version 1.13 or later (which introduced the prune command).

What Problem It Solves

Docker stores images, containers, volumes, and build caches on disk. Over time, these accumulate:

• Dangling images – layers no longer referenced by any tagged image
• Unused containers – stopped containers that still occupy disk space
• Build cache – intermediate layers from docker build commands
• Container logs – JSON log files that grow without bound unless configured otherwise

When any of these exhaust the available disk space on the partition where Docker stores its data (typically /var/lib/docker), new operations like docker pull, docker build, or docker run fail with the "no space left on device" error.

Root Cause Analysis

The error surfaces in several forms, each pointing to the same underlying disk exhaustion:

The root cause is rarely a single large file. It is the cumulative weight of:

• Many old images from different tags or builds
• Stopped containers that were never removed
• Build cache from repeated docker build runs
• Container stdout/stderr logs that have grown to gigabytes

Minimal Working Configuration

Immediate Cleanup Commands

Run these in order, from safest to most aggressive:

BASH
# Step 1: See what is consuming space
docker system df

# Step 2: Remove all unused containers, networks, and dangling images
docker system prune -f

# Step 3: Remove all unused images (not just dangling)
docker system prune -a -f

# Step 4: Remove unused volumes (WARNING: destroys data not used by any container)
docker volume prune -f

# Step 5: Clear BuildKit cache (if using BuildKit)
docker builder prune -f

Prevent Recurrence: Log Rotation Configuration

Container logs are a common hidden space consumer. Configure log rotation in /etc/docker/daemon.json:

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

After editing, restart Docker: sudo systemctl restart docker. Existing containers will not be affected; only new containers will use these limits.

Common Errors and Fixes

Error: Cannot delete image – image is being used by running container

Error: No such image: <image_id>
Error response from daemon: conflict: unable to delete <image_id> (cannot be forced) - image is being used by running container <container_id>

Fix: Stop and remove the container first, or use docker system prune which automatically skips in-use resources.

BASH
docker stop <container_id>
docker rm <container_id>
docker image rm <image_id>

Error: Prune command hangs waiting for confirmation

WARNING! This will remove all dangling images. Are you sure you want to continue? [y/N]

Fix: Add the -f (force) flag to skip interactive prompts. This is essential for scripts and cron jobs.

BASH
docker system prune -a -f

Error: Cannot remove image tag – container references it

Error response from daemon: conflict: unable to remove repository reference "<image>:<tag>" (must force) - container <container_id> is using its referenced image <image_id>

Fix: Clean up stopped containers first, then remove the image.

BASH
docker container prune -f
docker image rm <image_id>

Error: No space left during pull or build

Error processing tar file(exit status 1): write /var/lib/...: no space left on device

Fix: This indicates the disk is completely full. Run the aggressive cleanup sequence immediately. If that does not free enough space, check and truncate container log files:

BASH
# Check log file sizes
ls -lh /var/lib/docker/containers/*/*-json.log

# Truncate all log files (safe, Docker will recreate them)
truncate -s 0 /var/lib/docker/containers/*/*-json.log

Production Notes and Security Checks

• Never use --volumes with prune in production unless you are certain all volumes are disposable. Volumes hold persistent data (databases, uploads, configuration). The docker volume prune command removes volumes not attached to any container, and this data cannot be recovered.
• Schedule cleanup during low-traffic periods. Running docker system prune while builds or deployments are in progress can cause failures. In CI/CD pipelines, place cleanup steps outside the main build workflow.
• Ensure the executing user has Docker permissions. Scripts run by cron or systemd must run as a user in the docker group or as root. Otherwise, the Docker socket connection will fail.
• Avoid Docker data directories on NFS. Network filesystems introduce latency and locking issues that can cause prune operations to hang or fail. Use local SSD or NVMe storage for /var/lib/docker.
• Monitor proactively. Set up disk usage alerts on the Docker data partition. A cron job that runs docker system prune -a -f --filter "until=24h" daily can prevent the error from occurring in the first place.

FAQ

Q: I ran docker system prune -a and all my images were deleted. How do I recover them?

A: You cannot recover them from Docker's local storage. You must re-pull or rebuild them. If you have a docker-compose.yml or Dockerfile, run docker-compose pull or docker-compose build. If you do not have these files and the images are not in a remote registry, they are permanently lost. Always verify that images are available remotely before running aggressive prune commands.

Q: Why did docker system prune not free up much space?

A: Several possible reasons: (1) Container log files are not cleaned by prune – check and truncate them manually. (2) Volumes are not removed unless you explicitly run docker volume prune. (3) BuildKit cache may remain – run docker builder prune. (4) The disk space issue may not be Docker-related – use df -h to check other directories like /var/log or /tmp.

Q: How can I automate cleanup to prevent this error from recurring?

A: Three approaches: (1) Add a cron job that runs docker system prune -a -f --filter "until=24h" daily. (2) Configure log rotation in /etc/docker/daemon.json as shown above. (3) In CI/CD pipelines, add a cleanup step at the end of each pipeline run. For production servers, combine all three for defense in depth.