peteopp

That should be fine. I resolved emulated disk5 and all appears well.

I’m arguing with AI on this and could use an Unraid lesson. My current array . All smart passes Parity - 12tb. Old -data1 - 10tb - good -data2 - 10tb - good -data3 - 10tb - good -data4 - 10tb - good -data5 - 12tb - MISSING -data6 - 5tb - very old -data7 - 5tb - very old I bought two 18tb drives. I’m trying to upgrade the parity and data5 disk without putting stress on the system given the age of a couple of the drives. Can I just follow parity swap section or does that not apply here ? 1 . Move 18tb into parity Move 12tb parity into data 5. Hit button to copy parity to new parity. Then start array and allow new parity and data disks to rebuild onto data5 (which is the old parity disk)

Disk5 smart attached. disk5_smart.txt

Correct, perfect 1st pass with 0 read and no other errors.

With disk5 emulated, I did a filesystem check and repair. Output for both attached. disk5_xfs_fix.txt Looks like a clean repair. I don't see a Lost+found folder in disk5 and currently have the array started in normal mode emulating disk5. Path forward.... I unfortunately have 4 10TB drives that I could put into the system, but disk5 is 12TB. If it's the best path, i can purchase a new drive. I also purchased a 18TB that I was planning to replace my 12TB parity with. Given I've successfully did a ddrescue image of disk5, is there any real danger/risk to just reusing disk5 and let parity rebuild on-top of it? Given - i have a ddrescue .img of disk5 preserved. 1. Buy a new 12TB drive and rebuild disk5 off parity. This allows me to reserve disk5 in-case i need to walk backwards. 2. Format/clean disk5 and let unraid treat it as a new drive and have parity rebuild onto original harddrive. 3. Rebuild physical disk5 using xfs repair, add back into the array and rebuild parity. Not sure why i would like this option? Really appreciate the help JorgeB and trurl! Almost done.

I have the parity plus all disks (minus disk5) working in the array. Disk5 is successfully emulated. I already pulled all my essential data to a backup drive (YAY!). Attaching diagnostics which should have recent SMART runs. I believe everything is passed. given the xfs report i reported for disk5 up above, would you recommend just putting a new disk in and rebuilding disk5 off the emulation? Or is it easier and faster just to repair disk5, as you said it most likely reflects parity anyways.fridge-diagnostics-20260118-2127.zip

I’m currently using ddrescue and doing 4. I don’t quite follow the comment on 1. Though. Disk 5 “wrong” disk got kicked out of the array , that was the original problem that started this spiral of crap. Wouldn’t the parity be able to rebuild a new disk correctly if I just removed disk 5 from the system and booted up the array? Do this vs repairing xfs repair disk 5 and accepting data loss.

Do i have any other better options? What would you recommend? Disconnect the wrong disk w/ a new disk and see if i can boot the rest of the drives (including parity) and then rebuild the wrong disk. If I went this route, could I check the health of the parity drive first to determine if it's still in a good state? run xfs repair and accept the data loss. I believe this would invalidate my parity drive? boot up all drives, start array in maintenance mode if possible, and try and run xfs repair on the wrong disk drive, which would maintain parity.

I first went down the road of mounting my 'wrong disk' drive into a linux environment and tried to inspect the drive. This is the output i got (Sorry looks like formatting is bad): xfs_repair_wrong_disk.txt

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 workflowXFS file system repair is fully automated through the WebGUI: Click the CHECK button (no options to enter) 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 Click FIX to automatically repair the file system If needed, a ZERO LOG button may appear 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.

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.

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.

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>

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?

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:~#

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.

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.

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. 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. blkid /dev/sdX1 fdisk -l /dev/sdX 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? 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.

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?

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?

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.

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. 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. 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