June 11, 20251 yr Hi,My pendrive containing the Unraid config got in a bad state and the UD notified me about it. I was directed to change the usb device and followed accordingly. I tried to fix the issue putting the pendrive on Windows and running its fix utility, but no luck. I proceeded to create a new boot device using the "Unraid USB Creator", selected the same OS version (6.12.15), and after it, copied the config/ and extra/ to the new pendrive. I opened Folder Properties of the old and new folders to see if they are the same size, they had, as expected.After this, I turned off the server, plugged in the new USB and booted. After this, the Unraid Dashboard asked to replace the register key to the new USB, I did it. So far so good.I dont recall precisely, but between getting my old USB failling and replacing the key on the new USB my server got restarted some times (doing "shutdown" via UD) and I remember waiting more than 90s to it to power off (probably, doing a forcefulll shutdown I think). After this, my Disk 1 started to show "Unmountable: Unsupported or no file system".I saw around that running xfs_repair -L could repair it, but as it can cause loss of data I prefered to open this thread asking for help.Can you guys check out my attached logs and instruct me how to get my array back online? Thanks. tower-diagnostics-20250611-0157.zip
June 11, 20251 yr Author Did via UD with the default -n flag:Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 6 - agno = 7 - agno = 3 - agno = 4 - agno = 5 - agno = 1 - agno = 2 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... Maximum metadata LSN (7:1487724) is ahead of log (7:1487705). Would format log to cycle 10. No modify flag set, skipping filesystem flush and exiting.
June 12, 20251 yr Community Expert 12 hours ago, edassis said:Did via UDYou must do it using the GUI, see the link.
June 12, 20251 yr Community Expert UD typically means Unassign Devices plugin, run it again without -n or nothing will be done.
June 12, 20251 yr Author 1 hour ago, JorgeB said:UD typically means Unassign Devices pluginOh got it.Done:Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.
June 12, 20251 yr Author Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata - found root inode chunk Phase 3 - for each AG... - scan and 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 1 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 2 clearing reflink flag on inodes when possible Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (7:1487733) is ahead of log (1:2). Format log to cycle 10. doneSeems to had completed fine. Should I stop the array and restart in normal mode now? Edited June 12, 20251 yr by edassis
June 13, 20251 yr Author I rebooted the server and the shares didn't get mounted. I put the array in maintenance mode again, ran the xfs_repair, it pointed to log divergences again. I proceed to run xfs_repairwith the -L flag. And got the output in the attached file.This time, I disabled docker before rebooting. Did the reboot. The array started, the shares were mounted.Opened the Settings > User Utilities > Backup/Restore Appdata and started a manual backup:After the backup, I came back to the Shares view and they got unmounted:Seems to me that the shares break in the first writes to the array. I think maybe some plugin or script is misbehaving and affecting the shares links? I will be grateful for any help on diagnosing this. Thanks.xfs_repair -L.md tower-diagnostics-20250613-1201.zip Edited June 13, 20251 yr by edassis
June 13, 20251 yr Community Expert Solution Jun 13 11:47:24 Tower kernel: ata2: EH completeJun 13 11:47:27 Tower kernel: ata2: SATA link down (SStatus 0 SControl 310)Jun 13 11:47:32 Tower kernel: ata2: link is slow to respond, please be patient (ready=0)Jun 13 11:47:37 Tower kernel: ata2: COMRESET failed (errno=-16)Jun 13 11:47:42 Tower kernel: ata2: link is slow to respond, please be patient (ready=0)Jun 13 11:47:43 Tower kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)Jun 13 11:47:43 Tower kernel: ata2.00: configured for UDMA/100Jun 13 11:47:43 Tower kernel: ata2.00: limiting speed to UDMA/33:PIO4Jun 13 11:47:44 Tower kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)Jun 13 11:47:44 Tower kernel: ata2.00: configured for UDMA/33Jun 13 11:50:32 Tower kernel: XFS (md1p1): Metadata CRC error detected at xfs_allocbt_read_verify+0x12/0x5a [xfs], xfs_bnobt block 0x316777740 Jun 13 11:50:32 Tower kernel: XFS (md1p1): Unmount and run xfs_repairJun 13 11:50:32 Tower kernel: XFS (md1p1): First 128 bytes of corrupted metadata buffer:Jun 13 11:50:32 Tower kernel: 00000000: 7c 38 b1 de dc 68 2c 3c ce ec 49 d5 70 53 76 77 |8...h,<..I.pSvwJun 13 11:50:32 Tower kernel: 00000010: 70 63 54 00 fd 98 df 55 5f d1 8c e6 c0 c6 6d 5c pcT....U_.....m\Jun 13 11:50:32 Tower kernel: 00000020: f7 24 d0 03 30 cc cc 35 d2 c2 d9 ef 0e 4a c6 bf .$..0..5.....J..Jun 13 11:50:32 Tower kernel: 00000030: 61 d8 7f f1 1d 15 be 06 f4 74 f4 d7 3a 0d 12 87 a........t..:...Jun 13 11:50:32 Tower kernel: 00000040: f2 fa 87 3e e2 c2 3e 26 4a cb f9 03 5c 89 b6 6b ...>..>&J...\..kJun 13 11:50:32 Tower kernel: 00000050: 87 5a 51 d8 b0 8d 47 59 ae 34 df c3 3b ed cb 9f .ZQ...GY.4..;...Jun 13 11:50:32 Tower kernel: 00000060: 09 75 4d 7c 67 42 ac 91 18 4a 05 31 5e d5 77 48 .uM|gB...J.1^.wHJun 13 11:50:32 Tower kernel: 00000070: c3 1e fd f1 52 bc 67 07 b0 c1 ea 4d 7e 5c 93 51 ....R.g....M~\.QThere are ata errors logged for disk1 just before more xfs corruptions are detected, this looks like a power/connection issues, and probably what is corrupting the filesystem, replace both cables and post new diags after array start.
June 14, 20251 yr Author On 6/13/2025 at 12:38 PM, JorgeB said:this looks like a power/connection issues, and probably what is corrupting the filesystem, replace both cables and post new diags after array start.I had just one sparing sata cable, used it on disk1. Disconnected all SATA cables (power and data) and cleaned its contacts with a rubbber and contact cleaner. Swapped the PSU power cable too. Diagnostics attached. tower-diagnostics-20250614-1546.zip
June 15, 20251 yr Author Running xfs_repair from the GUI without options: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.Proceeded to run with -L(logs attached).After it, stopped the array and rebooted the server. Took a look on syslog, no ATA errors this time. Array started normally. Services are operational. yayThank you @JorgeB for the help!I will be marking your previous response as the solution.xfs_repair-L.txt tower-diagnostics-20250614-2101.zip Edited June 15, 20251 yr by edassis
June 15, 20251 yr Community Expert Looks OK, but keep monitoring the syslog for a few days to make sure it's resolved.
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.