MrShrip

Parity check completed with no errors and we are back in business 🥳. Thanks @JorgeB for all the help!

Well I was just about to come on here and say everything looked good, mark the problem as solved, and thank you for your help, but now I can't access the web UI no matter what I try. After an hour or so of unsuccessful troubleshooting, I plugged a monitor and keyboard into the box and saw the error attached. After looking through older help threads showing the same error, I suspect this has to do with a custom user script I had set to run every night to move files from the cache to the array. My guess is that setting a new configuration without updating the script caused the error and my current predicament. I really have no idea if my suspicions are correct, and even if so, I have no clue what I should do to fix this. crond (1954) exit status 135 fron user root rusrlocalenhttppluginsdynanixscript.pdf

Alright, it mounted and the parity check has been running all day with no errors so far. Disk1 does have a heat warning and is running at 46-47 degrees. Is there anything else I should do to address that error?

Ok, it reads that the file system is corrupted, which I kind of expected. I'm assuming the next step is to just hit fix and pray it works? Here are the results of the file system check Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... agf_freeblks 171702887, counted 171702879 in ag 0 agi unlinked bucket 0 is 414497216 in ag 0 (inode=414497216) agi unlinked bucket 1 is 414497217 in ag 0 (inode=414497217) agi unlinked bucket 54 is 144917302 in ag 10 (inode=21619753782) agi unlinked bucket 55 is 144917303 in ag 10 (inode=21619753783) agi unlinked bucket 56 is 144917304 in ag 10 (inode=21619753784) agi unlinked bucket 57 is 144917305 in ag 10 (inode=21619753785) sb_icount 10560, counted 10496 sb_ifree 1259, counted 1197 sb_fdblocks 1808944096, counted 1865044642 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... unknown block state, ag 0, blocks 31541056-31541063 - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 6 - agno = 9 - agno = 4 - agno = 5 - agno = 7 - agno = 8 - agno = 2 - agno = 10 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 414497216, would move to lost+found disconnected inode 414497217, would move to lost+found disconnected inode 21619753782, would move to lost+found disconnected inode 21619753783, would move to lost+found disconnected inode 21619753784, would move to lost+found disconnected inode 21619753785, would move to lost+found Phase 7 - verify link counts... would have reset inode 414497216 nlinks from 0 to 1 would have reset inode 414497217 nlinks from 0 to 1 would have reset inode 21619753783 nlinks from 0 to 1 would have reset inode 21619753784 nlinks from 0 to 1 Maximum metadata LSN (1:425388) is ahead of log (1:425362). Would format log to cycle 4. No modify flag set, skipping filesystem flush and exiting.

Not sure if I somehow configured something incorrectly, but the old parity is now disk1 and the new drive is set as parity, but it says disk1(old parity) is "Unmountable: wrong or no file system". tower-diagnostics-20250902-1444.zip

Alright, I stopped the sync and ran the extended SMART test; here are the new diags. tower-diagnostics-20250902-0323.zip

Thanks for the reply and the clarification. So I put in the old parity drive and assigned it to its original slot, diagnostics attached. tower-diagnostics-20250831-1216.zip

Basically what the title says. About a week ago I got several notifications that both my data and parity drive had failed a SMART check. I went and looked at the smart attributes and the reported uncorrected error count had been steadily increasing for both drives. I shut the array down and ordered some replacement drives. The replacement drives are 2tb larger than the old drives and after looking at the unraid docs it seemed the best procedure was to swap the parity drive and then the data drive. In the span of less than 15 minutes, there were already over 900 parity sync errors found and the reported uncorrected raw value of the old data drive had jumped from 80 to over 200. How should I proceed here? I'm more concerned with damaging the new drives than I am with data loss. Do I just let the parity sync continue despite the rapidly increasing error count, do I replace both bad drives and deal with the data loss, or is there some other, more preferable course of action? Diagnostics .zip attached. Any help would be greatly appreciated tower-diagnostics-20250830-1628.zip