Hi!

This morning I noticed that I couldn't access a directory on my server via an SMB share. When checking the UI I had a disabled device as well as read errors on 4 disks (if I recall correctly). Since I lose access to folders every now and then, for no apparent reason, I just restarted the server, which normally helps. It didn't this time so I shut the server down to work on the problem this evening.

Since I've been starting, stopping, and rebooting quite a few times now I can't say for sure when the "Unmountable: wrong or no file system" error showed up for one of my disks, but it's there now. Just to be sure I've re-seated all SATA and power cables as well as my SATA-controllers without any luck. Swapping SATA cables with another disk makes no difference so I assume that the file system actually is corrupt. I'd really like to get that data back though, if possible.

To make matters worse, the disabled device is still disabled. My plan was to replace that tomorrow when a new disk shows up but since I only have one parity disk I guess the data on the disabled disk is also gone? I unassigned the disk for that slot before I noticed the "Unmountable: wrong or no file system" error, although I guess it wouldn't have mattered if I left the disabled disk in the array since it was disabled.

The unmountable disk is TOSHIBA_MG08ACA16TE_X4D0A01NFWTG. Not sure if it matters but the disabled disk is TOSHIBA_MG10ACA20TE_85K2A06GF4MJ .

I got a lot of information when checking the file system on the unmountable disk via the UI, and it prompts me to fix the problems found with file system. Before I do that I just want to double check if there's anything else I need to do specific to how Unraid uses XFS (if there is in fact anything particular about it).

Let me know if there's anything else you need to know or want me to do.

nas-safemode-diagnostics-20260218-2001.zip xfs_repair status.txt

6 hours ago, MartinNr5 said:

lose access to folders every now and then, for no apparent reason

Why didn't you ask for help before now?

6 hours ago, MartinNr5 said:

the disabled disk is TOSHIBA_MG10ACA20TE_85K2A06GF4MJ

has disconnected and is now an unassigned device. Disk8 is the disabled/emulated disk.

6 hours ago, MartinNr5 said:

unmountable disk is TOSHIBA_MG08ACA16TE_X4D0A01NFWTG

unmountable disk5, but you didn't mention that emulated disk8 is also unmountable.

SMART for both disks looks OK. Do any of your other disks show SMART warning (👎) on the DASHBOARD page?

@MartinNr5

Do you have another copy of anything important and irreplaceable? Parity is not a substitute for backup.

I assume your check filesystem was on disk5, since you didn't mention emulated disk8 was also unmountable. I've seen worse, but I've also seen better. Not much you can do except FIX it and hope not too much ends up in lost+found. But let's leave that for later.

There may be other options with disabled/emulated/unmountable disk8, since we can try to repair the emulated disk, and compare the results to the physical disk.

Check filesystem on emulated disk8 from the webUI and post the results.

Why didn't you ask for help before now?

Because it was a simple fix to just restart the server and I've had this issue on and off for quite a while, before I installed the currently unmountable disk, so I assumed it was related to cabling or controller, not Unraid. This is the first time in all my years of using Unraid that I encounter an unmountable disk.

but you didn't mention that emulated disk8 is also unmountable.

That's because I didn't notice it was unmountable. I only noticed it on 1NFWTG.

Do you have another copy of anything important and irreplaceable?

As far as I can tell everything valuable is backed up.

Do any of your other disks show SMART warning (👎) on the DASHBOARD page?

No, they're all fine.

Not much you can do except FIX it

When I try to fix 1NFWTG I get the following back:

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 the filesystem is a snapshot of a mounted filesystem, you may need to give mount the nouuid option. 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.

Since I've accidentally mounted and unmounted the disks before I noticed the unmountable disk I assume that nothing might be gained from doing so again but just in case I misunderstand the above message, I'd rather double check before I tell it to zero the log.

Check filesystem on emulated disk8 from the webUI and post the results.

I've attached the information from that check to this post.

Thanks for all the help so far.

xfs_repair status emulated disk 8.txt

22 minutes ago, MartinNr5 said:

When I try to fix 1NFWTG I get the following back

How are you doing that? From the webUI? Or from the command line? Several ways to get the command wrong. WebUI will get it right.

8 minutes ago, trurl said:

How are you doing that? From the webUI? Or from the command line? Several ways to get the command wrong. WebUI will get it right.

From the web UI.

15 hours ago, trurl said:

let's leave that for later.

Go ahead and fix emulated disk8

45 minutes ago, trurl said:

Go ahead and fix emulated disk8

As far as I can tell the file system was fixed. I've included the output from xfs_repair if it might be of interest.

xfs_repair status fixed emulated disk 8.txt

Just now, MartinNr5 said:

As far as I can tell the file system was fixed. I've included the output from xfs_repair if it might be of interest.

xfs_repair status fixed emulated disk 8.txt

Do you have a lost+found folder on the drive? That is where the repair process puts any files for which it could not find the directory entry to give them their original name. Not having that folder is a good sign😀

3 minutes ago, MartinNr5 said:

file system was fixed

Start the array in normal mode and post diagnostics.

