Hi all, I noticed that the drives in the main were not spinning down and I noticed this on the logs. It looks like the actually do but immediately after get the read smart which seems to keep them up.

Anyone else seeing the same?

Thanks!

Jun  3 12:05:03 server emhttpd: read SMART /dev/sdb
Jun  3 12:05:05 server emhttpd: spinning down /dev/sdj
Jun  3 12:05:07 server emhttpd: read SMART /dev/sdj
Jun  3 12:30:04 server emhttpd: spinning down /dev/sdh
Jun  3 12:30:07 server emhttpd: read SMART /dev/sdh
Jun  3 12:45:02 server emhttpd: spinning down /dev/sdi
Jun  3 12:45:05 server emhttpd: read SMART /dev/sdi
Jun  3 12:45:14 server emhttpd: spinning down /dev/sdc
Jun  3 12:50:13 server emhttpd: read SMART /dev/sdc
Jun  3 12:57:52 server emhttpd: spinning down /dev/sdf
Jun  3 12:58:04 server emhttpd: read SMART /dev/sdf
Jun  3 13:00:18 server emhttpd: spinning down /dev/sdd
Jun  3 13:00:18 server emhttpd: spinning down /dev/sde
Jun  3 13:05:10 server emhttpd: read SMART /dev/sdd
Jun  3 13:05:11 server emhttpd: read SMART /dev/sde
Jun  3 13:05:11 server emhttpd: spinning down /dev/sdj
Jun  3 13:05:11 server emhttpd: spinning down /dev/sdb
Jun  3 13:05:15 server emhttpd: read SMART /dev/sdj
Jun  3 13:05:15 server emhttpd: read SMART /dev/sdb
Jun  3 13:30:06 server emhttpd: spinning down /dev/sdh
Jun  3 13:30:08 server emhttpd: read SMART /dev/sdh
Jun  3 13:40:44 server monitor_nchan: Stop running nchan processes
Jun  3 13:45:05 server emhttpd: spinning down /dev/sdi
Jun  3 13:45:09 server emhttpd: read SMART /dev/sdi
Jun  3 13:50:04 server emhttpd: spinning down /dev/sdc
Jun  3 13:50:08 server emhttpd: read SMART /dev/sdc
Jun  3 13:58:00 server emhttpd: spinning down /dev/sdf
Jun  3 13:58:16 server emhttpd: read SMART /dev/sdf

Read SMART means Unraid detected the drive is up, it's not what is making them spin up. Try booting in safe mode and leave all the drives to retest, also make sure nothing is accessing the disks over SMB

thanks for the reply, I will do more testing over the weekend.

I just find it weird because nothing access the disk on SMB and nothing have changed in a long time, now new apps, no new devices within the network, no new configuration. And before the upgrade they would not be spinning 4 or 5 of them most of the day.

If you don't find the reason, it also worth downgrading back to 7.3.0 to confirm if it really stops spinning up there.

well... this seems easier, I download the diagnosis file and downgrade, no change have been made, I will see within an hour i guess.

yeah, disk spun down in version 7.3.0

Upgrade again, and if it stops spinning down once more, post the diagnostics, mostly to see the hardware.

I'm having the exact same issue with 7.3.1 and had to roll back to 7.3.0 to resolve.

pet410-diagnostics-20260607-1956.zip

Edited June 7Jun 7 by Brianv78
add diagnostics file

I had the same error but rolling back to 7.3.0 or 7.2.7 did not do the trick. Meanwhile I deleted the drive from the array (Toshiba N300) and everything's back to normal... I was just tired of looking what caused the drive to be spun up immediately as I could not find anything unusual within the logs...

Just wonder if it is more drive related as my Seagate Exos were not affected and always remained spun down.

I rolled back to 7.3.0 and then upgrade again. Now looks like is working but still monitoring

On 6/9/2026 at 5:55 PM, remblack said:

I rolled back to 7.3.0 and then upgrade again. Now looks like is working but still monitoring

Not in my case. After ripping out the HDD that did spin up immediately after a manual spindown it's now a second cache device /ssd) that wakes up immediately... not that much of a nuisance as there is no mechanical spinning but it's really strange behaviour that was not an issue before.

Confirmed, same issue here. My ZFS drives slept fine in 7.3.0. Since upgrading to 7.3.1, they wake up constantly even when idle. Manually spinning them down lasts only 10–30 seconds before they wake again. XFS drives sleep normally.

Interesting. In my case I have xfs encrypted drives and - for now - it’s only a ssd within the pool that spins up immediately. I will test a a simple downgrade to 7.3.0 once I am back at the office…

Edit: I installed another PCIe ASM card, attached a new hdd and now everything is back to normal. That means: I did not change anything in my setup (e.g. go file) but had to reboot the server. I am unaware what did the trick but not all hdds and ssds are sleeping after the default spin down time (45 minutes).

I know, no real solution to follow but at least it seems to work (again).

Edited June 26Jun 26 by buscopina

I updated from 7.2.4 to 7.3.1. After the update, I read your post and was a little worried because I have 4 Toshiba HDDs: 1x 18TB MG series, 2x 16TB MG series, and one 12TB N300. Fortunately, they are all working and spinning down fine. I haven’t had any issues with these drives.

For context, I also have a PCIe to SATA adapter with a couple of drives connected to it. Additionally, I run Frigate, and recordings are saved to a separate Crucial SSD. Even this SSD successfully goes to sleep (spins down) without any issues. Only the NVMe cache stays active most of the time, but that's normal. BTW I disabled the two SATA ports on the ASMedia controller on my motherboard because of their poor power-saving capabilities. So, out of the six SATA ports on my motherboard, only four are working. Maybe check your sata ports.

I should also mention that I run some fairly advanced custom scripts to force power-saving states (like PCIe ASPM and SATA DIPM) on my server. I’m not sure if actively forcing these power states is what helps my drives go to sleep successfully compared to a stock Unraid setup, but everything is working perfectly on my end.

I have been watching the spin down behavior for almost a month and it seems to be working as expected after I rollback the upgrade and upgraded again.

Either:

1. You have SAS disks that dont like spin-downs

2. You have plugins reading/polling disks

3. You are running VMs/Docker containers reading/writing to the disks.

4. SMB/NFS client connections waking disks up to read contents.

Boot into SAFE MODE, disable docker and VM services from the settings menu, and observe the disks.