Since 7.2, my drives never stay spun down. They spin down successfully but emhttpd wakes them immediately via "read SMART" every ~60 seconds.

Syslog pattern (repeats endlessly):

May 12 13:13:02 emhttpd: spinning down /dev/sdf

May 12 13:14:04 emhttpd: read SMART /dev/sdf

Tested and ruled out as causes:

• Safe Mode (all plugins disabled) → issue persists

• All Docker containers stopped → issue persists

• poll_attributes=0 → no effect

• pcie_aspm=off kernel parameter → no effect

• ASM1166 firmware updated → no effect

• smartctl replaced with dummy (exit 0) → no effect

The dummy test is the key finding: emhttpd does not use the smartctl binary. It issues ioctl calls directly to the block device, confirmed via kernel ftrace (kprobe on blkdev_ioctl). This is a hardcoded timer completely independent of poll_attributes.

Drives with APM support (Seagate IronWolf, WD Red EFRX) are less affected. Drives without APM (WD Blue EZRZ, WD Red Plus EFPX) wake up on every ioctl.

Has anyone found a workaround?

boricua-diagnostics-20260512-1621.zip

Edited May 13May 13 by Boriqueno5
diagnostic attached

2 hours ago, Boriqueno5 said:

read SMART /dev/sdf

This means Unraid detected the drive as up, meaning, it was already spun up; it should not be this that is spinning it up.

So if read SMART is not the cause, something else is waking the drives first. I already ruled out Docker containers, all plugins (safe mode), and confirmed the issue persists with poll_attributes=0. I also confirmed via inotifywait that /dev/sdg gets OPEN→ACCESS→CLOSE every ~60 seconds. What would you suggest as next step to identify what is actually issuing that initial wakeup

You are likely to get better informed feedback if you attach your system’s diagnostics (with everything in the one zip file) to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current logs.

I have attached the diagnostics zip file to the first post.

sorry

Edited May 12May 12 by Boriqueno5

Try starting the array in maintenance mode; that will make sure nothing else is really accessing the disks, like shares

Also recommend uninstalling Connect to test, since it updates the API, and I'm not sure it still uses that in safe mode; there was recently a spin up issue with the API.

Tested both suggestions: maintenance mode (array stopped, no shares) and uninstalling Connect. Issue persists identically in both cases. Drives spin down and are woken by read SMART ~60 seconds later regardless.

Interestingly, not all drives are affected equally – some spin down and stay down, while others are woken repeatedly. This would suggest the cause is within emhttpd itself on a hardcoded internal timer, rather than shares, plugins, Docker, or the Connect plugin. Happy to run any further diagnostics if that would help narrow it down.

Edited May 12May 12 by Boriqueno5

If they still spin up in maintenance mode; it suggests a controller or firmware issue, assuming you are using all default settings/config.

I flashed both ASM1166 controllers to the latest firmware (241224-0000-00) with a full cold boot. Issue persists identically.

I also checked the syslog statistics – every single drive has almost identical spinning down and read SMART counts, regardless of which controller they are on. Drives on the onboard Intel AHCI controller show the same pattern as drives on the ASM1166 controllers.

Interestingly though, not all drives are equally affected: Seagate IronWolf and WD Red EFRX drives spin down and stay down, while WD Blue (EZRZ/EZRX) and WD Red Plus (EFPX) drives wake up every time. The key difference is APM support – the drives that sleep have APM, the ones that wake up do not. This suggests emhttpd is issuing an ioctl that NAS drives with APM can ignore internally, while desktop drives without APM cannot.

Worth noting: the same drives worked fine under a previous setup with different hardware (Gigabyte B760M D3HP instead of DS3H, no M.2 SATA adapter) running the same Unraid 7.2.x version. So the behavior may be hardware-dependent in some way I haven't been able to isolate yet.

This rules out the controller firmware as the cause – but I'm open to further suggestions.

Have you done any other customizations? I cannot reproduce, and if this were a general issue, there would be infinite posts of users complaining. I would recommend retesting with a new stock installation.

After upgrading to Unraid 7.3.0 the issue improved dramatically. Drives now sleep for ~43 minutes consistently before being woken by a read SMART. The 60-second endless loop is completely gone. The 7.3.0 release notes mention: 'WebGUI and API requests no longer unnecessarily spin up the full HDD array on affected systems.' This appears to have resolved the main issue. A periodic SMART read every ~43 minutes still wakes the drives briefly, but this is acceptable behavior compared to the previous state.

2 hours ago, Boriqueno5 said:

WebGUI and API requests no longer unnecessarily spin up the full HDD array on affected systems

This was a fix for 7.3 beta/rc, 7.2 was not affected by that.

On 5/14/2026 at 1:40 PM, Boriqueno5 said:

After upgrading to Unraid 7.3.0 the issue improved dramatically. Drives now sleep for ~43 minutes consistently before being woken by a read SMART. The 60-second endless loop is completely gone. The 7.3.0 release notes mention: 'WebGUI and API requests no longer unnecessarily spin up the full HDD array on affected systems.' This appears to have resolved the main issue. A periodic SMART read every ~43 minutes still wakes the drives briefly, but this is acceptable behavior compared to the previous state.

I ran into a similar issue. It's just a Toshiba NAS drive that is woken up immediately after being spun down. Same thing with

emhttpd: read SMART /dev/sdb

So currently I am on 7.3.1... Just wondering if a downgrade to 7.2.x would be a workaround... I am not happy with a 40is minute wakup all the time... in my case it does not spin down anyway and ther is no other thing running apart from the immediate SMART check.