5 minutes ago, itimpi said:

Do you have a lost+found folder on the drive?

No lost+found folder, at least not in the root of the disk. 🙂

4 minutes ago, trurl said:

Start the array in normal mode and post diagnostics

Attached.

nas-safemode-diagnostics-20260219-1938.zip

Check contents, but since there's no lost+found share, it should be fine.

Just now, JorgeB said:

Check contents, but since there's no lost+found share, it should be fine.

As far as I can tell, the contents are restored. There's a lot of folders and files but everything looks ok at a glance.

How does the unmountable disk 1NFWTG affect the contents? If I have one emulated disk and one unmountable with only 1 parity disk, it seems to me that I still need to repair 1NFWTG to get back all data.

5 minutes ago, MartinNr5 said:

How does the unmountable disk 1NFWTG affect the contents?

It doesn't really affect that, but you should also try and fix that filesystem.

Just now, JorgeB said:

It doesn't really affect that, but you should also try and fix that filesystem.

So I can still add a new disk to the array to replace the emulated disk and rebuild as usual, without fixing 1NFWTG?

What would the consequences be if I try and fix 1NFWTG and it fails?

2 minutes ago, MartinNr5 said:

So I can still add a new disk to the array to replace the emulated disk and rebuild as usual, without fixing 1NFWTG?

Yes, and if this was the old disk8:

Device Model: TOSHIBA MG10ACA20TE

Serial Number: 85K2A06GF4MJ

It looks healthy; most likely, it got disabled due to a power/connection issue, not a disk problem.

3 minutes ago, MartinNr5 said:

What would the consequences be if I try and fix 1NFWTG and it fails?

Nothing suggests disk5 has issues for now, it's just a filesystem problem, but if that disk, or any other disk, fails during the rebuild, the rebuild may not finish, or finish with errors.

Nothing suggests disk5 has issues for now, it's just a filesystem problem, but if that disk, or any other disk, fails during the rebuild, the rebuild may not finish, or finish with errors.

I'm obviously completely misunderstanding how Unraid works under the hood. I was under the impression that all drives in the array (physical or emulated) had to have a functioning XFS file system for the contents to be accessible but that's clearly not the case. 🙂

2 minutes ago, MartinNr5 said:

I was under the impression that all drives in the array (physical or emulated) had to have a functioning XFS file system for the contents to be accessible but that's clearly not the case.

XFS is not the only filesystem Unraid supports. But unless whatever filesystem is "mountable", meaning that the OS can load the filesystem, its folders and files aren't accessible. Some corruption prevents mounting, some corruption might not.

And, each array disk is an independent filesystem that can be mounted and read all by itself on any linux.

Just now, trurl said:

And, each array disk is an independent filesystem that can be mounted and read all by itself on any linux.

That is one of the benefits of the way Unraid implements parity on separate disks.

Just now, trurl said:

That is one of the benefits of the way Unraid implements parity on separate disks.

Another benefit is it allows different sized disks in the array.

Just now, trurl said:

XFS is not the only filesystem Unraid supports. But unless whatever filesystem is "mountable", meaning that the OS can load the filesystem, its folders and files aren't accessible. Some corruption prevents mounting, some corruption might not.

Ok, let me clarify. ☺️ Since I'm using XFS for my array, I assumed that a disk in the array had to have a healthy XFS file system for the contents on that disk to be available. But if I understand JorgeB correctly, all my data is back despite the array having one emulated disk and one unmountable disk.

I've always read that with 1 parity disk you can lose 1 data disk and be fine but if you lose 2 data disks, you're up the creek without a paddle.

Edited February 19Feb 19 by MartinNr5

And just to be sure that I don't screw myself over; should I start by replacing the emulated disk or should I start with fixing the file system on 1NFWTG?

5 minutes ago, MartinNr5 said:

all my data is back despite the array having one emulated disk and one unmountable disk.

All your data is not back. All the emulated data is back but won't actually be on any physical disk until the emulated data is rebuilt to a physical disk. The data from the remaing unmountable disk is not back at all since it is an independent (and currently unmountable) filesystem. It still needs to be repaired.

8 minutes ago, MartinNr5 said:

I've always read that with 1 parity disk you can lose 1 data disk and be fine but if you lose 2 data disks, you're up the creek without a paddle.

You didn't lose 2 data disks. Disabled/emulated/missing are completely different and independent conditions from unmountable. Parity doesn't know anything about filesystems, it is just a bunch of bits.

A disk can be disabled/emulated/missing/destroyed, and as long as parity plus all other disks can be reliably read, it can be rebuilt, regardless of the contents of those other disks. The parity calculation doesn't care about the contents, it is all just a bunch of bits.

A disk can be unmountable, and parity rebuild can't fix that.

A disk can be both disabled and unmountable. Each condition requires a different solution. We always try to repair unmountable before rebuilding onto the same disk.

But it doesn't really matter if you repair the unmountable (but not disabled) disk before rebuilding, or rebuild the repaired emulated disk before repairing the unmountable disk. They are independent.