I just moved my small setup to a new machine (MSI H610m-e with i5 14600) and I'm having the issue that my drives immediately spin up after spinning down. Docker, VMs, appdata etc are all writing to the cache. Looking at file activity nothing is writing or reading to the disks. The log shows clearly that they immediately spin up. Even if I manually spin them down they spin right back up with no delay. I tried turning off docker and VMs but no change. I rarely write to the array (more archival nature) and would really love to keep it spun down to save energy. Any idea what could be going on here?

Logs: Aug 26 07:53:05 ministry emhttpd: spinning down /dev/sdd Aug 26 07:53:06 ministry emhttpd: read SMART /dev/sdd Aug 26 07:53:44 ministry emhttpd: spinning down /dev/sde Aug 26 07:53:49 ministry emhttpd: read SMART /dev/sde Aug 26 08:06:47 ministry emhttpd: spinning down /dev/sdb Aug 26 08:06:48 ministry emhttpd: read SMART /dev/sdb Aug 26 08:08:07 ministry emhttpd: spinning down /dev/sdd Aug 26 08:08:09 ministry emhttpd: read SMART /dev/sdd Aug 26 08:08:48 ministry emhttpd: spinning down /dev/sde Aug 26 08:09:31 ministry emhttpd: read SMART /dev/sde

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread.

It is always a good idea to do this to allow us to see the current state of your system and so we can see logs.

1 hour ago, itimpi said:

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread.

It is always a good idea to do this to allow us to see the current state of your system and so we can see logs.

Thanks for the heads up.

Here is the diagnostics.

Edit: just checked, even in safe mode the drive spins up right after spindown.

ministry-diagnostics-20250826-1558.zip

Edited August 26, 2025Aug 26 by sillywalks

I rolled back to 6.12 and the issue persists.

Can this somehow be related to hardware? So maybe the mainboard is not allowing spindown?

I updated the bios to the latest version alread so that was no help.

Any ideas how I can further debug this issue?

It seems unlikely to me that the board/controller would be the issue, did you try using the open files plugin to see if there are any?

56 minutes ago, JorgeB said:

It seems unlikely to me that the board/controller would be the issue, did you try using the open files plugin to see if there are any?

Yes I did that.

