March 19, 20251 yr After several power disruptions, one of my data drives (xfs) became "unmountable" However Unraid doesn't seem to be attempting to emulate it (I have a parity drive) My array is one parity drive, (12TB) and two data drives (12TB, 4TB) -- It was previously 3 data drives, but one failed before I actually had any data in it So I just made a new configuration -- the power disruptions happened months *after* making the new configuration When I browse the contents of my shares I only get the data on the 4TB drive. I'm pretty confident the data is intact or at least can be rebuilt, since when I run the trial (windows) version of DiskInterals raid recovery I can "preview" all the data fine with all the folder structure and file names. (and all the media files can play from beginning to end without issue). I would like to avoid paying $200+ to be able to export the data. Does anyone know where to begin troubleshooting this? Or at least force unraid to emulate the "unmountable" disk? I've tried removing the disk from the configuration and it still didn't attempt to emulate it. edit: the post hasn't been approved by the mods yet, but I forgot to mention I ran testdisk, as well as IIRC xfs_repair? one couldn't recover the partition table, the other couldn't find any superblocks Edited March 19, 20251 yr by Ness
March 19, 20251 yr Author Well, here's the thing. the system is off, and I've connected the 4 drive bay to another computer to run the diskinternals scan I mentioned. Logs are in RAM and thus erased every boot right? Obviously I'd need to move the drives back before booting up the system with unraid on it. But what else should I do to make sure enough useful information is captured and what should I avoid doing to make sure nothing on the drives get disturbed as they are? I feel like I could just boot up and capture logs, but it likely wouldn't have enough useful information without actually doing something. I'm guessing bare minimum start in non-maintenance mode but 🤷♀️. I'm not avoiding taking diagnostics or anything, just the drive bay is plugged into another computer in R/O mode right now -- and not available to be put back into the server, So I might as well, ask and make sure i'm ready to capture whatever would be useful whenever doing so won't be disruptive. -- Rather than do it and not have anything because "the machine just got powered on and doesn't show anything useful" and then needing to do it again. Edited March 19, 20251 yr by Ness
March 19, 20251 yr Community Expert 5 hours ago, Ness said: the other couldn't find any superblocks This suggests xfs_repair was run on the disk, not the partition, do you remember the command you used? For more help we would need the diags, you start the array in the current state, it won't do any more damage, and only after that can we see if there's filesystem corruption on the emulated disk, which is the most likely problem.
March 19, 20251 yr Author It's *not* being emulated though... Otherwise i would consider just rebuilding the disk onto itself. I've had drives fail, and have unraid emulate contents. In those cases it states that the drive is being emulated, and I could access the content. In it doesn't state that, and going into the share doesn't show its contents. I think the command I used was xfs_repair -V -L [path] path being /dev/ [whatever showed in paranthesis in main] i think it was sdb. You're probably right. I assumed it would find partitions and scan/fix them recursively. In any case, It'll likely be a few hours before the tasks i'm running are finished and I can put the drive back on the unraid server and take diagnostics. I just wanted to clarify that the disk is *not* being emulated, and hoping that may provide some insight or narrow possibilities before I can grab diagnostics. Edited March 19, 20251 yr by Ness
March 19, 20251 yr Community Expert Solution 1 minute ago, Ness said: path being /dev/ [whatever showed in paranthesis in main] i think it was sdb. You're probably right. I assumed it would find partitions and scan/fix them recursively. That would almost certainly be the wrong path to use. You are normally better off running this from the GUI (from the dialog you get when clicking on the drive on the Main tab) as it the system then automatically gets the device name right.
March 19, 20251 yr Author I didn't realize that was available within the gui I'll certainly take a look the next time I run it. I won't do anything until I post diagnostics though.
March 19, 20251 yr Community Expert 10 minutes ago, Ness said: just wanted to clarify that the disk is *not* being emulated Possibly what you really mean is that the emulated disk is unmountable. We need to fix the emulated filesystem to make it mountable before trying to rebuild. Will wait for diagnostics.
March 21, 20251 yr Author Yes, sorry I didn't recognize the distinction but that is in fact what is happening. After removing the drive, the emuiated disk remains unmountable -- it's contents inaccessible from unraid. Here are my diagnostics. s3nas-diagnostics-20250321-1300.zip Edited March 21, 20251 yr by Ness
March 21, 20251 yr Community Expert The normal handling of drives unexpectedly becoming unmountable is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.
March 21, 20251 yr Author Thank you. Yeah, I'll run the xfs repair from the UI instead of command line.
March 21, 20251 yr Author will a message eventually pop up when it is finished? or is it something I need to grab from the log? edit: I'm an idiot I was afraid hitting refresh would stop the process when the dots indicator was on the screen. I opened another window and navigated to the disk and see the output of the running process. Edited March 21, 20251 yr by Ness
March 21, 20251 yr Author I'm guessing ...Fix then rebuild? I originally was going to rebuild onto itself, but I found a blank 12TB drive so I might build onto that instead. Just so I can take out the drive and work with some of it's contents while it's rebuilding... 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... out-of-order bno btree record 452 (174232297 787516) block 2/1 block (2,174232297-174640681) multiply claimed by bno space tree, state - 1 block (2,174640683-174642116) multiply claimed by bno space tree, state - 1 block (2,174642118-174647590) multiply claimed by bno space tree, state - 1 block (2,174647592-174797022) multiply claimed by bno space tree, state - 1 block (2,174797024-174853351) multiply claimed by bno space tree, state - 1 block (2,174853353-174939598) multiply claimed by bno space tree, state - 1 block (2,174939600-174958020) multiply claimed by bno space tree, state - 1 block (2,174958022-174989872) multiply claimed by bno space tree, state - 1 block (2,174989874-175012857) multiply claimed by bno space tree, state - 1 block (2,175012862-175018577) multiply claimed by bno space tree, state - 1 block (2,175018579-175018727) multiply claimed by bno space tree, state - 1 agf_freeblks 100437892, counted 99651460 in ag 2 agf_freeblks 61640402, counted 1871570 in ag 1 agf_longest 623324, counted 1671902 in ag 1 agi_freecount 62, counted 64 in ag 4 agi unlinked bucket 29 is 41565533 in ag 4 (inode=8631500125) ir_freecount/free mismatch, inode chunk 0/106671680, freecount 3 nfree 1 ir_freecount/free mismatch, inode chunk 2/445471296, freecount 6 nfree 2 finobt ir_freecount/free mismatch, inode chunk 0/1197857856, freecount 25 nfree 27 agi_freecount 25, counted 29 in ag 0 finobt ir_freecount/free mismatch, inode chunk 2/1350277376, freecount 10 nfree 14 agi_freecount 10, counted 18 in ag 2 agi_freecount 14, counted 0 in ag 1 agi_freecount 14, counted 0 in ag 1 finobt sb_fdblocks 817359246, counted 777234922 - 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 imap claims a free inode 2294426615 is in use, would correct imap and clear inode imap claims a free inode 2294426616 is in use, would correct imap and clear inode - agno = 2 imap claims a free inode 4698477910 is in use, would correct imap and clear inode imap claims a free inode 4698477911 is in use, would correct imap and clear inode imap claims in-use inode 4740438614 is free, would correct imap imap claims in-use inode 4740438615 is free, would correct imap data fork in ino 5624898173 claims free block 711511594 data fork in ino 5624989011 claims free block 711513029 data fork in ino 5625039316 claims free block 711518503 data fork in ino 5626233150 claims free block 711667935 data fork in ino 5626685187 claims free block 711724264 data fork in ino 5627375265 claims free block 711810511 data fork in ino 5627520237 claims free block 711828933 data fork in ino 5627707020 claims free block 711860785 data fork in ino 5627960785 claims free block 711883770 data fork in ino 5628006805 claims free block 711889490 data fork in ino 5628008214 claims free block 711889640 - 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... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 No modify flag set, skipping filesystem flush and exiting.
March 21, 20251 yr Community Expert Run the Fix option (and if it offers it zero the log). After that post new diagnostics taken with array started in normal mode (so we can check on the success of the repair) before attempting a rebuild.
March 21, 20251 yr Author Looks good to me! but Here's the diagnostics just in case. s3nas-diagnostics-20250321-1512.zip
March 21, 20251 yr Community Expert Browse to disk1, on lost+found folder, click +, Calculate and post the result
March 21, 20251 yr Author Calculate Occupied Space Name: lost+found Location: disk1 Last modified: 51 minutes ago Total occupied space: 0 B in 1 folder and 1 file
March 21, 20251 yr Community Expert Looks good! Looks like a single empty file. You can get rid of that if you want and lost+found share will go away. https://docs.unraid.net/unraid-os/manual/storage-management/#rebuilding-a-drive-onto-itself
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.