Today I decided to start using a different approach to managing my drives in my array. I thought I'd start spinning them down after an hour of no usage. This seemed reasonable until I ran into an issue when I opened windows explorer on my PC to access a local file which has a share folder from my array mapped as a network drive. I traced my array drives all spinning up to the opening of windows explorer. This led to five of my drives having four read errors each, which I assume was related to the drives not being fully spun up when explorer tried to access some data on them.

My filesystem seemed to have some issues as I couldn't see any of the folders/files on the mapped network drive. I went ahead and stopped my array and started it back up, which unRaid reported as error free and the errors disappeared on the main tab in the GUI. I was also able to browse the folders properly after doing this.

So, my primary question is, how can I prevent windows explorer from doing this in the future? I removed a network folder that had been pinned automatically to quick access by windows, but there's also a few files in the history of explorer too. Should I turn off indexing for the mapped network drive?

Also, should I be concerned about those five drives throwing four read errors each and the filesystem not being accessible until I stopped and started it back up?

tower-syslog-20251221-0439.zip

Edited December 21, 2025Dec 21 by chris206

15 hours ago, chris206 said:

traced my array drives all spinning up to the opening of windows explorer. This led to five of my drives having four read errors each, which I assume was related to the drives not being fully spun up when explorer tried to access some data on them.

I am fairly confident accessing your data over SMB would not cause read errors.

If anything this is likely hardware related.

I would think that it could be power related, or your SAS card might be overheating. How are you powering the disks and are you using power splitters? Also do you have active cooling on your SAS card?

I am using power splitters. There should be a max of five drives on each SATA power cable if I'm recalling correctly. The SAS card itself has a noctua 40mm fan attached to it that is constantly spinning at ~3k rpm. I could certainly open up the back of my tower and trace each drive back to their respective power cable.

Also, I would suggest posting your FULL diagnostics not just the syslog.

1 minute ago, MowMdown said:

Also, I would suggest posting your FULL diagnostics not just the syslog.

Done. I often forget to include that one, thanks.

tower-diagnostics-20251221-1506.zip

Are you using a RAID card in RAID/IR mode?

01:00.0 RAID bus controller [0104]: Adaptec Series 7 6G SAS/PCIe 3 [9005:028c] (rev 01)
	Subsystem: Adaptec Device [9005:0507]
	Kernel driver in use: aacraid
	Kernel modules: aacraid

Just now, MowMdown said:

Are you using a RAID card in RAID/IR mode?

01:00.0 RAID bus controller [0104]: Adaptec Series 7 6G SAS/PCIe 3 [9005:028c] (rev 01)
	Subsystem: Adaptec Device [9005:0507]
	Kernel driver in use: aacraid
	Kernel modules: aacraid

I believe it should be in IT mode? I would not be surprised if it's setup wrong, I'm certainly an amateur.

To elaborate a bit further. My drives are actually connected to a SAS expander card, that is then plugged into the SAS raid controller. So perhaps the SAS expander had temp issues upon spinup? I need to recheck my drive positions in my tower, but based on previous notes it seems that the drive errors were spread across three different power splitters each on their own individual SATA power cable back to the PSU.

Edit: Also, I should add, the 14TB drives and the 4 in unassigned devices are plugged directly into the RAID card through two of the external ports in a DAS.

Edited December 21, 2025Dec 21 by chris206

Dec 20 21:43:07 Tower emhttpd: read SMART /dev/sdj

Dec 20 21:43:17 Tower kernel: sd 1:1:37:0: [sdj] tag#525 UNKNOWN(0x2003) Result: hostbyte=0x05 driverbyte=DRIVER_OK cmd_age=10s

Dec 20 21:43:17 Tower kernel: sd 1:1:37:0: [sdj] tag#525 CDB: opcode=0x28 28 00 40 07 f6 1c 00 00 04 00

Dec 20 21:43:17 Tower kernel: I/O error, dev sdj, sector 8594108640 op 0x0:(READ) flags 0x0 phys_seg 4 prio class 0

Dec 20 21:43:17 Tower kernel: md: disk1 read error, sector=8594108576

Dec 20 21:43:17 Tower kernel: md: disk1 read error, sector=8594108584

Dec 20 21:43:17 Tower kernel: md: disk1 read error, sector=8594108592

Dec 20 21:43:17 Tower kernel: md: disk1 read error, sector=8594108600

The read errors are occurring right after spin up, suggesting a compatibility issue between the controller and the drives. My suggestion for now would be to disable spin down with that combo.