I'm new to all this, so bear with me. I dove into unRAID about a month ago and finally have everything running the way I want. Except something is preventing my disks from staying spun down for more than a few minutes at a time. This happens after manually spinning them down and I've also got them set to spin down after 15 minutes. I've used Active Streams, Open Files, and File Activity to try to figure out what's causing it, but nothing listed in those references the disks during the times the disks spin up (they only reference files that are on my cache drive). I've set Plex to only do library scans once a day and to only scan when changes are made. I've even set mover to only run automatically once a week (I occasionally run it manually), just to make sure in-progress downloads aren't on the array. Docker is on cache. No VMs. Transcoding is on cache. I think I've successfully moved anything that would regularly need to be accessed onto cache.

 

I've got smb shares mapped on my Windows computer. Could that be the cause?

 

I'd really appreciate it if someone could help me keep my disks spun down. I'm trying to save power, plus they're pretty loud and in my living room. I live in a small studio, so unfortunately I can't just put the server in another room.

 

 

Edit because I can't figure out how to delete this: I think I figured it out. Some remnants of folders I thought I had completely moved to cache were still on a few of the disks. After manually moving the remnants of those files to the cache drive, those disks are spinning down properly. So all but one disk is spinning down now, and I think that one is damaged, which is preventing it from spinning down. It has never been used and Scrutiny is telling me it's got a Command Timeout error.

box-diagnostics-20240208-0844.zip

Edited February 9, 20242 yr by notalek
updated with solution

7 minutes ago, notalek said:

I've got smb shares mapped on my Windows computer. Could that be the cause?

Most applications can browse the network these days, so I've not seen any need to map shares in a long time.

 

Is Windows trying to index the mapped share?

3 minutes ago, trurl said:

Is Windows trying to index the mapped share?

I don't believe so. Indexing Options in Windows says "Indexing Complete" and I none of the shares are within any of the included locations that Windows should be indexing.

I think I figured it out. Some remnants of folders I thought I had completely moved to cache were still on a few of the disks. After manually moving the remnants of those files to the cache drive, those disks are spinning down properly. So all but one disk is spinning down now, and I think that one is damaged, which is preventing it from spinning down. It has never been used and Scrutiny is telling me it's got a Command Timeout error.

43 minutes ago, notalek said:

I think that one is damaged, which is preventing it from spinning down. It has never been used and Scrutiny is telling me it's got a Command Timeout error.

Looks like you must be talking about disk4. You don't want to keep questionable disks in the array. It could prevent you from rebuilding a different disk if that becomes necessary.

 

Parity by itself can rebuild nothing. In order to reliably rebuild every bit of a disk, it must be able to reliably read every bit of all other disks.

https://docs.unraid.net/unraid-os/manual/what-is-unraid/#parity-protected-array

 

Run an extended SMART self-test on disk4.

 

Do any of your disks show SMART warning ( 👎 ) on the Dashboard page?

@notalek

1 minute ago, trurl said:

Run an extended SMART self-test on disk4.

 

If the disk is bad you must either replace it, or shrink the array and rebuild parity without it.