You buy a NAS for silent, always-on storage. It sits in a corner, humming quietly, doing its thing.
You installed Docker on it for the same reason I did: to save money. Every open-source service you’d otherwise pay a VPS for — your media server, your download automation, your file sync, your home automation bridge — all of it can run on the NAS for free. No monthly VPS bills, no cloud subscriptions, no $5/mo here and $10/mo there that add up to a second rent. Just one box, your box, doing everything.
The problem is that Docker wasn’t designed for spinning disks.
And suddenly the HDDs never stop. Seeking, spinning, clicking, whirring — not occasionally, not every few minutes, but constantly. At 2am you can hear it from the next room. Through a closed door. It drives you insane because you bought this thing specifically so it would not make noise.
I know, because I lived with it for months. Every night, the same clicking. Every morning, the same relief when the TV drowned it out. The NAS was supposed to be invisible, and instead it was the loudest thing in the house.
Here’s what causes it, and how I went from that to 99.9% less noise in one afternoon.
What’s Actually Causing the Noise
Mechanical HDDs make noise when the read/write head moves. The more random the I/O — small reads and writes scattered across the disk — the more seeking, the more noise. Sequential writes to a single file are quiet. Random I/O across thousands of small files is loud.
Docker is pathological for HDDs.
Docker overlay2
Docker’s default storage driver is overlay2. Every container runs on top of layered filesystems — the image layers are stacked, and a thin writable layer sits on top for each running container.
Every file operation inside a container that touches a file from a lower layer triggers a copy-on-write: the entire file gets copied up to the writable layer before the write happens. On an SSD this is fast and silent. On spinning HDDs with mechanical heads, every copy-on-write is a seek, a read, and a write — often scattered across the disk.
And it’s not just copy-on-write. Docker’s overlay2 metadata lives in small files across a deep directory tree. Container startup reads dozens of these. Log rotation writes to them. Health checks touch them. Any container doing anything at all generates constant scattered I/O.
Now multiply that by however many containers you’re running. Every single one is generating random I/O all day, every day. The HDDs never get a break.
Everything Else Piling On
Beyond Docker, a typical homelab NAS has:
- System monitoring tools running on cron (every 5-10 minutes, writing stats to disk)
- systemd journal flushing logs
- The NAS OS itself doing housekeeping
None of these alone would be noticeable. But on top of Docker’s constant churn, the drives never spin down. Not for a second.
Diagnosing Which Process Is the Problem
Before moving anything, confirm what’s actually hitting the disk:
# Real-time I/O per process (needs sysstat)
sudo iotop -o
# Disk utilization over time
iostat -x 2 10
On a typical Docker setup you’ll see the Docker daemon at the top, with periodic spikes from cron jobs.
The Fix: Move Docker Off the HDDs
The HDDs are loud because they’re doing work they shouldn’t be doing. The solution is to give that work to something that doesn’t make noise.
An external SSD connected via USB is cheap, silent, and fast enough for everything Docker needs. USB 3.0 to a SATA SSD delivers 400+ MB/s — far more than any container workload requires.
The goal: the HDDs only handle the NAS OS and your actual data (media, documents, backups). Everything Docker-related moves to the SSD.
What to Migrate
Docker data-root — the overlay2 layers, image cache, container writable layers. This is the biggest source of random I/O and the highest-impact thing to move.
# /etc/docker/daemon.json
{"data-root": "/mnt/external-ssd/@docker"}
Bind-mount volumes — the persistent data your containers read and write (databases, config files). If these live on the HDD, container writes hit the HDD. Move them to the SSD.
For bind mounts, a symlink keeps things transparent — containers keep using the same paths, no reconfiguration needed:
ln -s /mnt/external-ssd/volumes /original/volumes/path
What Stays on the HDDs
- The NAS operating system
- System logs
- Your actual data files (documents, media, backups) — these have sequential I/O patterns that HDDs handle well and don’t cause the constant seeking noise
A Note on Copying Files (UGOS Pro Caveat)
If your NAS runs UGOS Pro (UGREEN’s Debian-based OS), there’s a critical gotcha: rsync will silently corrupt permissions when copying from the NAS filesystem to an external drive. This is caused by proprietary kernel-level xattr hooks in UGOS Pro.
The fix and the full technical explanation are in a separate post: Why rsync Destroys Permissions on UGOS Pro — and the Only Fix That Works
Short version: use tar --xattrs-exclude='ug.*' instead of rsync for any file copy on UGOS Pro.
Mount the SSD Correctly
# /etc/fstab
UUID=<your-uuid> /mnt/external-ssd ext4 defaults,noatime,nofail 0 2
Two flags matter:
-
noatime— disables access time updates on every file read. Eliminates a whole class of unnecessary writes. -
nofail— if the SSD disconnects and the NAS reboots, it boots normally instead of hanging at the fstab error.
The Result: Silence
After the migration, the difference is night and day. Before, the HDDs were seeking constantly — a low but relentless clicking that never stopped, day or night. It was the kind of noise you don’t notice during the day but drives you crazy at 3am when the house is silent.
Now? Nothing. The HDDs spin up occasionally — a system log flush, a cron job writing stats — but the constant background noise is gone. The drives spend most of their time parked, doing what they were designed to do: sit there quietly and hold your data.
I’d estimate 99.9% reduction in audible HDD activity. The clicking that used to drive me insane? Completely gone. The NAS is back to being the quiet box in the corner it was always supposed to be.
You don’t realize how much that noise was bothering you until it stops. Trust me.
If your NAS runs UGOS Pro, read the companion post before attempting the migration — the rsync issue will cost you time if you hit it blind: Why rsync Destroys Permissions on UGOS Pro