1 hour ago, vanarebane said:

Has this problem been addressed after that?

 

Unfortunately not, as there is not much this plugin can do in way of fixing or working around this. I had a brief exchange with @limetechregarding a potential Unraid mod that could help with these types of drives, but it turns out this would require a substantial architectural change to the inner parts of Unraid, which is too complex and hence not in the cards.

Hello! I cannot for the life of me make this work.

I have a 9 Drives in my server, the box is a Dell Poweredge 720XD with a PERC h310 mini as controller the drives are all Seagate EXOS X16 12 TB (ST12000NM002G) and I cannot spin them down. I have tried do it in unraid's webui, the green button spins but nothing changes.

From console when trying sg_start  --readonly --pc=3 /dev/sdj I get the error:
 

start stop unit: transport: Host_status=0x07 [DID_ERROR]

Transport error
START STOP UNIT command failed
sg_start failed: Transport error

 

and this shows in the logs:
 

Mar 17 18:33:23 SuperServer kernel: sd 1:0:8:0: [sdj] tag#16 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=13s
Mar 17 18:33:23 SuperServer kernel: sd 1:0:8:0: [sdj] tag#16 CDB: opcode=0x1b 1b 00 00 00 30 00
Mar 17 18:34:02 SuperServer kernel: sd 1:0:8:0: Power-on or device reset occurred

Any advice would be appreciated.

Thx!

Hi all 

 

 

So I have just started using the array again with a few Samsung 3.84tb SAS ssds and noticed none of them are spinning down seen this plugin on community apps but it still doesn't seem to be spinning them down happy to provide any further information if needed. 

 

 

Drives are MZILT3T8HBLS_007

 

Iv also got a load of NVME disks U.2 Micron_7300_MTFDHBE7T6TDF these don't look to be spinning down either any suggestions would me much appreciated! 

 

 

 

On 3/29/2025 at 8:16 PM, Sargent_-_Merkie said:

So I have just started using the array again with a few Samsung 3.84tb SAS ssds and noticed none of them are spinning down

SSDs do not spin down. 

 

Look at the bright side though - they do not spin up, either.

 

 

On 3/14/2025 at 8:46 PM, doron said:

Unfortunately not, as there is not much this plugin can do in way of fixing or working around this. I had a brief exchange with @limetechregarding a potential Unraid mod that could help with these types of drives, but it turns out this would require a substantial architectural change to the inner parts of Unraid, which is too complex and hence not in the cards.

That is unfortunate.

For the record, I have used both Toshiba MG06ACA800E SATA and the SAS version. The SATA versions did spin down normally without the SAS plugins help. but I did have many Disk failures over three months until the whole array failed with data loss.

 

I figured the SATA drives were old and found a deal on SAS drives that just happened to be the same build and those SAS drives had also disk failures (I managed to include those disks in the SAS spin down plugin) and after removing that plugin, the disks have not failed once.

 

I can only hope that Unraid team sees the need to rework the Unraid internally in the future, but if this is only for old disks I can see that it's not worth ofcourse.

 

By chance, is there any maintained list of the disks that fail over this issue?

Edited April 4, 20251 yr by vanarebane

On 4/4/2025 at 1:20 PM, vanarebane said:

For the record, I have used both Toshiba MG06ACA800E SATA and the SAS version. The SATA versions did spin down normally without the SAS plugins help. but I did have many Disk failures over three months until the whole array failed with data loss.

Indeed; in the SATA realm, the spin-down process is better defined in the standards and is fully implemented across the board. There's actually a reason for that difference, but that is unrelated to the matter at hand.

On 4/4/2025 at 1:20 PM, vanarebane said:

 

I figured the SATA drives were old and found a deal on SAS drives that just happened to be the same build and those SAS drives had also disk failures (I managed to include those disks in the SAS spin down plugin) and after removing that plugin, the disks have not failed once.

Right. That makes sense, since it is most likely that the failures you've seen are not actual drive failures, but rather a phenomenon of the SAS spin-down implementation in these drives. As discussed above, some SAS drives, when spun down, expect an explicit "spin up" command, or else they stay still. In Unraid, that behavior would translate to an i/o error the next time the drive is needed for an i/o.

On 4/4/2025 at 1:20 PM, vanarebane said:

 

I can only hope that Unraid team sees the need to rework the Unraid internally in the future, but if this is only for old disks I can see that it's not worth ofcourse.

