Not sure what I did wrong on this one. And unfortunately it's just been a spiral of bad misfortunes.

I'm on version 7.2.3 with an 1-drive parity and on 1/12 selected the 'add pool' button. I was attempting to add 4 small ssds as a new pool to use for VMs. I named it vm and selected 4 slots.

When I did this I shutdown the array (not sure why) and then noticed my disk5 in my array had a red x and i saw the error 'the replacement disk must be as big or bigger than the original.' The disk selected was the original 12TB disk. I deleted the new pool and took all 4 drives back to unassigned. No fix. I toggled the x drive dropdown between one of the unassigned drives and then back to the original. Unraid replaced with a green X, so I started the array. It indicated that the error drive had no filesystem and i believe i was getting all the normal options for rebuilding the drive (didn't take a screenshot or look to closely unfortunately). It also complained one of my cache drives also was in the same situation of needing a format.

I didn't click anything more at that point. I stopped the array and shutdown the system. My plan was to replace the drive in the morning and just rebuild the drive through parity. I swapped the drive w/ the 'suspicious' drive and bagged the old one. When i went to boot up, i got no power to the devices. I determined this to be a failed/failing power supply. I bought a new power supply.

(side rant of bad luck)

Unplugging one of my hard-drives broke the sata power plastic l-bracket. I had to buy an adapter and do surgery to get the connector hot glued back on and connected correctly. So this one is in a fun risky state.

I plugged everything back in w/ the new hard-drive and new power supply only to discover that my parity drive is making a clunking sound, not detected and i presume to be failed. I'm guessing the power supply failure took it out.

So now i'm in a 2 drive failed state that includes the 1 wrong disk and 1 parity drive failed. I have two questions at this point.

1. Given i'm not sure what even happened to my array originally, SMART passed. is it possible the original data disk isn't bad, or at least fully bad? Googling keeps indicating the newConfig tool might fix this situation, but not experienced enough there of the risk and have low confidence level.

2. If i do have in fact two failed drives, do i at least have a option to rebuild the array accepting some loss (vs all loss).

I'm posting logs, but this was after a restart. Not sure how valuable it is. Unfortunately I've had to learn a couple life lessons on this one and will be losing semi-important data that I did not backup properly. I really appreciate any advice or pointing in the right direction here.

(this is before the power failure and loss of the parity)

fridge-safemode-diagnostics-20260112-2302.zip

Edited January 16Jan 16 by peteopp
Clarification

2 hours ago, peteopp said:

So now i'm in a 2 drive failed state with only 1 parity.

Diags still show parity as OK, only one "wrong" disk, to confirm, parity is no longer available?

Yes I believe that’s confirmed parity no longer available. Sorry, that was misleading, updated the original post.

After a power supply failure, the drive exhibits a rhythmic clunking and doesn’t show in bios.

Edited January 16Jan 16 by peteopp

If parity is gone, the best is trying to correct the "wrong" disk.

Post the output from:

blkid /dev/sdX1

fdisk -l /dev/sdX

Replace X with the correct letter for disk5, it was /dev/sdc in the screenshot, but can change with a reboot.

Man i'm frustrated.

I plugged back in the old 'wrong' drive and it's also not being detected in bios. I thought i heard an abnormal sound on the first boot up. I did a reboot and it sounded better, but still not detected in bios. When I shut it down, it definitely made some clanky sounds.

Only thing I can think of is that the PSU killed it on shutdown? 😕 I will also note it's the same type of white-label WD shucked drive that the parity was that also failed.

Any last ditch effort to recover that data w/o professional data recovery services?

Edited January 16Jan 16 by peteopp

If it's making strange noises, typically it's a mechanical issue, not related to the PSU.

I had two drives failed within the exact same time period. I would assume the PSU would be to blame for killing it?

I thought it was the multiple startup attempts w/ the old PSU that didn't start the drives that killed them, but maybe it was the PSU shutting down that did it? It was on a UPS at the time.

Best guess is that the wrong disk was already the disk failing.

Given i'm now at 2 confirmed failed drives. What's the best way of inspecting what i've lost (or still have)? Can i assign the remaining drives as unassigned and view each individually?

Edited January 16Jan 16 by peteopp

Did you try to use a modular PSU cable that wasn't supplied with the PSU? There is no standard pinout and using a wrong modular cable has fried many drives.

Funny story. I bought the new psu as a warehouse deal and it came with a cable that i was about to use. right before i booted it up i came to the realization that the cable just didn't match the other two supplied cables. Sure enough , the pinout going into the PSU was wrong. Talk about Amazon F'ing you over. I am the one that chose the warehouse deal though, lol.

Another fact i just realized. Both failed drives are WD white label shucked drives. I forgot about the whole 3.3v pinout mod to get these to function correctly. I originally made custom cables for my case w/o the 3.3v mod. W/ the new PSU, i didn't think about that fact. So both drives were getting 3.3v during this time of 'clunking' sounds and failure to appear in bios. This is one of the parity drives and 1 disk that I'm referring to.

I'm diving back into the 3.3v mod and how much risk of mechanical failure i may have induced myself at this point, but I think there's still a sliver of hope i can get 1-2 of these drives booted if I just do the mod. However i feel this is still a weaved unraid/hardware problem and not sure the best way to navigate this, being sensitive to the data loss possibility as well.

also to reiterate, the parity drive was making far more noises during operation than the data disk drive. the disk drive was only making very light sounds on the first boot, and made no sounds on the 2nd boot with only clunking sounds on spin-down.

Options after 3.3v mod both drives.

1. Try and start the wrong disk. This has the least mechanical sounds. If detected in bios, proceed on and try and rebuild the array using the NewConfig option. Or at least attempt the command like originally requested. I feel this would allow me to recover data and the plan would still work even if I lost SOME data due to some sectors being bad from the mechanical noise it emitted w/ the 3.3v attached.

   1. blkid /dev/sdX1

      fdisk -l /dev/sdX

2. Try and start the parity disk. If detected in bios, proceed on and try and rebuild the array w/ the missing disk using the parity. I fear that all that clunking may have damaged at least some sectors and if it's not perfect parity, i assume parity doesn't work?

3. Rather than focus on integrating them back into the array, just focus on getting them to appear in bios and then clone the drive or backup manually not using the array. Not knowledgeable in that subject.

I could still do option 2 first and use that as an experiment drive, as i do feel that drive has faced some mechanical consequences of my actions and have doubts using it still as a parity to rebuild the array is a likely possibility. Feel free to disagree though!

I really appreciate the help everyone. Anxiety levels have been through the roof.

Edited January 16Jan 16 by peteopp

25 minutes ago, peteopp said:

made custom cables for my case w/o the 3.3v mod

Just a MOLEX-SATA splitter will work for that since MOLEX only has 4 pins

Just now, trurl said:

MOLEX only has 4 pins

+12, +5, Gnd, Gnd

Understand. i originally made the custom cables (years ago) for routing and keeping things clean.

I currently have the configuration setup to run off a molex cable and i'm ready to boot up one of the drives, if that's a solid plan. I'm just trying to be cautious and not cause further damage to the drive.

Which should i try first if i do it? parity, data disk? my plan was just to boot to bios and verify if it's displayed.

Edited January 16Jan 16 by peteopp

1 minute ago, peteopp said:

boot to bios and verify if it's displayed.

good start

Tested the parity drive.

2 seconds of slight clank noise on startup. Went away. Discovered in bios. Turned off. Full clanking sound on spin down.

thoughts on next step? im betting i can at least get the data disk discoverable as well.

I booted just the 'wrong disk' disk 5 drive by itself.

output running command on disk5.

blkid /dev/sdX1

fdisk -l /dev/sdX

root@Fridge:~# blkid /dev/sdb1

/dev/sdb1: UUID="7cc35300-8d3a-4f85-ab57-2ef1ef23a753" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="3eb93511-f9ca-461d-a5d4-151667d662cd"

root@Fridge:~# fdisk -l /dev/sdb

Disk /dev/sdb: 10.91 TiB, 12000138625024 bytes, 23437770752 sectors

Disk model: WDC WD120EMFZ-11

Units: sectors of 1 * 512 = 512 bytes

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

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

Disklabel type: gpt

Disk identifier: F13208B8-A644-444D-AE9E-27348004A00D

Device Start End Sectors Size Type

/dev/sdb1 64 23437770718 23437770655 10.9T Linux filesystem

root@Fridge:~#

Edited January 16Jan 16 by peteopp

Post diagnostics so we can see SMART report for all connected disks now.

Given my test results on the parity drive,
Tested the parity drive.

2 seconds of slight clank noise on startup. Went away. Discovered in bios. Turned off. Full clanking sound on spin down. Concerned about the health of that drive more so than disk5.

would you boot up w/ the parity too to capture all diagnostics and smart report?

Edited January 16Jan 16 by peteopp

If you never power it up again it is as good as dead.

First, I want to sincerely thank you for the guidance you’ve provided so far. It’s been incredibly helpful.

I wanted to ask for your advice regarding data preservation. If protecting the data on Disk 5 is the most important priority, would I have a better chance of securing the critical files by mounting that drive in a Linux environment first and manually copying off the most important data before attempting to recover the array?

I really value your insight and want to make sure I take the safest approach possible.

Thank you again for your time and support.

commands

sudo fdisk -l

sudo mkdir /mnt/<source_disk>

sudo mount -o ro /dev/sdb1 /mnt/<source_disk>

ls /mnt/<source_disk>

Edited January 17Jan 17 by peteopp

Unless you mount the drive readonly, you will invalidate parity if you mount it outside the array.

You could just try to mount it in Unraid with Unassigned Devices.

I already tried mounting one of the drives as unassigned and it threw and error and didn't let me.

Jan 16 13:42:04 Fridge unassigned.devices: Mount of 'sdd1' failed: 'mount: /mnt/disks/HITACHI_H0H72121CLAR12T0: mount() failed: Function not implemented. dmesg(1) may have more information after failed mount system call.' Jan 16 13:42:04 Fridge unassigned.devices: Partition 'HITACHI H0H72121CLAR12T0' cannot be mounted.

Do you know what filesystem it is supposed to be?

I believe they should all be xfs (first screenshot).

just to be clear, i just used the ui and buttons. Didn't do any commands.

Edited January 17Jan 17 by peteopp

Can you check filesystem on it with Unassigned Devices?

I booted two drives. One is a brand new drive. (10Tb), the other is from the array. (5TB).

The link mostly talks about starting in the array, which i assumed didn't apply here. All i did was remove the disk from the array to make it visible in the unassigned.

Even if i can get the drive/s mounted as unassigned, how can i pull or transfer the data w/o dockers or shares up? EDIT, seems like Midnight commander would be a good option.

I also found my unassigned settings to be in destructive mode. Seems like a good idea to take that off for now?

Do you want me to execute this workflow? (Won't this ruin my parity potentially?)

XFS automatic repair workflow

XFS file system repair is fully automated through the WebGUI:

1. Click the CHECK button (no options to enter)

2. Check results:

   • No corruption detected: Shows "no filesystem corruption detected" and the CHECK button remains

   • Corruption detected: Shows "filesystem corruption detected" and a FIX button appears

3. Click FIX to automatically repair the file system

4. If needed, a ZERO LOG button may appear

5. Shows "filesystem repaired" when the process is complete

This automated system eliminates the need for users to manually enter repair options and ensures the correct repair sequence is followed.

Edited January 17Jan 17 by peteopp