TL;DR: Every 9h45 (that's precise !), my toshiba drives wake up even when there's no user activity. All other drives are fine and behave as they should.

The symptom/problem:

When not in use, my syslog file looks like this :

Jan 29 03:55:40 ugreen emhttpd: read SMART /dev/sdc

Jan 29 04:10:41 ugreen emhttpd: spinning down /dev/sdc

Jan 29 05:23:37 ugreen emhttpd: read SMART /dev/sdb

Jan 29 05:38:38 ugreen emhttpd: spinning down /dev/sdb

Jan 29 13:40:44 ugreen emhttpd: read SMART /dev/sdc

Jan 29 13:55:45 ugreen emhttpd: spinning down /dev/sdc

Jan 29 15:08:05 ugreen emhttpd: read SMART /dev/sdb

Jan 29 15:23:06 ugreen emhttpd: spinning down /dev/sdb

A word about my setup:

- The system is hosted by a Ugreen DXP4800 (4 HDD / 2 SSD). I have 3 drives online and active in the array (one parity, two data drives), as well as one nvme SSD for cache and a few user shares (including Appdata and System).

- From these 3 data drives, two of them are Toshiba MG08ACA16TE (NAS/enterprise grade HDD), and the last one is a Western Digital. I also have another HDD in the 4th slot, but it's not included in the array and not being used.

- Spin down delay is set to 15 mins

- Most of my shares are on data HDDs formatted in XFS, but all my docker activity or things Idonotcareabout are on the cache SSD (formatted with btrfs).

Every 9h45 (more than twice a day), both Toshiba disks wake up for an unknown reason. As the spin down default

- no swap on the system

My first reflex was to look for read or write accesses to my disks, with the "File Activity" plugin, but it showed nothing. I then quickly moved on to other techniques, including the usage of iotop and pspy, but nothing stood out. Web searches on this forum and reddit returned many results, and every time, there was a user-process that was accessing the disks for some reason. So I though that was my problem too.

What i've done/tried so far while in safemode:

- stopped docker

- stopped Qemu

- disabled automatic mover

- disabled scheduled parity check

- disabled scheduled trim

- stopped crond service (should be enough for scheduled tasks i guess)

- unplugged ethernet cable

The problem is still present after all these steps, and I couldn't identify any read or write access to my toshiba disks.

I also tried different things, without success:

- changed ASPM mode

- disabled offline data collection status (smartctl -o off /dev/sdx)

- changed APM value to 1, 127, 255 (disabled)

- disabled / enabled EPC (with openSeaChest)

I'm starting to run out of ideas, is there anything else that I can try to troubleshoot this problem?

Edited January 30Jan 30 by iDwucWEDSaE.U3jetfc2uz

42 minutes ago, iDwucWEDSaE.U3jetfc2uz said:

Every 9h45 (that's precise !),

Are they formatted ZFS?

53 minutes ago, JorgeB said:

Are they formatted ZFS?

No, all my HDD drives are formatted using XFS. My cache SSD is formatted with btrfs however

OK, there's a known issue with ZFS where they wake every 24H at the same time, if they are not using ZFS, you likely have some plugin or script waking them at that time.

Ooh, I get the confusion. i'm sorry, didn't make myself clear on the first post. What I meant with "every 9h45" is "every 9 hours and 45 minutes" (as seen in the logs) ; which is more than twice a day !

If we take for example /dev/sdb :

Jan 29 05:23:37 ugreen emhttpd: read SMART /dev/sdb

Jan 29 05:38:38 ugreen emhttpd: spinning down /dev/sdb

...

Jan 29 15:08:05 ugreen emhttpd: read SMART /dev/sdb

Jan 29 15:23:06 ugreen emhttpd: spinning down /dev/sdb

it wakes up at 5:23, goes to sleep 15 mins later, and then gets woken up again at 15:08... which is 9 hours and 45 minutes later.

8 minutes ago, JorgeB said:

you likely have some plugin or script waking them at that time.

I rebooted my system into safemode, so it should be safe to assume no plugin or app are executing, right ? (I'm still new to unraid)

What really bugs me, is that the problem occurs only with my Toshiba drives... My WD HDD is sleeping as expected

Most likely there is still something accessing them, like a container or over SMB, etc, I assume one of the disks is parity?

If nothing else is accessing it could be an issue with the disk or their firmware. If you are sure nothing else is accessing them, the easiest way to test would be to replace one of the Toshiba disks with one from a different brand and retest. You could even swap the WD with the Toshiba, but for the test to be valid, they would need to swap actual slots in Unraid and also their data, in case something is accessing one of them

Since we haven't asked yet

Attach Diagnostics ZIP to your NEXT post in this thread.

1 hour ago, JorgeB said:

Most likely there is still something accessing them, like a container or over SMB, etc, I assume one of the disks is parity?

yes, one of them is parity, and the parity disk can be woken up alone (the second toshiba being woken up at a later time)

1 hour ago, JorgeB said:

If nothing else is accessing it could be an issue with the disk or their firmware.

As only Toshiba disks are woken up, and not the WD, I'm leaning towards a "disk" issue, rather than a "user access" issue. Both disks (WD and Toshiba) contains data of user shares, but only Toshiba wake up every X hours. Besides, the ethernet cable is unplugged, so that nothing can reach the NAS from the network. I could stop others services like SMB to be 100% sure though ... I might try it in the upcoming days.

1 hour ago, JorgeB said:

The easiest way to test would be to replace one of the Toshiba disks with one from a different brand and retest. You could even swap the WD with the Toshiba, but for the test to be valid, they would need to swap actual slots in Unraid and also their data, in case something is accessing one of them

I would love too, but the Toshiba has more data in it than the WD total capacity. It would be a lot of work, and to be frank, is not my main hypothesis as to why disks are woken up. But I'll keep this test in my mind for later.

1 hour ago, trurl said:

Attach Diagnostics ZIP to your NEXT post in this thread.

The zip file is attached to this post. By the way, thank you so much for digging into my issue, really appreciated.

diagnostics-20260130-2131.zip

11 minutes ago, iDwucWEDSaE.U3jetfc2uz said:

the parity disk can be woken up alone

You mean this happens by itself?

Parity should not spin up unless array disk is written.

My parity disk is /dev/sdb. As you can see from the syslog or the short extract of log in my first post, /dev/sdb is the only disk to wake up on Jan 29 05:23:37. But there are more examples of this behavior in the syslog file.

The thing is, I think I did everything I could about power-management on those drives. I enabled / disabled APM and EPC, or tried different values for APM, but nothing changed.

Modifying the global "Default spin down delay" configuration (or changing the specific configuration disk by disk) to "never", and issuing the following commands "solved" this issue :

hdparm -S 180 /dev/sdb

hdparm -S 180 /dev/sdc

When I monitor the disks with hdparm -C, drive state keeps in standby mode.

I'll try to re-enable APM, EPC and Smart data offline collection to see if it changes anything, but now, when my disks go to sleep, they do not wake up as they did before.

The last thing I have to fix is the webGUI of unraid does not detect properly that disks are spun down

TL;DR: Unraid's behavior with enterprise-grade disk is a little odd, but I managed to make those drives to sleep, and slightly patched the GUI to display the real state of disks.

It turned out that running hdparm -S wasn't enough to COMPLETELY prevent disks wakes-up, but reduce it to once every 4-5 days. Which is satisfying enough to keep this configuration.

In the end, here are the mandatory configuration items :

• Set Default spin down delay to NEVER. It is absolutely crucial to set the default to never ; otherwise Unraid keeps waking the disk every 9 hours (even if the default is set to X minutes, and specific disks are setup to never be spun down). For disks that aren't Enterprise-grade HDD, set a specific spin down delay to whatever.

• APM must be disabled (hdparm -B 255 /dev/sdX)

• Smart offline data collection must be disabled as well (smartctl -o off /dev/sdX)

• EPC doesn't seem to have any impact

The only caveat of this setup is that from the GUI, disks are always marked as "Active" ; even if the disks are spun down. I think it is related to the fact that the default spin down delay in Unraid changes the global behavior of the disk monitoring. Idealy, to fix this issue, we would have to gain control over what writes into /var/local/emhttp/disks.ini, but this file is being overwritten every second or so by a thread of emhttpd.

What I did is setup a patch for /usr/local/emhttp/plugins/dynamix/nchan/update_2 ; checking for the state of Toshiba enterprise-grade disks. For those interested, here is the patch :

--- /usr/local/emhttp/plugins/dynamix/nchan/update_2    2026-02-20 16:46:42.299061313 +0100 
+++ /usr/local/emhttp/plugins/dynamix/nchan/update_2.patched    2026-02-20 16:48:55.535689177 +0100 
@@ -169,6 +169,9 @@ 
  
 function device_status(&$disk, &$error, &$warning) { 
   global $var; 
+  if (str_contains(_var($disk,'id'), 'TOSHIBA_MG') && str_contains(exec('hdparm -C /dev/' . var($disk,'device')), 'drive state is:  standby')) { 
+    $disk['color'] = 'green-blink'; 
+  } 
   if (var($disk,'type')!='Extra' && var($var,'fsState')=='Stopped') { 
     $color = 'green'; $text = 'off-line'; 
   } else switch (var($disk,'color')) {

To apply it immediately, run patch /usr/local/emhttp/plugins/dynamix/nchan/update_2 < /boot/custom/update_2.patched and restart nginx (/etc/rc.d/rc.nginx restart).
To make it permanent, modify your /boot/config/go file to patch on every boot.