Got a red 'x' and "Unmountable: No file system".  Followed the wiki instructions for a check/repair.  Got this:

 

Phase 1 - find and verify superblock... 
Phase 2 - using internal log 
- zero log... 
Invalid block length (0x0) for buffer 
Log inconsistent (didn't find previous header) 
empty log check failed 
zero_log: cannot find log head/tail (xlog_find_tail=5)

 

Then tried -L then press "check" for a repair but nothing happens.   Thanks in advance.

 

tower-diagnostics-20210302-1839.zip

Why are you running such an old version of Unraid? There were problems with some of the older versions of the XFS repair tool. You may need to upgrade to get the repair to work.

 

Also, better if we can get Diagnostics with the array started. There are many things diagnostics can't tell us until the array is started.

 

Why do you still have ReiserFS disks?

6 hours ago, trurl said:

You may need to upgrade to get the repair to work.

This would be the first thing to try.

Silly me.  So sorry for the post before being on the latest version.  Upgraded.

Big difference with the new scan, in that the log was huge (attached).  The -L repair ran (also a huge log, attached).  Re-started array in normal mode, but Drive1 still has red 'x'.  Says it's unmounted.  Ran a new scan, and that one was much shorter and didn't seem to have anything clearly wrong.  I feel I'm now missing something obvious, no?

 

BTW, this all started when doing a lengthy scan of my array content by a new media server.

tower-diagnostics-20210303-0835.zip Drive1 check after repair.txt drive1 repair.txt Drive1 check.txt

According to those diagnostics disk1 is mounted but disabled. Unmountable and disabled are independent conditions.

 

Unmountable means corrupt filesystem which needs repair.

 

Disabled means the disk was kicked out of the array and is no longer being used, instead it is emulated from parity. It has to be rebuilt because it is out-of-sync.

 

Looks like you were able to repair the filesystem of the (emulated) disk1, and there is a share anonymized as l--------d. This is the lost+found folder where all the files the repair couldn't figure out got dumped.

 

Possibly the physical disk isn't as bad as the emulated disk, so if you can rebuild to a new disk and keep the original we can take a look at the original to see if you can get files from it.

Thanks a ton for the quick replies.  Makes total sense.  What are your thoughts about just rebuilding to the existing disk? 

If you rebuild to the same disk you will lose any chance of seeing what is on that disk and the result of the rebuild will be exactly what you have with the emulated disk now. Your repair logs looked like a lot was probably lost or at least not cleanly recovered. Did you take a look in lost+found?

Another possibility would be to see if the original disk can be mounted as an Unassigned Device to see if you can copy anything off it. Or if it is unmountable, try to repair it outside the array to see what you can get after repair.

 

If it turns out the disk is mountable and looks like it has most of your files then you might even put it back in the array with New Config and rebuild parity instead of rebuilding the data disk.

 

But since you only have single parity, your array is unprotected until the disk is rebuilt, whether to the same or a new disk (or parity is rebuilt with New Config). Rebuilding to a new disk would be my recommendation then you can take your time to see what might be recovered from the original.

 

I'm trying to handle this remotely from work, but as of the update, WOL isn't working, so had to wait for someone to manually wake my unraid.  An issue for another time...

 

As you theorized, the lost+found had a bunch of stuff missing from the emulated disk (3577 files/folders). 

 

When you ask if I can mount the disk as Unassigned, do you mean clicking the folder/magnifying glass icon to the right of it or something else?  When I click the folder/magnifying glass, it looks like the emulated view (missing stuff).

 

10 minutes ago, curtis-r said:

When you ask if I can mount the disk as Unassigned, do you mean clicking the folder/magnifying glass icon to the right of it or something else?  When I click the folder/magnifying glass, it looks like the emulated view (missing stuff).

Since the disk is disabled/emulated, any attempt to access it is using emulation to calculate its data from parity plus all other disks.

If you stop the array - unassign that disk - start the array, its contents will still be emulated but the disk itself will no longer be in the array.

Then you can see if that disk will mount in Unassigned Devices.

Ok, I stopped the array & unassigned the disk, & started array.  Disk shows under unassigned.  Does that folder/magnifying glass still reflect the parity or the actual disk?  The contents look the same as the parity (missing stuff).   Is that what you mean by mounting in Unassigned Devices?

OK, looking back at your Diagnostics, I see you don't have Unassigned Devices plugin installed. That is usually one of the first plugins people install after Community Applications so I assumed you were familiar with it. It allows you to access disks that are not in the array. How have you been using Unraid for over 10 years and not needed to access a disk outside the array?

 

Install Unassigned Devices plugin from Community Applications then you will have a Mount button for the Unassigned disk.

 

Possibly it will be unmountable but won't know until we try, and if it does need repairing maybe it will have better result than the emulated repair.

 

 

Ha, never needed Unassigned Devices plugin until now ;).  Anyhow, installed.  Clicked Mount for disk1, but nothing seems to happen.  There is a sublisting of that disk also with 'Mount" grayed-out.

Post new diagnostics.

3 minutes ago, curtis-r said:

Clicked Mount for disk1

Better if you don't refer to that disk that way when it isn't in the disk1 slot in the array. When it is Unassigned, you will be working with the sdX letter assignment. Or you can use the last 4 characters of the serial number to keep things straight.

Also, best if you don't try to use the server for anything while we try to get things stable again. You don't have any redundancy as noted.

Diagnostics attached.  Thanks.

tower-diagnostics-20210303-1510.zip

Mar  3 13:25:25 Tower kernel: XFS (sdi1): Filesystem has duplicate UUID 1486a2d3-69ff-4562-8535-d4e418a850c8 - can't mount

Click the settings icon (*) at upper right of Unassigned Devices and see if it will let you change the UUID at the bottom of that settings page.

There is no additional option in the UUID drop-down.  I clicked 'Change UUID' anyhow.

Try clicking the Mount button again and post new diagnostics.

Done.  Thanks for being patient with me.tower-diagnostics-20210303-1626.zip

Maybe have to repair filesystem before it will let you change UUID

 

 

How do I execute an uuidgen, if that's the suggestion?

Try this, if it doesn't work post the output:

 

xfs_admin -U generate /dev/sdX1

 

Replace X with correct letter for the unassigned device.

I think I'm too much of a newb because I'm unclear where to enter that code.  I tried through putty but it returned "fatal error -- couldn't initialize XFS library".  Is there another place to run this?  Sorry.