If HDDs inside a USB enclosure such as a TerraMaster D4-320 never spin down on ZimaOS, separate the old smartd wake-up bug from the enclosure's own USB-to-SATA standby behavior. ZimaOS 1.6.0 fixed smartd periodically waking disks, but multiple users still reported that specific USB DAS models stayed spinning even on 1.6.0.
That means the current diagnosis is enclosure-specific: prove whether the USB bridge forwards ATA standby commands, whether the drives can enter standby manually, and whether ZimaOS or another process immediately wakes them. Do not assume a Dockerized hd-idle container is a universal fix.
Update Past the smartd Wake-Up Bug First
ZimaOS 1.6.0 officially fixed the issue where smartd intermittently woke disks and prevented normal sleep.
The current ZimaOS 1.6.0 release notes should be your version baseline.
Why USB Enclosures Behave Differently from Direct SATA
A DAS contains a USB-to-SATA bridge controller between Linux and each disk. Some bridges forward ATA power-management commands well; others filter or translate them differently. Multi-bay enclosures add another layer of firmware and may present drives in unusual ways.
Step 1: Confirm Each Disk Is Exposed Individually
lsblk -o NAME,MODEL,SERIAL,TRAN
lsusbIf all disks appear individually as USB-attached block devices, note their stable identifiers before testing any standby command.
Step 2: Test Non-Waking Status Checks
Where the bridge supports SAT passthrough, a command such as:
smartctl -d sat -n standby /dev/sdXcan check whether the drive is already asleep without deliberately waking it. Not every bridge supports the same -d mode.
Step 3: Test Manual Standby Carefully
If supported, use the drive/enclosure vendor's documented standby method or a Linux tool known to work with that bridge. A manual standby command that succeeds once proves more than repeatedly changing the GUI timer.
If the drive sleeps and immediately wakes, another process is accessing it. If it refuses to sleep at all, bridge compatibility is the stronger suspect.
Why hd-idle in Docker Is Awkward
hd-idle needs direct block-device access and must coordinate with a host that is actively mounting and using those disks. Passing raw disks into a privileged container weakens isolation and can become fragile after device names change.
Use a native current ZimaOS solution when available rather than building a permanent raw-device control container solely for standby.
Community Workarounds Are Not the Same as Native Support
One D4-320 user built a systemd timer that periodically issued smartctl -s standby,now. That can work as a workaround, but forcing standby on a timer without checking active I/O is risky. A backup, scrub, download, or file copy should never be interrupted just because five minutes elapsed.
Check Enclosure Firmware and Native Power Features
If the same D4-320 sleeps correctly on Windows or macOS but not Linux, compare whether those operating systems use vendor-specific USB commands or utilities. ZimaOS cannot always replicate proprietary enclosure behavior through generic ATA power commands.
When Direct SATA Is the Better Choice
If low power and predictable disk standby are important, direct SATA usually exposes drive power-management commands more transparently than a multi-bay USB bridge.
The storage troubleshooting guide provides a safer diagnostic structure.
FAQ
Did ZimaOS 1.6.0 fix all disk spindown problems?
No. It fixed a specific smartd wake-up issue. USB bridge compatibility can still prevent or disrupt standby on some enclosures.
Why does my TerraMaster sleep on Windows but not ZimaOS?
The enclosure may depend on bridge-specific or vendor-specific power-management behavior that differs under Linux.
Should I run hd-idle in Docker?
It is possible with raw-device access, but it adds privilege and device-mapping complexity. It is not the clean first choice.
Is it safe to force standby every few minutes?
Only if you can guarantee the disk is idle. A blind timer can conflict with active writes, backups, scrubs, or media access.
