What Causes a Container to Fill the System Disk When Its Data Is Elsewhere?
A container can fill the system disk when logs, caches, temporary files, or accidental writes remain inside Docker’s local storage.
Moving a media library or database volume to another pool does not move the container image, writable layer, JSON log, BuildKit cache, metadata, or any path that was omitted from the mount list. A failed external mount can also leave the expected host directory empty, causing the application to write new data into the system disk without an obvious error.
Measure the Docker Root Before Inspecting Application Data
Check the filesystem containing Docker’s data root and compare host directory sizes with Docker’s image, container, volume, and build-cache accounting. Record usage before deleting anything.
A Cloudron user found /var/lib/docker/overlay2 consuming more space than all visible application data, showing why the Docker storage root must be measured independently from external libraries.
If the system disk is full but the external pool has space, identify whether growth sits under containers, overlay layers, volumes, images, or build cache. Do not run a broad prune until active and recoverable data are classified.
Check for Unbounded Container JSON Logs
Inspect the log driver and the size of each container log file. A service can store its primary data elsewhere while stdout and stderr grow indefinitely under Docker’s local container directory.
Code Maven documents a case where docker system df did not reveal the main issue because the default log file kept growing outside that summary. The hidden consumer was an ever-growing container log.
Find and fix the noisy application error before rotating or truncating logs. Configure bounded log rotation for future containers and verify the new files stop growing at the expected limit.
Find Data Written Into the Container Writable Layer
Compare the intended persistent paths with the application’s real cache, transcode, download, database, thumbnail, backup, and temporary directories. Any unmounted write remains in the container’s writable layer on the system disk.
A Docker forum explanation notes that writes and changed image files are stored in the writable layer, while large unrotated logs live in container metadata. Both can make one container consume nearly all local space despite an external data volume.
Use per-container size reporting and inspect the largest changed paths inside the container. Add explicit bind mounts or named volumes only for data that must persist, then recreate the container to discard obsolete writable-layer content after backing up anything valuable.
Verify the External Mount Was Present When the Container Started
Check that the SSD, NAS share, or storage pool was mounted at the expected host path before Docker launched the container. Compare device identity and mount output with the directory the container sees.
When an external mount is absent, the underlying empty directory on the system filesystem may still exist. The container can write normally into that fallback directory, making the system disk grow while the external pool appears untouched.
Stop the container before remounting storage over populated fallback data. Move or reconcile the hidden files safely, add mount dependencies or startup checks, and refuse application startup when the expected device is missing.
Inspect Image Layers, Build Cache, and Abandoned Objects
Review unused images, stopped containers, anonymous volumes, and BuildKit cache. Frequent updates or local builds can accumulate many layers even when the application’s persistent data is correctly mounted elsewhere.
A Moby-project forum explanation clarifies that overlay mounts can make disk figures confusing and that the underlying filesystem usage must be interpreted carefully. A separate Home Assistant case also showed overlay2 growth from logs and layers over time.
Remove only objects confirmed unused by current Compose projects and backups. Never delete individual overlay2 directories manually, because Docker’s metadata references can become inconsistent.
Validate the Fix With a Growth Baseline
After correcting the responsible path, record Docker-root usage, log sizes, container writable sizes, and external-pool usage at regular intervals through the workload that previously caused growth.
The ZimaSpace workflow for staging a large NAS transfer provides a repeatable load for confirming that data lands on the intended pool.
The issue is fixed only when system-disk growth matches expected image and log behavior, persistent application data grows on the external pool, and a missing external mount causes a safe startup failure instead of silent writes to the root filesystem.
Recommended products
Support & Tips
More to Read
Can Plex Share a GPU With Another Docker Container?
Plex and another container can often access the same GPU, but you must test driver support, device mapping, video-engine load, memory, and recovery behavior.
How to Tell Whether a Plex Error Comes From the Client or Server
Reproduce the same item on another client, compare the session path, then collect server evidence only after scope tells you where the failure actually...
How to Configure Plex Cache and Transcode Temporary Storage
Protect persistent Plex state while placing transcode temp files on suitable local storage, then verify cleanup, free space, and restart behavior.