Not "old" disks, mainly (I'm assuming) the fact that only a small fraction of the customers even use SAS drives, so it is looked at as something a bit "eccentric". At least that is my impression. Which is why I developed the plugin in the 1st place. But I wish that as well  

On 4/4/2025 at 1:20 PM, vanarebane said:

By chance, is there any maintained list of the disks that fail over this issue?

This thread has it all 🙂 also, if you look at the "exclusions" file in the plugin directory (/usr/local/emhttp/plugins/sas-spindown/) you can find some drives that were notoriously bad in that sense, so they were explicitly excluded from being acted on.

Wanted to leave a big "thank you!" for your plugin. saved my ass (or the money in my pocket :o))

I am using a lsi91214i4e-hba with one sata-hdd and one sas-hdd (ST6000NM0095 - 6TB). It never spun down but the sata-hdd, which is connected to the hba also, did. So i installed your plugin and hoped the best. It took a few restarts and some playing with the automatic spin-down-command (i think), but now the sas-hdd goes into idle:

mhttpd: read SMART /dev/sdc

Server emhttpd: spinning down /dev/sdc

Server SAS Assist v2024.11.25: Spinning down device /dev/sdc

yay!

18 hours ago, Thermalbad said:

Wanted to leave a big "thank you!" for your plugin. saved my ass (or the money in my pocket :o))

Thanks for reporting. Glad to hear it is working well for you!

May be you can put MG07 in the exclusions list. I have used MG07 with this plugin for a moth and the system continue showing wrong. At last my array was broken. As i remove the plugin, my system worked well for about 2 months untill now.I don't know if this is an isolated case.Just for report. Sorry about my terrible English. Hoping you can understand

On 6/15/2025 at 10:48 AM, kimsu said:

May be you can put MG07 in the exclusions list. I have used MG07 with this plugin for a moth and the system continue showing wrong. At last my array was broken. As i remove the plugin, my system worked well for about 2 months untill now.I don't know if this is an isolated case.Just for report. Sorry about my terrible English. Hoping you can understand

Thanks for reporting!

Would you be so kind as to run this on your console (when the plugin is installed - you can remove it immediately thereafter):

/usr/local/emhttp/plugins/sas-spindown/sas-util

and post:

1. The console output

2. The file /tmp/sas-util-out

If you prefer, you can send these to me privately.

(BTW your English is surely 100x better than my control of your language 😜)

After successfully using the plugin for months and a problem with the unraid-usb-dongle later, my sas-drive didn´t spin down anymore. Not for one second. I reinstalled the plugin, restarted multiple times but it didn´t help.

The problem ist solved by now - it wasn´t the plugin itselve, it wasn´t unraid´s fault.... after i fixed my usb-dongle something went wrong with my appdata-folder. there were processes which continously accessed my sas-hdd, so it never spun down.

For all of you who are having problems with the spindown - there could be processes that prevent your hdd from spinning down. Just my 2 cents, maybe it helps one of you guys. i translated via gemini, as i am from germany....... ;)


## Guide to Diagnosing and Troubleshooting Unraid Disk Spindown Issues

This guide provides the necessary steps and commands to identify which process is actively keeping your SAS drive (or any disk) from spinning down.

### 1\. Preparation: Identifying the Drive

First, you need to find the Mount Point /mnt/diskX) for your SAS drive, as this is the path you will use in all subsequent commands.

1. List Mount Points:

df -h

*Look for the path you suspect is active (e.g., /mnt/disk4) and note the device name if displayed.*

2. Find the Device Name and Partition UUID (Optional, but helpful):

ls -l /dev/disk/by-id

*This helps to connect the physical drive to its device name sdX).*

## 2\. Identify Active File Accesses (Fuser)

The most effective way to detect a process accessing a directory or file (and thus the disk) is by using the fuser command.

Important: Replace /mnt/diskX in the commands below with the actual mount point of your SAS drive (e.g., /mnt/disk4).

| Goal | Command | Purpose |

| :--- | :--- | :--- |

| All Accesses | fuser -m -v /mnt/diskX | Lists all processes that have files open within that directory. |

| Detailed Output | lsof /mnt/diskX | (Alternative/Supplementary) Shows a more detailed list of open files and the processes using them. |

### Interpreting the fuser Output:

The output will provide one or more PIDs (Process IDs).

```

/mnt/diskX: <user> <PID>c (Example: root 1234c)

```

