Fix "no space left" on Docker
Quick Answer: The "no space left" error in Docker typically indicates that the Docker daemon's storage backend (often located at /var/lib/docker) has exhausted its available disk space, preventing new images, containers, or volumes from being created or updated. Your first action should be to run `docker system prune -a` to reclaim space from unused Docker objects. Expect to see a significant amount of disk space freed, allowing Docker operations to resume normally.
What Causes This Error
- Accumulation of dangling images, stopped containers, and unused volumes that consume significant disk space within Docker's storage directory.
- Large build caches from frequent image builds, especially multi-stage builds or builds with many intermediate layers that are not properly cleaned up.
- Container logs growing uncontrollably due to verbose application logging or misconfigured log rotation policies, filling the host's filesystem.
- Docker's storage driver (e.g., OverlayFS, Btrfs) experiencing filesystem-level issues or misconfigurations on the host, leading to inaccurate space reporting or actual exhaustion.
- Host filesystem where /var/lib/docker resides is genuinely full due to other non-Docker applications or data, impacting Docker's ability to store its assets.
Step-by-Step Fixes
Fix 1: Reclaim Disk Space with Docker Prune Commands
Execute `docker system prune -f` to remove all stopped containers, dangling images, unused networks, and build cache. Use `-a` for more aggressive cleanup (all unused images, not just dangling).,For specific volume cleanup, run `docker volume prune -f` to remove all unused local volumes.,To clean up build cache specifically, use `docker builder prune -f` or `docker builder prune --all -f`.
Fix 2: Manage Container Log Files Effectively
Identify large log files by inspecting containers: `docker ps -a -s` to see container size, then `docker inspect <container_id> --format='{{.LogPath}}'` to find log file path.,Configure log rotation for new containers by adding `logging` options in `docker run` or `docker-compose.yml`. Example: `--log-opt max-size=10m --log-opt max-file=3`.,For existing containers, stop them, manually truncate their log files (`truncate -s 0 /var/lib/docker/containers/<container_id>/<container_id>-json.log`), then restart. Consider updating their logging configuration.
Fix 3: Increase Host Filesystem Capacity or Relocate Docker Data
Check host disk usage with `df -h` to confirm the filesystem where `/var/lib/docker` resides is full. Identify and remove non-Docker large files if present.,If the host filesystem is genuinely undersized, consider expanding the virtual disk (for VMs) or adding more physical storage.,Alternatively, relocate the Docker data root to a larger filesystem by editing `/etc/docker/daemon.json` to include `"data-root": "/path/to/new/docker-data"` and restarting the Docker daemon (`sudo systemctl restart docker`).
Fix 4: Optimize Docker Image and Build Processes
Review Dockerfiles to minimize image layers and reduce image size. Use multi-stage builds to discard build-time dependencies.,Ensure `.dockerignore` files are correctly configured to exclude unnecessary files from the build context.,Regularly pull updated base images to benefit from smaller, optimized versions and ensure `docker system prune` effectively removes older layers.
Advanced Fixes
Advanced Fix 1: Configure Docker with a Dedicated Storage Device or LVM Volume
Provision a dedicated block device or Logical Volume Manager (LVM) volume for Docker's data root, ensuring it has ample space and performance characteristics.,Stop the Docker daemon: `sudo systemctl stop docker`. Move existing `/var/lib/docker` contents to the new device/volume: `sudo mv /var/lib/docker /path/to/new/device/docker-data`.,Update `/etc/docker/daemon.json` to point `data-root` to the new location (e.g., `"data-root": "/path/to/new/device/docker-data"`) and restart the Docker daemon: `sudo systemctl start docker`.
FAQs
Q: What is the primary location Docker uses for storage, and how can I check its usage?
A: Docker primarily stores images, containers, and volumes in `/var/lib/docker` by default. You can check its disk usage using `du -sh /var/lib/docker` for a summary or `df -h /var/lib/docker` to see the filesystem usage where it resides.
Q: Does `docker system prune -a` remove everything, including running containers?
A: No, `docker system prune -a` is designed to be safe for running containers. It removes all stopped containers, all networks not used by at least one container, all dangling images, and all build cache. The `-a` flag also removes all *unused* images (not just dangling ones), but it will not touch images used by running containers.
Q: Can I prevent log files from filling up my disk without manually truncating them?
A: Yes, you can configure logging drivers and options for your containers. For example, using the `json-file` driver with `max-size` and `max-file` options (e.g., `--log-opt max-size=10m --log-opt max-file=3`) will automatically rotate logs, preventing them from growing indefinitely. This should be configured when creating or updating containers.
Q: My `docker system prune` didn't free up much space. What else could be consuming space?
A: If `docker system prune` is ineffective, check for: 1) Large container log files not managed by log rotation (as per fix above). 2) Docker volumes that are still referenced by stopped containers (use `docker volume ls -qf dangling=true` to find truly unused ones). 3) The host filesystem itself being full with non-Docker data, or a misconfigured storage driver. Inspect `df -h` and `du -sh /var/lib/docker` to confirm.