Quite a few files open but none on the drives. All on the cache. :(

To rule out a config issue you can try booting with a flash drive using a stock install, backup the current one first, and then recreate it using the USB tool and just restore the key and super.dat for the array assignments.

Leave the pool unassigned for now, start the array, wait a couple of minutes and spin the drives down, if they don't stay spun down like that, it can be some hardware compatibility issue.

To get back to the old config you then just need to copy the complete /config folder from the backup, overwriting all existing files.

17 minutes ago, JorgeB said:

To rule out a config issue you can try booting with a flash drive using a stock install, backup the current one first, and then recreate it using the USB tool and just restore the key and super.dat for the array assignments.

Leave the pool unassigned for now, start the array, wait a couple of minutes and spin the drives down, if they don't stay spun down like that, it can be some hardware compatibility issue.

To get back to the old config you then just need to copy the complete /config folder from the backup, overwriting all existing files.

Thanks. I'll try that and report back.

3 hours ago, JorgeB said:

To rule out a config issue you can try booting with a flash drive using a stock install, backup the current one first, and then recreate it using the USB tool and just restore the key and super.dat for the array assignments.

Leave the pool unassigned for now, start the array, wait a couple of minutes and spin the drives down, if they don't stay spun down like that, it can be some hardware compatibility issue.

To get back to the old config you then just need to copy the complete /config folder from the backup, overwriting all existing files.

Sweet that worked. Drives stay spun down on the fresh system.
Where do I go from here. Should I manually rebuild my setup? Because restoring the flash backup might reintroduce the problem?

You can restore pools folder for the pool assignments, also copy the docker user templates folder (\config\plugins\dockerMan\templates-user), if it still works you can then reconfigure the server or try restoring a few config files at a time from the backup to see if you can find the culprit.

ok so after a few days without issues it has returned.
I am still running a minimal setup and I have no idea why this issue is back.

Here is the part of the log where it suddenly starts:
Aug 30 12:11:17 Tower kernel: usb 1-7: reset low-speed USB device number 5 using xhci_hcd

Aug 30 12:11:18 Tower kernel: usb 1-1.1: reset full-speed USB device number 4 using xhci_hcd

Aug 30 12:11:18 Tower kernel: usb 1-1.3.1: reset full-speed USB device number 8 using xhci_hcd

Aug 30 12:11:18 Tower kernel: usb 1-6: reset high-speed USB device number 3 using xhci_hcd

Aug 30 12:11:58 Tower kernel

: x86/split lock detection: #AC: CPU 8/KVM/73515 took a split_lock trap at address: 0x6199f100

Aug 30 12:11:58 Tower kernel: x86/split lock detection: #AC: CPU 2/KVM/73509 took a split_lock trap at address: 0x6199f100

Aug 30 12:11:58 Tower kernel: x86/split lock detection: #AC: CPU 9/KVM/73516 took a split_lock trap at address: 0x6199f100

Aug 30 12:11:58 Tower kernel: x86/split lock detection: #AC: CPU 0/KVM/73507 took a split_lock trap at address: 0x6199f100

Aug 30 12:11:58 Tower kernel: x86/split lock detection: #AC: CPU 7/KVM/73514 took a split_lock trap at address: 0x6199f100

Aug 30 12:11:58 Tower kernel: x86/split lock detection: #AC: CPU 10/KVM/73517 took a split_lock trap at address: 0x6199f100

Aug 30 12:11:59 Tower kernel: x86/split lock detection: #AC: CPU 1/KVM/73508 took a split_lock trap at address: 0x6199f100

Aug 30 12:12:02 Tower kernel: x86/split lock detection: #AC: CPU 13/KVM/73520 took a split_lock trap at address: 0x6199f100

Aug 30 12:12:02 Tower kernel: x86/split lock detection: #AC: CPU 4/KVM/73511 took a split_lock trap at address: 0x6199f100

Aug 30 12:12:03 Tower kernel: x86/split lock detection: #AC: CPU 12/KVM/73519 took a split_lock trap at address: 0x6199f100

Aug 30 12:12:04 Tower kernel: x86/split lock detection: #AC: CPU 11/KVM/73518 took a split_lock trap at address: 0x6199f100

Aug 30 12:22:30 Tower kernel: usb 1-7: reset low-speed USB device number 5 using xhci_hcd

Aug 30 12:22:33 Tower kernel: usb 1-1.1: reset full-speed USB device number 4 using xhci_hcd

Aug 30 12:22:33 Tower kernel: usb 1-1.3.1: reset full-speed USB device number 8 using xhci_hcd

Aug 30 12:22:41 Tower kernel: ata8.00: Enabling discard_zeroes_data

Aug 30 12:22:41 Tower kernel: sde: sde1

Aug 30 12:22:41 Tower kernel: br0: port 2(vnet0) entered disabled state

Aug 30 12:22:41 Tower kernel: vnet0 (unregistering): left allmulticast mode

Aug 30 12:22:41 Tower kernel: vnet0 (unregistering): left promiscuous mode

Aug 30 12:22:41 Tower kernel: br0: port 2(vnet0) entered disabled state

Aug 30 12:22:41 Tower kernel: usb 1-7: reset low-speed USB device number 5 using xhci_hcd

Aug 30 12:22:42 Tower kernel: input: SZH usb keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:C0F4:04C0.0007/input/input16

Aug 30 12:22:42 Tower kernel: hid-generic 0003:C0F4:04C0.0007: input,hidraw0: USB HID v1.10 Keyboard [SZH usb keyboard] on usb-0000:00:14.0-7/input0

Aug 30 12:22:42 Tower kernel: input: SZH usb keyboard Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.1/0003:C0F4:04C0.0008/input/input17

Aug 30 12:22:42 Tower kernel: input: SZH usb keyboard System Control as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.1/0003:C0F4:04C0.0008/input/input18

Aug 30 12:22:42 Tower kernel: hid-generic 0003:C0F4:04C0.0008: input,hidraw1: USB HID v1.10 Device [SZH usb keyboard] on usb-0000:00:14.0-7/input1

Aug 30 12:22:42 Tower elogind-daemon[1904]: Watching system buttons on /dev/input/event2 (SZH usb keyboard Consumer Control)

Aug 30 12:22:42 Tower elogind-daemon[1904]: Watching system buttons on /dev/input/event1 (SZH usb keyboard)

Aug 30 12:22:42 Tower elogind-daemon[1904]: Watching system buttons on /dev/input/event3 (SZH usb keyboard System Control)

Aug 30 12:22:42 Tower kernel: usb 1-6: reset high-speed USB device number 3 using xhci_hcd

Aug 30 12:22:42 Tower kernel: usb 1-1.3.1: reset full-speed USB device number 8 using xhci_hcd

Aug 30 12:22:42 Tower kernel: input: Thermaltake Tt eSPORTS Challenger Ultimate gaming keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/0003:04F2:0978.0009/input/input19

Aug 30 12:22:42 Tower kernel: hid-generic 0003:04F2:0978.0009: input,hidraw2: USB HID v1.11 Keyboard [Thermaltake Tt eSPORTS Challenger Ultimate gaming keyboard] on usb-0000:00:14.0-1.3.1/input0

Aug 30 12:22:42 Tower kernel: input: Thermaltake Tt eSPORTS Challenger Ultimate gaming keyboard Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.4/0003:04F2:0978.000A/input/input20

Aug 30 12:22:42 Tower kernel: input: Thermaltake Tt eSPORTS Challenger Ultimate gaming keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.4/0003:04F2:0978.000A/input/input21

Aug 30 12:22:42 Tower kernel: hid-generic 0003:04F2:0978.000A: input,hiddev96,hidraw3: USB HID v1.11 Device [Thermaltake Tt eSPORTS Challenger Ultimate gaming keyboard] on usb-0000:00:14.0-1.3.1/input4

Aug 30 12:22:42 Tower elogind-daemon[1904]: Watching system buttons on /dev/input/event4 (Thermaltake Tt eSPORTS Challenger Ultimate gaming keyboard)

Aug 30 12:22:43 Tower kernel: usb 1-1.1: reset full-speed USB device number 4 using xhci_hcd

Aug 30 12:22:43 Tower kernel: input: Logitech Gaming Mouse G502 as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.0/0003:046D:C332.000B/input/input23

Aug 30 12:22:43 Tower kernel: hid-generic 0003:046D:C332.000B: input,hidraw4: USB HID v1.11 Mouse [Logitech Gaming Mouse G502] on usb-0000:00:14.0-1.1/input0

Aug 30 12:22:43 Tower kernel: input: Logitech Gaming Mouse G502 Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.1/0003:046D:C332.000C/input/input24

Aug 30 12:22:43 Tower kernel: hid-generic 0003:046D:C332.000C: input,hiddev97,hidraw5: USB HID v1.11 Keyboard [Logitech Gaming Mouse G502] on usb-0000:00:14.0-1.1/input1

Aug 30 12:22:43 Tower elogind-daemon[1904]: Watching system buttons on /dev/input/event8 (Logitech Gaming Mouse G502 Keyboard)

Aug 30 12:22:44 Tower kernel: ata8.00: Enabling discard_zeroes_data

Aug 30 12:22:44 Tower kernel: sde: sde1

Aug 30 12:22:44 Tower kernel: vfio-pci 0000:01:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=none

Aug 30 12:22:44 Tower kernel: nvidia 0000:01:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=none

Aug 30 12:22:44 Tower kernel: ata8.00: Enabling discard_zeroes_data

Aug 30 12:22:44 Tower kernel: sde: sde1

Aug 30 12:23:59 Tower emhttpd: cmd: /usr/local/emhttp/plugins/user.scripts/startScript.sh /tmp/user.scripts/tmpScripts/nvidia powersave hourly/script

Aug 30 22:25:41 Tower webgui: Successful login user root from 10.10.10.116

Aug 30 22:27:11 Tower monitor_nchan: Stop running nchan processes

Aug 30 23:12:28 Tower kernel: usb 1-1: USB disconnect, device number 2

Aug 30 23:12:28 Tower kernel: usb 1-1.1: USB disconnect, device number 4

Aug 30 23:12:28 Tower acpid: input device has been disconnected, fd 13

Aug 30 23:12:28 Tower kernel: usb 1-1.3: USB disconnect, device number 6

Aug 30 23:12:28 Tower kernel: usb 1-1.3.1: USB disconnect, device number 8

Aug 30 23:12:29 Tower acpid: input device has been disconnected, fd 11

Aug 30 23:12:29 Tower kernel: usb 2-1: USB disconnect, device number 2

Aug 30 23:12:29 Tower acpid: input device has been disconnected, fd 12

Aug 30 23:36:50 Tower monitor_nchan: Stop running nchan processes

Aug 30 23:40:02 Tower emhttpd: read SMART /dev/sdb

Aug 30 23:40:09 Tower emhttpd: read SMART /dev/sdc

Aug 30 23:54:57 Tower emhttpd: spinning down /dev/sdb

Aug 30 23:54:59 Tower emhttpd: read SMART /dev/sdb

Aug 30 23:55:04 Tower emhttpd: spinning down /dev/sdc

Aug 30 23:55:37 Tower emhttpd: read SMART /dev/sdc

Aug 31 00:10:00 Tower emhttpd: spinning down /dev/sdb

Aug 31 00:10:28 Tower emhttpd: read SMART /dev/sdb

Aug 31 00:10:32 Tower emhttpd: spinning down /dev/sdc

Aug 31 00:11:09 Tower emhttpd: read SMART /dev/sdc

Aug 31 00:25:23 Tower emhttpd: spinning down /dev/sdb

Aug 31 00:25:24 Tower emhttpd: read SMART /dev/sdb

Aug 31 00:26:04 Tower emhttpd: spinning down /dev/sdc

Aug 31 00:26:36 Tower emhttpd: read SMART /dev/sdc

Aug 31 00:40:25 Tower emhttpd: spinning down /dev/sdb

Aug 31 00:40:52 Tower emhttpd: read SMART /dev/sdb

Aug 31 00:41:31 Tower emhttpd: spinning down /dev/sdc

Aug 31 00:42:06 Tower emhttpd: read SMART /dev/sdc

Aug 31 00:55:47 Tower emhttpd: spinning down /dev/sdb

Aug 31 00:55:48 Tower emhttpd: read SMART /dev/sdb

Aug 31 00:57:01 Tower emhttpd: spinning down /dev/sdc

Aug 31 01:10:49 Tower emhttpd: spinning down /dev/sdb

Aug 31 01:11:16 Tower emhttpd: read SMART /dev/sdb

The complete log is in the attachment.

Any idea whats going on?

error log unraid

Have you created a "spinup group" for a bunch of drives?

My experiences so far showed me (nothing official, Limetech does not investigate this so far), that if there is a spinup group, ONE of the drives instantly wakes up again when the others are all down.

Deleting the group solved the problem here (but of course now drives wake up again one after the other).

This is reproducable.

So, if you have such a group, get rid of it for now and watch if the problem goes away or not.

2 hours ago, MAM59 said:

Have you created a "spinup group" for a bunch of drives?

My experiences so far showed me (nothing official, Limetech does not investigate this so far), that if there is a spinup group, ONE of the drives instantly wakes up again when the others are all down.

Deleting the group solved the problem here (but of course now drives wake up again one after the other).

This is reproducable.

So, if you have such a group, get rid of it for now and watch if the problem goes away or not.

Unfortunately not.

It's just one data drive an one parity drive.

That's all.

And both spin up immediately after being spun down.

Docker and VM completely disabled and it still happens.

2 minutes ago, sillywalks said:

Unfortunately not.

It's just one data drive an one parity drive.

That's all.

a "group" can also contain a single disk only :-)