* PID: The number of the process accessing the disk.

* *<user>:** The user running the process.

* *c:** Indicates the process has its current working directory in that path.

-----

## 3\. Map PIDs to Containers/Services (PS)

Once you have a suspicious PID (e.g., *1234**), use the ps command (Process Status) to find out which container or service that process belongs to.

### A. Mapping by PID

Enter the PID to see the full command name:

```bash

ps -o pid,user,cmd -p 1234

```

### B. Searching Specifically for Docker Processes

To display all processes that directly access your SAS drive, which are often part of a Docker container:

```bash

ps aux | grep /mnt/diskX

```

*Look in the CMD column for container-related names like /usr/bin/docker-proxy... or the name of an Appdata service.*

-----

## 4\. Common Causes and Final Steps

### A. Check the Volume Configuration

The most common cause is a Docker container whose volume settings are configured to write directly to that specific disk:

* Ensure that the Appdata directory for active containers is not located on this specific SAS disk, especially if you have duplicated Appdata folders.

* Verify that your Docker Image and Libvirt Image (VM storage) are not stored on this SAS disk. If they are, the disk will remain active as long as containers or VMs are running.

### B. Final Troubleshooting Steps

1. Stop the identified service/container based on the PID you found.

2. Attempt a spin down manually through the Unraid GUI.

3. If the spin down is successful, the identified service was the culprit. Adjust the container's volume mapping in Unraid to point to your main Appdata share /mnt/user/appdata/) instead of the specific disk /mnt/diskX).

