How Do You Stop Docker Logs From Filling a Host Boot Drive?

Stop the immediate log producer, identify the active log sink, then apply bounded rotation and fix the error or restart loop creating the flood.

On a Docker-based NAS or home server, the boot drive can fill even when media and databases live on another pool because container stdout and stderr, systemd journal data, and application-native files may still remain under the system filesystem. The safe sequence is to preserve enough recent evidence, stop uncontrolled growth, classify which logging layer owns the space, configure retention for existing and future services, and verify that the underlying application no longer emits the same volume.

Locate the Log Store That Is Actually Growing

Check free space on the boot filesystem, then compare the size of Docker’s data root, per-container log files, the system journal, and application log directories mounted from the host. Record the largest paths before deleting or truncating anything.

A Docker disk-space case found that normal Docker summaries did not reveal the main consumer because the default log file grew separately. The decisive evidence was an ever-growing container log under the local Docker storage path.

Inspect each running container’s configured log driver and log path, then match the largest file with the container name and recent messages. If no container log explains the usage, continue with journald and app-native folders rather than assuming every Docker-related disk problem belongs to json-file.

Stop the Noisy Container Before Emergency Cleanup

When the boot drive is close to full, pause or stop the container producing the fastest growth. Save a bounded tail of the log, its restart count, exit state, image version, environment, mounts, and the first repeated error before reclaiming space.

Administrators commonly discover that container JSON logs can consume the remaining disk when no size limit is configured. A long-running Stack Overflow discussion identifies unbounded JSON log growth as a separate capacity risk from image and volume data.

Do not delete an active log file blindly while Docker still holds it open, and never remove arbitrary directories from Docker’s metadata tree. Use the platform’s supported rotation or truncation procedure only after stopping the producer, then confirm that reclaimed blocks are visible before restarting any affected service.

Apply Bounded Rotation to Each Long-Running Service

Set an explicit log driver and finite rotation limits in the Compose service or container configuration. For the common JSON driver, the important controls are a maximum file size and a limited number of retained files.

A Docker community rotation thread explains that options such as max-size and max-file bound how much local history one container retains. The operational requirement is a finite rotation policy, not one indefinitely growing file.

Choose limits based on how quickly an incident must be diagnosed and how much boot-disk space the host can safely reserve. Recreate the service so the running container receives the new logging configuration, then inspect its effective settings and force a small controlled test to prove files rotate as expected.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Set Defaults for Future Containers Without Assuming They Change Existing Ones

Configure a daemon- or platform-level default for newly created containers so an omitted service setting cannot silently return to unlimited local logging. Keep critical services free to use a narrower override when their diagnostic needs differ.

Changing a Docker logging default does not retroactively rewrite every existing container’s host configuration. The same community guidance distinguishes daemon defaults from per-container creation settings, so old services must be inspected and deliberately recreated.

Roll the change through one non-critical service first. Confirm that log retrieval, monitoring, alerts, and support workflows still work, then recreate the remaining services in controlled batches without removing their persistent volumes.

Fix the Event That Produces the Log Flood

Rotation limits damage, but they do not repair a container that restarts every few seconds, retries an unreachable database, logs every health check, receives an attack or request flood, or was left in debug mode after troubleshooting.

One Docker user traced an approximately 80 GB JSON log to excessive debug output, illustrating how debug-level output can overwhelm a boot drive even when rotation is the immediate safeguard.

Group repeated messages by frequency and first timestamp, then repair the earliest root error. The ZimaSpace guide to finding a restart-loop dependency is the next diagnostic when connection, mount, secret, or readiness failures generate the log storm.

Track Docker, Journald, and App-Native Logs Separately

A container can send stdout to Docker while also writing its own files into a bind mount, and the Docker service itself may send daemon events to journald. Each sink has a different retention owner and can fill the same boot filesystem independently.

Home-server operators have reported application log directories growing despite expectations that Docker-level rotation would contain them. A TrueNAS community case highlights the need to identify which logging layer owns retention before adjusting limits.

Record a post-fix baseline for boot-disk usage, largest log files, journal size, container restart counts, and daily growth. The repair is complete only when every active sink has a bounded policy, the noisy service remains stable under its normal workload, and a deliberate restart does not recreate unlimited files.