August 30, 2025Aug 30 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
August 31, 2025Aug 31 Community Expert To be clear you were not doing a parity swap, just a standard parity upgrade, though a parity swap won't work if the old parity was failing.Disk1 ius failing, so you won't be able to correctly sync a new parity drive. Reconnect the old parity and post new diags to see that SMART.
August 31, 2025Aug 31 Author 7 hours ago, JorgeB said:To be clear you were not doing a parity swap, just a standard parity upgrade, though a parity swap won't work if the old parity was failing.Disk1 ius failing, so you won't be able to correctly sync a new parity drive. Reconnect the old parity and post new diags to see that SMART.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
September 1, 2025Sep 1 Community Expert It would have been better if you hadn't started a parity sync and kept the old parity intact, but cancel it and run an extended SMART test on the old parity and post new diags.
September 2, 2025Sep 2 Author Alright, I stopped the sync and ran the extended SMART test; here are the new diags. tower-diagnostics-20250902-0323.zip
September 2, 2025Sep 2 Community Expert Solution The extended test passed, suggesting the disk is OK for now. Since you only have one data disk, parity will be a mirror, you can try doing a new config (tools - new config), then set old parity as disk1 and a new disk as parity, see if that mounts OK and the parity sync finishes without errors, but keep the old disk1 intact for now.
September 2, 2025Sep 2 Author 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
September 3, 2025Sep 3 Author 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 checkPhase 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.
September 3, 2025Sep 3 Community Expert 2 hours ago, MrShrip said:I'm assuming the next step is to just hit fixYep, and if it asks to zero the log, click that also.
September 4, 2025Sep 4 Author 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?
September 4, 2025Sep 4 Community Expert 2 hours ago, MrShrip said:and is running at 46-47 degrees. Is there anything else I should do to address that error?That's not too bad, but I like to keep disks under 45C
September 4, 2025Sep 4 Community Expert 6 hours ago, MrShrip said:Disk1 does have a heat warning and is running at 46-47 degrees.Have you closed up the computer case? Most cases have to closed up to have any air flow over the drives. IF you have to have the case open, try a external fan to provide additional air flow over the fan disk. For servers, you want the air to enter the case from the front, over the drives, and be exhausted in the rear. Edited September 4, 2025Sep 4 by Frank1940
September 5, 2025Sep 5 Author 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
September 6, 2025Sep 6 Community Expert That error should not make the server crash, but you can try booting in safe mode.
September 7, 2025Sep 7 Author Parity check completed with no errors and we are back in business 🥳. Thanks @JorgeB for all the help!
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.