so better check the setting. disallow spinup groups globally.

But if this has nothing to do with spinup groups, there must be a program that is constantly writing to the drive (therefor the parity also needs to spin up).

12 minutes ago, MAM59 said:

a "group" can also contain a single disk only :-)

so better check the setting. disallow spinup groups globally.

But if this has nothing to do with spinup groups, there must be a program that is constantly writing to the drive (therefor the parity also needs to spin up).

Spin up groups are disabled. So unfortunately not the issue.

File activity plugin shows nothing whatsoever writing to the disk.

Open files also draws a blank

Installed plugins are:

Community Apps

Dynamix system temp

File activity 2

GPU stats

Intel GPU top

Nvidia driver

Tailscale

Un-get

Powertop (via un-get)

Unraid connect

User scripts

That's it. I'll try disabling them one by one and see if one of them is the cause.

start with powertop. it often is the source of evil things...

1 hour ago, MAM59 said:

start with powertop. it often is the source of evil things...

That was indeed the first one to go but still the issue persists.

too bad, but dont give up yet :-)

I think I will once again start with a fresh install and keep it as minimal as possible adding services one by one.

Bit of a pain but I really want the drives to stay spun down what with electricity prices being high.

It's still pretty strange that at one point it just started happening without me doing anything to the system.

I can even see th exact moment in the power readout of the smart plug, and I was in bed at that time :)

3 minutes ago, sillywalks said:

I can even see th exact moment in the power readout of the smart plug, and I was in bed at that time :)

Yeah I know these evil creepy hamsters very well...

BTW: what you see at night maybe the general cron job of UNRAID which fires up at 04:40. It is normal that all drives spin up at that time.

This may include disk checks and so on... keep that in mind...

Edited September 1, 2025Sep 1 by MAM59

I finally found the culprit.

I was using a home assistant integration to connect to the unraid api and that was for whatever reason keeping the disks constantly spun up.

If HA is trying to get smart status or temperature of the drives, then that does cause the drives to spin up. Maybe adjust HA and the integration to not query spun down drives