I just ordered a 6TB SATA drive from a used server part ebay store but received a 6TB Seagate Exos SAS drive instead. Fortunately I have a hard drive cage that is compatible with SAS drives and an LSI HBA card, so I was able to get it up and running, but I noticed like all of you that the SAS drive would not spin down. Followed the process outlined in this reddit thread (https://www.reddit.com/r/unRAID/comments/11r4ock/comment/jc8i1za/?utm_source=share&utm_medium=web2x&context=3) to install your plugin and it looked like everything was working properly until the mover tried to move some files to that disk. Then I got an 'X' next to the SAS drive and had to remove it from my array. Since Unraid 7.2 is supposed to offer some support for SAS drives I tried installing that and while the command: sg_start --stop /dev/sdX worked to spin things down while it was in unassigned devices (still had a green ball next to it but the temperature reading was an *), it also unmounted it and gave me the following error codes:

17:48:06: UNKNOWN(0x2003) Result: hostbyte=0x00

17:48:06: I/O error, dev sdh, sector 0 op 0x0:(READ)

17:48:06: Buffer I/O error on dev sdh, logical block 0

Does this mean that this drive is just incompatible with my server unless I want to leave it powered on 24/7?

BTW contacted the ebay seller and told them item was not as described (I ordered a SATA drive after all) and they sent me a beat to shit HGST drive from June 2014 with gouges on the front like it had been thrown into a trash can with other drives.

On 3/14/2025 at 2:46 PM, doron said:

Unfortunately not, as there is not much this plugin can do in way of fixing or working around this. I had a brief exchange with @limetechregarding a potential Unraid mod that could help with these types of drives, but it turns out this would require a substantial architectural change to the inner parts of Unraid, which is too complex and hence not in the cards.-

I went away from SAS disks for a while but recently picked up four new WD 18TB disks DOM 2024.

For some reason I cant get the disks to spin down at all, even manually through the GUI. Any thoughts on what might be cuasing this or information I can send your way to help address it? I've included my server diag zip.

maverick-diagnostics-20260119-1219.zip

17 hours ago, Ezekial66 said:

I went away from SAS disks for a while but recently picked up four new WD 18TB disks DOM 2024.

For some reason I cant get the disks to spin down at all, even manually through the GUI. Any thoughts on what might be cuasing this or information I can send your way to help address it? I've included my server diag zip.

maverick-diagnostics-20260119-1219.zip

Do you get any sense data for the new SAS drives?

/usr/sbin/sdparm -C sense /dev/sdx replace x with the drive letters

Hello everyone!

I installed the plugin because I installed the drives SAS:

Vendor: SEAGATE

Product: ST16000NM002G

Revision: E003

Compliance: SPC-5

And they don't want to turn off:

Jan 30 15:04:27 unraid emhttpd: spinning down /dev/sdx

Jan 30 15:04:27 unraid SAS Assist v2024.11.25: Spinning down device /dev/sdx

Jan 30 15:04:57 unraid emhttpd: read SMART /dev/sdx

Can anyone tell me what needs to be done to properly force the drives to turn off?

root@unraid:~# /usr/sbin/sdparm -C sense /dev/sdx

/dev/sdx: SEAGATE ST16000NM002G E003

root@unraid:~# /usr/local/emhttp/plugins/sas-spindown/sas-util

SAS Spindown Utility (v20240218.01)

sdf | ST16000NM002G | 1000:0064:1000:30c0 | n/a |

sdg | ST16000NM002G | 1000:0064:1000:30c0 | n/a |

sdy | ST16000NM002G | 1000:0064:1000:30c0 | n/a |

sdx | ST16000NM002G | 1000:0064:1000:30c0 | n/a |

Run completed. The output is at /tmp/sas-util-out.

sas-util-out

Edited January 30Jan 30 by mark949

20 minutes ago, mark949 said:

Vendor: SEAGATE

Product: ST16000NM002G

Revision: E003

Compliance: SPC-5

And they don't want to turn off:

Jan 30 15:04:27 unraid emhttpd: spinning down /dev/sdx

Jan 30 15:04:27 unraid SAS Assist v2024.11.25: Spinning down device /dev/sdx

Jan 30 15:04:57 unraid emhttpd: read SMART /dev/sdx

Many Seagate drives appear not not work well with this plugin - i.e., not to respond to the "spin down" SAS wire instruction with a temporary spindle spindown; however, from your log excerpt it appears that the issue is different - something in your Unraid setup keeps issuing i/o against the drive. The message unraid emhttpd: read SMART /dev/sdx is an indication of an i/o being issued, 30 seconds after the drive was sent to sleep.

Suggest you explore who is keeping the drive busy, and check whether you can silence that entity. Might be another plugin, docker, VM, a remote access to one of your shares etc.

6 minutes ago, doron said:

Many Seagate drives appear not not work well with this plugin - i.e., not to respond to the "spin down" SAS wire instruction with a temporary spindle spindown; however, from your log excerpt it appears that the issue is different - something in your Unraid setup keeps issuing i/o against the drive. The message unraid emhttpd: read SMART /dev/sdx is an indication of an i/o being issued, 30 seconds after the drive was sent to sleep.

Suggest you explore who is keeping the drive busy, and check whether you can silence that entity. Might be another plugin, docker, VM, a remote access to one of your shares etc.

These new disks haven't been allocated to the data array yet.

There are no plugins or containers that work with them, they are currently in "Unassigned Disk Devices"

1 minute ago, mark949 said:

These new disks haven't been allocated to the data array yet.

There are no plugins or containers that work with them, they are currently in "Unassigned Disk Devices"

Understood. Still, something is waking them up 30 secs later and causing Unraid to issue a SMART read.

Let's put that aside for a moment and check whether your drives are even spinning down at all.

Can you run the following line on your console and paste the output:

sg_start -rp3 /dev/sdx ; sleep 3s; sdparm -C sense /dev/sdx

12 minutes ago, doron said:

Understood. Still, something is waking them up 30 secs later and causing Unraid to issue a SMART read.

Let's put that aside for a moment and check whether your drives are even spinning down at all.

Can you run the following line on your console and paste the output:

sg_start -rp3 /dev/sdx ; sleep 3s; sdparm -C sense /dev/sdx

root@unraid:~# sg_start -rp3 /dev/sdx ; sleep 3s; sdparm -C sense /dev/sdx

/dev/sdx: SEAGATE ST16000NM002G E003

Additional sense: Standby condition activated by command

1 hour ago, mark949 said:

root@unraid:~# sg_start -rp3 /dev/sdx ; sleep 3s; sdparm -C sense /dev/sdx

/dev/sdx: SEAGATE ST16000NM002G E003

Additional sense: Standby condition activated by command

Okay this is actually good - it means the drive does go into spindown when the command sends it there.

Question now is what wakes it up 30sec later. This is for you to figure out. It might be related to the unassigned devices situation, but I'm not sure.

Hi and thanks for the great plugin and all the work you're putting in to try to fix it. I wondered if there was something you could suggest for one of my drives that spins down and immediately spins up again.

It's unfortunately a Seagate ST20000NM002D - I have 5 of them and 4 behave perfectly, just one has this problem. I've removed this from the array and wiped it, so it shouldn't nothing should be accessing it. I'm not using fan control either.

Some information follows:

root@Srvr:/mnt/cache/system/custom/SeaChest# ./SeaChest_PowerControl -d /dev/sg5 --spinDown

==========================================================================================

SeaChest_PowerControl - Seagate drive utilities - NVMe Enabled

Copyright (c) 2014-2025 Seagate Technology LLC and/or its Affiliates, All Rights Reserved

SeaChest_PowerControl Version: 3.7.2 X86_64

Build Date: Oct 10 2025

Today: 20260221T210511 User: root

==========================================================================================

/dev/sg5 - ST20000NM002D - - E005 - SCSI

Successfully sent command to spin down device. Please wait 15 seconds for it to finish spinning down.

root@Srvr:/mnt/cache/system/custom/SeaChest# ./SeaChest_PowerControl -d /dev/sg5 --transitionPower standby_z

==========================================================================================

SeaChest_PowerControl - Seagate drive utilities - NVMe Enabled

Copyright (c) 2014-2025 Seagate Technology LLC and/or its Affiliates, All Rights Reserved

SeaChest_PowerControl Version: 3.7.2 X86_64

Build Date: Oct 10 2025

Today: 20260221T210616 User: root

==========================================================================================

/dev/sg5 - ST20000NM002D - - E005 - SCSI

Power Mode Transition Successful.

Please give device a few seconds to transition.

Hint:Use --checkPowerMode option to check the new Power Mode.

root@Srvr:/mnt/cache/system/custom/SeaChest# ./SeaChest_PowerControl -d /dev/sg5 --transitionPower sleep

==========================================================================================

SeaChest_PowerControl - Seagate drive utilities - NVMe Enabled

Copyright (c) 2014-2025 Seagate Technology LLC and/or its Affiliates, All Rights Reserved

SeaChest_PowerControl Version: 3.7.2 X86_64

Build Date: Oct 10 2025

Today: 20260221T210648 User: root

==========================================================================================

/dev/sg5 - ST20000NM002D - - E005 - SCSI

Transitioning power modes not allowed on this device

Thanks!

23 minutes ago, AndyS said:

I wondered if there was something you could suggest for one of my drives that spins down and immediately spins up again.

It's unfortunately a Seagate ST20000NM002D - I have 5 of them and 4 behave perfectly, just one has this problem. I've removed this from the array and wiped it, so it shouldn't nothing should be accessing it. I'm not using fan control either.

In practically all cases I've looked at, when a drive does in fact spin down and then spins back up it means that something is accessing it. Could be user access, could be plugin, could be anything - but someone is issuing i/o. If your drive is wiped and out of the array, could it be Unassigned Devices?

To test that, I'd actually format it and put it back into the array, empty. Also, I'd disable as many plugins as I can, just for the investigation. Then, add them one by one. A bit tedious perhaps but might reveal the culprit.

On 1/20/2026 at 6:16 AM, SimonF said:

Do you get any sense data for the new SAS drives?

/usr/sbin/sdparm -C sense /dev/sdx replace x with the drive letters

I'm so sorry for not responding. Seems I had my notifications off and never realized you responded. I appreciate your help I didnt mean to leave you hanging or make you feel that you were wasting your time.

I ran the command and this was the response I got for each of the drives X 4:

/dev/sdae: OOS18000G OOS1

Additional sense: Idle condition activated by timer

On 4/7/2026 at 10:11 AM, Ezekial66 said:

I'm so sorry for not responding. Seems I had my notifications off and never realized you responded. I appreciate your help I didnt mean to leave you hanging or make you feel that you were wasting your time.

I ran the command and this was the response I got for each of the drives X 4:

/dev/sdae: OOS18000G OOS1

Additional sense: Idle condition activated by timer

@doron Hey there I just wanted to check in if you may have any thoughts on these SAS disks that arent spinning down.

40 minutes ago, Ezekial66 said:

@doron Hey there I just wanted to check in if you may have any thoughts on these SAS disks that arent spinning down.

The Seagate drives are renowned for not always playing well with the mechanism we use to spin SAS drives down.

That said, how do you determine they are not spinning down?

The sense data you provided seems to indicate the drive is trying to idle down via an internal timer, a feature that's independent and unrelated to what we do.

Can you, right after asking the drive to spin down via the UI, run that sense command and see if it outputs anything different?