I have an array of 17 drives with a XFS encrypted filesystem.

Last months I have had some problems with drives suddenly failing, pretty new drives. And when I replace them, the new ones fail right away...or after hours/days.

Its all in a pretty decent enclosure with SAS backplate.

All drives are 8TB with 2 drives for parity.

Powersupply is 1200W (I overestimated a bit, intend to add GPU later) and is currently peaking at 320W.

I am left with either a cable or backplate problem. But that also seems a bit unlikely. I had this issue 2 months ago and couldnt for the life of me figure it out. I ended up swapping drives twice, and it suddenly worked fine again.

Now its back. I am pretty sure I have 3-4 drives on my shelf that actually are working fine.

Also, this time a ghost-drive has appeared. I have double-checked the serial of all drives 4 times, yet the system claims there is an active drive plugged in, that is not there.

I think I have created a diagnostic file, I can see some error about the drives disconnecting. Hoping someone more experienced in Unraid can help out.

EDIT: The current problem is that 2 drives have failed, I replaced them with 2 new drives that failed immediately as well.

nexus-diagnostics-20260228-1037.zip

Edited February 28Feb 28 by Einar Eliassen

On mobile now so can't look at Diagnostics yet.

Connection problems are much more common than bad disks, hope you haven't spent too much money replacing disks that weren't really the problem.

I'll check later when I can. Someone else may chime in.

I have kept the drives that were failing because I had a feeling something wasnt right.

So I can maybe get them working again.

But how can the connections be stable for like 6 months...then suddenly become unstable?

Server is sitting pretty with no changes....

With so many drives, power would be one suspect. Maybe PSU is enough, but how is the power distributed? Ideally, no more than 4 drives per PSU cable. Any power splitters?

Are you sure your controllers have plenty of cooling?

SMART for disabled disk13 looks fine. You were rebuilding disk15 and it disconnected. It is now unassigned.

Can't tell anything about your filesystems since the array is not started in normal (not maintenance) mode.

I haven't looked at SMART for all disks, but the few that seemed to be having problems since you last rebooted all seem to have good SMART reports.

Do any disks have SMART warning (👎) on the DASHBOARD page?

As mentioned, this looks more like a power/connection issue.

Yes, there are some splitters because the backplane has those Molex power connections which doesnt exist on current PSU cables these days.

I will take a new look at how its all managed and maybe redistribute the load somehow.

How do I get the drives enabled again for a new try ?

Edited March 1Mar 1 by Einar Eliassen

If they are being emulated correctly, the general recommendation is to rebuild on top, ideally after trying to do something about the power/connections.

6 hours ago, Einar Eliassen said:

those Molex power connections which doesnt exist on current PSU

Not seen any PSU like that. Molex connectors that aren't specifically labeled as being for disk connections still have the correct voltages and pinouts. PSUs typically have cables like that in addition to SATA connectors.

Ok, I have finally gotten hold on some new cables.

So to get this working again, I tried switching around the 2 drives that were failing to get them to erase and rebuild.

But as I was doing this...drive 16 suddenly reported to the a wrong drive. And it was stating which drive was the correct one (serial number), but that IS the drive assigned in that slot.

What is going on ? Now the array wont start in normal or maintenance mode!

Please post the current diagnostics.

30 minutes ago, JorgeB said:

Please post the current diagnostics.

I booted into safemode to see if that helped me do anything....but I guess not.

nexus-safemode-diagnostics-20260305-1736.zip

Disk16 is showing as wrong because it was recorded with a 4TB partition.

Post the output from

fdisk -l /dev/sdu

33 minutes ago, JorgeB said:

Disk16 is showing as wrong because it was recorded with a 4TB partition.

Post the output from

fdisk -l /dev/sdu

Disk /dev/sdu: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors

Disk model: WDC WD80EFAX-68K

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 16773120 bytes

Disklabel type: gpt

Disk identifier: AD4E49B8-BC08-4B08-8BEC-E58153393E5E

Device Start End Sectors Size Type

/dev/sdu1 2048 4982527 4980480 2.4G Linux RAID

/dev/sdu2 4982528 9176831 4194304 2G Linux RAID

/dev/sdu5 9453280 5860519007 5851065728 2.7T Linux RAID

/dev/sdu6 5860535104 7814023007 1953487904 931.5G Linux RAID

/dev/sdu7 7814039104 15627846207 7813807104 3.6T Linux RAID

15 minutes ago, Einar Eliassen said:

/dev/sdu7 7814039104 15627846207 7813807104 3.6T Linux RAID

This is likely the data partition, meaning it's only using half the disk. Post the output from

blkid /dev/sdu7

2 minutes ago, JorgeB said:

This is likely the data partition, meaning it's only using half the disk. Post the output from

blkid /dev/sdu7

/dev/sdu7: UUID="e45da7a6-4b00-4e35-9ff3-53af5d1a590a" TYPE="crypto_LUKS" PARTUUID="b3419e82-856d-4bd7-8f33-4a7c3b80ab74"

It has the expected LUKS signature, and that partition matches exactly what Unraid was detecting.

You can try this (assuming parity is still valid).

-Tools -> New Config -> Preserve current assignments: All -> Apply

-Check all assignments and assign any missing disk(s) if needed, including the new disks you want to rebuild

-IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked)

-Stop array

-Unassign disk13 and disk15

-Start array (in normal mode now), and post new diagnostics

P.S.Disk16 will be detected as 4TB again, but you can fix that later.

4 minutes ago, JorgeB said:

It has the expected LUKS signature, and that partition matches exactly what Unraid was detecting.

You can try this (assuming parity is still valid).

-Tools -> New Config -> Preserve current assignments: All -> Apply

-Check all assignments and assign any missing disk(s) if needed, including the new disks you want to rebuild

-IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked)

-Stop array

-Unassign disk13 and disk15

-Start array (in normal mode now), and post new diagnostics

P.S.Disk16 will be detected as 4TB again, but you can fix that later.

This will not erase the data in the array right ?

Correct, and as long as parity is valid, it should emulate the two disabled disks.

After just starting the array again the first time it all looks good ? All disks are green.

Do I still need to remove and assign the drives again ?

If disks 13 and 15 are the old disks (with all the existing data), and assumed to be healthy, they may not need rebuilding, but note that if they are not OK, you may lose the ability to rebuild them, or at least make it more difficult.

They were the old disks but they were disabled. Emulated. So to try to use them again/rebuild, I try to have them switch places.

But now it seems to have them both working again ?

Right now Write Corrections to Parity is checked.

I kinda want to uncheck it, start the array up in normal mode and see if I can browse the drives for any data.

A parity check won't start after a new config, as long as you checked "parity is already valid" as instructed.

Disk 15 is now showing as unmountable: wrong or no filesystem

If I click to format this, it doesnt seem this will rebuild it ?

DO NOT FORMAT!

Post new diagnostics

I have started a check on the drive....looks like its gonna take many hours.