JorgeB

Never heard of IT mode for drives, do you hear them spinning up and are they detected in the HBA BIOS?

Changed Status to Closed Changed Priority to Other

Closing this since you've started a new thread on the general support forum.

So that confirms what I said, share has files in the array, 6 Bytes is likely just the folder, you can delete it or change the share to cache=prefer and run the mover and after that it will show protected.

Click on compute for that share and post a screenshot together with the diagnostics.

That doesn't matter, what matters if the share has data on the array or not, you can check by clicking on "compute" for that share.

IIRC some LSI HBAs don't work on an x1 slot, but it won't hurt to try assuming the slot is open ended, if it works bandwidth would not be bad with 4 typical hard drives.

Please post the diagnostics.

Is the array protected with parity and without any disabled disk? If not any share that has files there will be unprotected.

It's disk5

Yep, it should be done ASAP since if another disk fails Unraid likely won't be able to rebuild it without errors. Yes.

Nothing major for now but start by replacing the cables for that disk.

I believe shfs is single threaded for a single operation.

Looks more like a general support issue but next time it happens download the diagnostics before rebooting and attach them here.

Run another non correcting check, if the exact same errors are found just correct them, if not post new diags.

Since the last changes on v6.8 turbo write doesn't help much with array to array transfers, those will always be slow, try to plan things ahead as much as possible to avoid them, for large transfers and assuming backups exist it's faster to disable parity and re-sync when done.

The syslog. No, just looks like the linked issue.

Log looks clean for now and the emulated disk is mounting, assuming contents look correct you can rebuild on top.

Server load is quite high, and there's something reading and writing to at least two disks in the array, so it might be normalnormal, but you can stop everything if you want to find out what it is.

Basically yes, you can also update using the GUI, not a bad idea to read the release notes at least for the major releases, like v6.9.0, 6.10.0 and 6.11.0.

Possibly a board/kernel compatibility issue, you can try booting a different Linux distro to confirm.

Because you are using an LSI HBA with a known affected Ironwolf disk model and the errors happened just after spin up.

Nov 1 07:13:07 Monster kernel: ata2: link is slow to respond, please be patient (ready=0) Nov 1 07:13:10 Monster kernel: ata2: SATA link down (SStatus 0 SControl 300) Nov 1 07:13:16 Monster kernel: ata2: link is slow to respond, please be patient (ready=0) Nov 1 07:13:16 Monster kernel: ata3: link is slow to respond, please be patient (ready=0) Nov 1 07:13:20 Monster kernel: ata3: COMRESET failed (errno=-16) Nov 1 07:13:20 Monster kernel: ata2: COMRESET failed (errno=-16) Nov 1 07:13:21 Monster kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Nov 1 07:13:21 Monster kernel: ata2.00: supports DRM functions and may not be fully accessible Nov 1 07:13:21 Monster kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Nov 1 07:13:21 Monster kernel: ata3.00: supports DRM functions and may not be fully accessible ### [PREVIOUS LINE REPEATED 1 TIMES] ### Nov 1 07:13:21 Monster kernel: ata3.00: configured for UDMA/133 Nov 1 07:13:21 Monster kernel: ata2.00: supports DRM functions and may not be fully accessible Nov 1 07:13:21 Monster kernel: ata2.00: configured for UDMA/133 Also having issues with disks 1 and 2, do they share anything in common other than the controller, like a power splitter?

Post new diags.

Could be either, first check if all affected disks share a miniSAS cable or splitter, if they only share the PSU I would start there.