Added a new drive to the array last night and left the array to erase contents overnight. Woke up this morning and as the drives were spinning up, a different drive got the red X treatment. Diagnostics attached.

tower-diagnostics-20261018-0623.zip

Your syslog shows disk11 (the WD 18 TB on sdr) stopped answering at 20:18 last night, about 27 minutes into the clear of the new disk: timeouts, “failed to IDENTIFY”, then the kernel disabled the device. No CRC errors, the drive simply vanished from the bus, so SMART couldn’t be read either. The red X only came at 06:07 when the array next touched it. Disk11 sits on the Marvell 88SE9215 card together with the new disk that was being cleared and disk1; Marvell cards are known to drop disks under load, so my guess is the card, not the drive. JorgeB will no doubt confirm or correct that and give you the exact steps; in the meantime: reboot, check disk11’s SMART, and don’t run the clear and a rebuild through that card at the same time.

Good to know about the Marvell card. Disk 1 is the parity drive so I'll move that off that card during this process. I'll go ahead and pull the new disk for the time being. I was planning on adding a second new drive as well, which would put four drives on that card where it's been running with only two drives so I think it's best to just replace the card altogether.

Seeing that disk 11 wasn't in use at the time and the errors weren't disk related, would there be any issues skipping the disk rebuild and running a new config using the existing data?

Two things from your diagnostics first: parity is the 32 TB with serial …K1S1KNN6 (sdo) and it sits on an Intel port; disk1 is the other 32 TB (…K1S1L37P, sds), and that one is on the Marvell card. So moving disk1 off the card is right, parity doesn’t need to move?

On skipping the rebuild: the “write error” at 06:07 was Unraid’s own read-error correction (it reconstructed the four sectors from parity and tried to write them back, that write failed, hence the disable), so it doesn’t look like anything of yours was written to the emulated disk11 before the array stopped at 06:21; the physical disk is very likely identical to what parity emulates. Even so, I’d rebuild rather than New Config: a rebuild rewrites one 18 TB disk from parity, so you don’t have to trust that the physical disk11 matches what parity emulates; New Config takes the disk as it is and then needs a full parity sync over all 17 disks, which takes longer. If disk11’s SMART is clean after the reboot, rebuild it onto itself: Stop, set disk11 to “no device”, Start, Stop, assign it again, Start. Replace the card first, so the rebuild doesn’t run through it.

Hopefully you still have a backup just in case—there are a lot of disks....🤔

Edited 7 hours ago7 hr by UnraidSecretaryOffice

ok, I pulled the SATA card out of another array I didn't have up and running and swapped it out. Where in the diagnostics can I look to see who makes the chipset?

I forgot about Parity being the first disk in the GUI, not Disk 1. Regardless, Disk 1 will be a second parity drive once I am done adding disks, so I'm still going to move it off the SATA card.

SMART report on disk 11 was fine. I am running the data rebuild on it right now. I am leaving disk 17 unassigned until this is done.

Thanks for the assistance.

Edited 1 hour ago1 hr by johngalt