DEV Community: iatxako

Your NAS Is Loud Because of Docker (and How to Fix It)

iatxako — Tue, 02 Jun 2026 07:36:39 +0000

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

Your NAS Is Loud Because of Docker (and How to Fix it)

iatxako — Mon, 01 Jun 2026 21:19:53 +0000

This article has moved to a new URL.

Please visit the updated version: https://dev.to/iatxako/your-nas-is-loud-because-of-docker-and-how-to-fix-it-m94

This redirect is here because the original slug contained a reference to Syncthing which is no longer relevant to the article.

Why rsync Destroys Permissions on UGOS Pro - and the Only Fix That Works

iatxako — Mon, 01 Jun 2026 21:13:51 +0000

Moving Docker from HDDs to an external SSD on an ARM64 NAS running UGOS Pro (Debian 12) looked simple. It took two failed approaches to find out the OS itself was the obstacle.

The Setup

A UGREEN NAS running UGOS Pro - a customized Debian 12 on ARM64 - hosting several Docker containers. All Docker data sitting on slow mechanical HDDs: both the data-root (overlay2 layers) and bind-mount volumes. Goal: migrate everything to an external SSD connected via USB to eliminate HDD I/O noise from containers.

First Attempt: rsync -aHX

Standard approach for Docker migrations. Copy everything, stop Docker, delta-sync, update daemon.json, restart.

rsync -aHX /volume1/@docker/ /mnt/external-ssd/@docker/

Copy succeeded. Docker started. Containers launched. Two minutes later - every container crashed with permission errors. All binaries inside the overlay2 layers had been reset to 600. Not executable. Just broken.

Second Attempt: rsync Without Xattrs

Suspected xattr copy was the problem. Excluded them:

rsync -aH --no-xattrs /volume1/@docker/ /mnt/external-ssd/@docker/

Same result. All files 600 again.

Root Cause: UGOS Pro's Kernel VFS Hook

UGOS Pro adds two proprietary extended attributes to every file on its native filesystem:

ug.archive_bit - tracks archive state for backup tooling
system.ugacl_self - stores the NAS's custom ACL data

The custom ARM64 kernel includes VFS-level hooks tied to these xattrs. The hook behavior:

When ug.archive_bit is written to any filesystem - including ext4 on the SSD - the kernel resets that file's permissions to 600.

This fires in both rsync modes:

With -X: rsync explicitly copies ug.* xattrs to the destination ? hook fires
Without xattrs: rsync calls chmod() after writing files ? the kernel hook intercepts the chmod and applies ug.* to the new file ? hook fires again

No rsync flag combination avoids this. The hook is below userspace.

The Fix: tar with --xattrs-exclude

The solution is tar with explicit xattr exclusion. Unlike rsync, tar applies the file mode atomically during extraction - the kernel doesn't get a separate chmod syscall to intercept.

Excluding ug.* ensures they're never written to the destination:

sudo tar \
  --xattrs \
  --xattrs-include='*.*' \
  --xattrs-exclude='ug.*' \
  -cpf - -C /source/path directory-name \
| sudo tar \
  --xattrs \
  --xattrs-include='*.*' \
  --xattrs-exclude='ug.*' \
  -xpf - -C /destination/path

The pipe avoids writing to disk twice. The --xattrs-include='*.*' is required - without it, --xattrs-exclude is silently ignored.

Expected warning during extraction:

tar: system.ugacl_self: Operation not supported

Harmless. The ext4 SSD doesn't support this xattr type, tar reports it and continues normally.

Migration Steps

Prepare the SSD

Add to /etc/fstab for persistent mount:

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

The nofail flag is critical - without it, a disconnected SSD during boot will hang the NAS.

sudo mkdir -p /mnt/external-ssd
sudo mount -a

Phase 1: Migrate Docker data-root

# Stop Docker completely - both socket and service
sudo systemctl stop docker.socket docker.service

# Copy with tar pipe
sudo tar \
  --xattrs --xattrs-include='*.*' --xattrs-exclude='ug.*' \
  -cpf - -C /original/docker/path @docker \
| sudo tar \
  --xattrs --xattrs-include='*.*' --xattrs-exclude='ug.*' \
  -xpf - -C /mnt/external-ssd

# Update daemon.json
echo '{"data-root": "/mnt/external-ssd/@docker"}' \
  | sudo tee /etc/docker/daemon.json

# Restart and verify
sudo systemctl start docker
docker info | grep 'Docker Root Dir'
docker ps

Phase 2: Migrate bind-mount volumes

The symlink approach avoids recreating any containers - Docker sees the same path, it just resolves to the SSD:

sudo systemctl stop docker.socket docker.service

sudo tar \
  --xattrs --xattrs-include='*.*' --xattrs-exclude='ug.*' \
  -cpf - -C /original/volumes/path . \
| sudo tar \
  --xattrs --xattrs-include='*.*' --xattrs-exclude='ug.*' \
  -xpf - -C /mnt/external-ssd/volumes

# Replace original directory with symlink
sudo mv /original/volumes/path /original/volumes/path.bak
sudo ln -s /mnt/external-ssd/volumes /original/volumes/path

sudo systemctl start docker
docker ps

Verify:

ls -la /original/volumes/path
readlink -f /original/volumes/path

Result

All containers running from SSD. HDD I/O dropped significantly. Mechanical drives now only handle the OS, logs, and background system processes. The symlink approach meant zero container reconfiguration.

The Rule for UGOS Pro

Any time you copy files from UGOS Pro's native filesystem to another filesystem (ext4, btrfs, tmpfs), use tar --xattrs-exclude='ug.*'. rsync cannot be made safe for this operation regardless of flags.

This applies to:

Docker data-root migrations
Backup operations targeting external drives
Any bulk copy from UGOS-managed paths to a non-UGOS filesystem

The warning system.ugacl_self: Operation not supported will appear during extraction - it's harmless.

Tested on UGOS Pro with a custom ARM64 kernel. If you hit this on a different NAS OS with proprietary xattr hooks, the same pattern applies - find the vendor xattr prefix and exclude it from tar.