Docker on NAS causing constant HDD noise? Fix it in one afternoon

Docker containers running on a network-attached storage (NAS) device often turn what should be a silent, always-on storage solution into a relentless noise machine. The culprit isn't the NAS hardware itself—it's the way Docker interacts with mechanical hard disk drives (HDDs). These drives are designed for steady, sequential reads and writes, but Docker thrives on random, scattered input/output operations that force HDDs to seek constantly. The result: a humming, clicking symphony that drowns out late-night meetings and early-morning calls.

After living with this problem for months, I found a straightforward solution that reduced drive noise by nearly 100% in a single afternoon. The key is reassigning Docker’s resource-intensive operations from the HDDs to an external, silent SSD—keeping the NAS’s primary storage for actual data while offloading the chaotic workloads to hardware that can handle them without complaint.

Why Docker turns HDDs into a noisy nuisance

Mechanical HDDs generate noise primarily through head movement. Each time the read/write head shifts to access data scattered across the disk, it produces a distinct click or whir. Sequential operations—like streaming a movie or backing up large files—are quiet because the head moves in smooth, predictable paths. Random I/O, on the other hand, forces the head to dart erratically across the platter, creating constant seeking and clicking.

Docker’s default storage driver, overlay2, amplifies this problem exponentially. Every container runs atop a layered filesystem where changes to files trigger copy-on-write operations. Instead of modifying files in place, overlay2 copies the entire file upward into a writable layer before any change is made. On SSDs, this is nearly instantaneous and silent. On HDDs, each copy-on-write becomes a seek, a read, and a write—often to different parts of the disk.

Beyond overlay2, Docker generates thousands of tiny metadata files that record container states, log rotations, and health checks. These files live in deep directory trees, and accessing them triggers random I/O. When you run multiple containers—each with its own layers, logs, and configurations—the combined effect is a storm of scattered disk activity that never pauses. System monitoring tools, cron jobs, and the NAS operating system only add to the chaos, ensuring the HDDs never spin down.

Pinpointing the true noise culprit

Before making any changes, it’s essential to confirm which processes are responsible for the constant drive activity. Two command-line tools are particularly useful for this diagnosis:

sudo iotop -o

This real-time monitor lists processes by their disk I/O usage, highlighting which applications are generating the most activity. On a typical Docker-enabled NAS, the Docker daemon will dominate the list, often followed by periodic spikes from cron jobs running system monitoring scripts.

iostat -x 2 10

This utility provides extended disk statistics over a set time window. Pay attention to the %util column, which shows the percentage of disk capacity being used at any moment. Consistently high utilization across multiple intervals confirms that the HDDs are under near-constant load.

Moving Docker off the HDDs: a silent solution

The solution is simple in concept but transformative in practice: offload Docker’s data-heavy operations to an external SSD while reserving the HDDs exclusively for the NAS operating system and your actual files. SSDs handle random I/O effortlessly and silently, eliminating the mechanical seeking that turns your NAS into a noise generator.

The first step is to identify what needs to be moved. Docker’s data-root directory contains image layers, container writable layers, and the overlay2 metadata—all of which generate continuous random I/O. This directory should be relocated to the SSD.

Configure Docker to store data on the SSD

Edit the Docker daemon configuration file to point to the new storage location:

{
  "data-root": "/mnt/external-ssd/@docker"
}

After saving the file, restart Docker to apply the change:

sudo systemctl restart docker

Relocate persistent container volumes

Container volumes that store databases, configuration files, or application data should also be moved to the SSD. These bind mounts generate their own random I/O as containers read and write data. Instead of changing container configurations to point to new paths, use a symbolic link to maintain compatibility:

ln -s /mnt/external-ssd/volumes /original/volumes/path

This approach preserves existing paths in container configurations while transparently redirecting I/O to the SSD.

Keep essential files on the HDDs

Not everything should move to the SSD. The NAS operating system, system logs, and your primary data files—documents, media, and backups—belong on the HDDs. These workloads benefit from HDDs’ strengths in sequential read/write operations and don’t contribute significantly to the noise problem.

Special considerations for UGOS Pro users

If your NAS runs UGREEN’s UGOS Pro—a Debian-based operating system—there’s a hidden trap when copying files to an external drive. The system uses proprietary kernel-level extended attributes that can corrupt permissions during transfers, especially when using rsync. Avoid this issue by using tar with the appropriate exclusion flag instead:

tar --xattrs-exclude='ug.*' -cf backup.tar /path/to/source

This command preserves permissions and metadata while safely moving files to the SSD.

Mounting the SSD for optimal performance

To ensure the SSD mounts reliably on every reboot, add an entry to /etc/fstab:

UUID=<your-uuid> /mnt/external-ssd ext4 defaults,noatime,nofail 0 2

Two options are critical here:

• noatime disables access time updates on file reads, reducing unnecessary write operations.
• nofail prevents the NAS from failing to boot if the SSD is disconnected.

The difference you’ll hear—and feel

After migrating Docker to the SSD, the transformation is immediate and dramatic. The relentless background hum that once filled the house at night is gone. The HDDs now spin up only occasionally—for system log flushing or scheduled cron jobs—returning to near-total silence within minutes. The NAS operates as originally intended: an invisible, always-on storage solution that doesn’t announce its presence to the entire household.

This setup isn’t just quieter—it’s more efficient, too. SSDs handle Docker’s random I/O workloads with ease, reducing latency and improving container performance. Meanwhile, the HDDs focus on what they do best: storing and serving large files without generating noise or heat.

Looking ahead, the rise of containerized applications shows no signs of slowing. As more users adopt NAS devices to run Dockerized services, understanding how to optimize storage configurations will become increasingly important. The solution isn’t to abandon Docker or switch to all-SSD setups—it’s to intelligently distribute workloads based on the strengths of each storage medium. With a few simple tweaks, your NAS can deliver both the power of containerized applications and the peace of mind that comes with near-total silence.