Docker disk full: measure before you prune
When a Docker node runs out of space, identify images, containers, volumes, and logs first. A blind prune can remove data you still need.
Maintained by Kevin · Ovalk
Scope and prerequisites
Docker Engine on Linux. Docker Desktop, rootless installations and non-default data roots use different storage locations.
Determine Docker Root Dir, logging driver and the filesystem actually full. Docker socket access is highly privileged. Identify business-data volumes before considering cleanup.
Common symptoms
- docker pull or container writes fail with no space left on device.
- The node root filesystem is nearly full.
- Container logs stop or workloads begin to restart.
1. Identify the kind and location of pressure
Check both block space and inodes, then compare Docker’s own accounting with filesystem usage. JSON container logs, anonymous volumes, and build cache require different responses.
df -h; df -i
docker system df -v
docker info --format "{{.DockerRootDir}}"2. Release only known-safe space
Use supported log rotation; do not manually truncate or delete Docker-managed JSON logs. Changed daemon defaults do not reconfigure existing containers. The prune example deletes build cache and requires an approved inventory of what can be rebuilt. Review volumes separately and address continuous writes.
State-changing example below — confirm authorization, scope and recovery before executing.
docker ps -a --size
docker builder prune --filter "until=168h"3. Verify recovery beyond free bytes
Confirm critical workloads can write again, log shipping is healthy, and alerts will fire earlier next time.
docker ps --format "table {{.Names}}\t{{.Status}}"
journalctl -u docker --since "30 min ago" --no-pagerInterpret the evidence
| Observation | What to check next |
|---|---|
| Inodes full; bytes available | Look for many small files on that mount; deleting one large image may free little inode capacity. |
| Reclaimable build cache | Check who uses the builder and which caches are needed. Pruning removes cache and can slow later builds. |
| Large container log | Check its logging driver. Do not directly truncate or delete Docker-managed JSON log files. |
Illustrative diagnosis
A hypothetical example to explain the reasoning, not a reported customer incident or a claim of testing on your stack.
docker system df reports modest image use, but the Docker filesystem is nearly full. A chatty container uses the json-file driver without a size limit. Deleting images will not address the continuing log growth. Reduce the noisy source, arrange supported log handling, then recreate affected containers with explicit rotation settings after assessing interruption.
Verify recovery
- Check both block and inode headroom and whether new image pulls and application writes succeed.
- Watch growth after normal traffic resumes. Docker daemon log defaults do not update existing containers automatically.
Rollback and stopping point
Save container definitions and logging configuration before recreation. Pruned images and caches require pulling or rebuilding; deleted volume data requires a backup. Prefer temporary capacity expansion if ownership is unclear.
Prevention and long-term repair
- Set container log rotation and size limits.
- Budget images, runtime data, and business data separately.
- Alert on both disk capacity and inode consumption.
References and corrections
Use the documentation for your installed version. The references below explain the underlying behavior; commands still need environment-specific validation.
Report a correction to Kevin — include the page URL, version and a redacted reproduction. See our editorial policy.