If ZimaOS hard drives spin down correctly but wake every 15–30 minutes, update to ZimaOS 1.6.0 or newer before editing SMART configuration manually. ZimaOS 1.6.0 officially fixed intermittent wake-ups caused by the smartd service, which matches the periodic pattern reported in the source thread.
If disks still wake on a current stable release, then move beyond the old smartd bug and identify the real reader: storage health polling, a Docker app, SMB client, indexing, backup task, RAID metadata activity, or USB bridge behavior.
Start with the Current ZimaOS Version
The source user was on 1.5.4 and saw the drives wake every 15–20 minutes even after stopping Jellyfin and JDownloader.
The current ZimaOS 1.6.0 release notes explicitly lists a fix for disks being unable to remain asleep because smartd woke them intermittently.
Step 1: Confirm the Drives Can Enter Standby
Set Disk Standby in ZimaOS and wait without running file operations. Then check status with a non-waking command where supported:
smartctl -n standby /dev/sdXIf the drive never reaches standby at all, that is different from “it sleeps successfully and wakes every 20 minutes.”
Step 2: Measure the Wake Interval
Write down the exact times for several wake events. A highly regular interval suggests a timer, health poll, scheduled task, or daemon rather than random network access.
Step 3: Stop User Apps One Group at a Time
Pause media scanners, downloaders, photo indexers, databases, and backup jobs. Do not stop every service simultaneously unless you are only proving that the trigger is user-space activity.
If the wake-up continues with all user containers stopped, focus on system services, storage polling, and RAID/DAS behavior.
Step 4: Check Backup, SMB, and Remote Clients
A laptop opening a mapped share, a backup scheduler checking paths, or a media library scan can wake a disk. Disconnecting the network can be a useful short isolation test, as the source user already attempted.
Do Not Keep Old smartd.conf Workarounds After the Fix
Earlier community workarounds changed SMART daemon options so health checks would not wake sleeping drives. On current ZimaOS, first test the official fix rather than carrying an old custom smartd configuration indefinitely.
RAID Can Add More Background Access
Arrays have metadata and health checks that single disks do not. If only RAID members wake, compare the behavior of a standalone HDD with an array under the same standby interval.
USB Enclosures Are a Separate Problem
A USB bridge may not forward ATA standby commands consistently. If an internal SATA disk sleeps correctly but the same model in a DAS does not, diagnose the enclosure chipset instead of rewriting ZimaOS SMART policy.
The current ZimaOS storage guide documents the current storage model.
The storage troubleshooting guide helps structure the wider investigation.
FAQ
Did ZimaOS fix periodic smartd wake-ups?
Yes. ZimaOS 1.6.0 release notes explicitly say intermittent wake-ups caused by smartd were fixed.
Why do my drives still wake on newer versions?
Another service, client, array check, backup task, or USB bridge may still access them. Measure the interval and isolate layers systematically.
Is frequent spin-up worse than leaving NAS drives running?
Repeated start/stop cycles add mechanical load, while continuous operation adds runtime and power use. Choose a standby policy based on your workload rather than forcing very short cycles.
Should I edit smartd.conf manually?
Not as the first step on a current stable release. Test the official smartd wake-up fix first.
