I'd love some help,I've gone through the documentation on the matter but it hasn't addressed my case;

This morning one of the disks was suddenly emulated. I suspect a temporary power issue, I could see in the logs the HBA considered it unresponsive and disconnected it before assigning it a new ID. After a reboot I can confirm the SMART values of the disk are fine, including 0 reallocated sectors. My array is xfs-encrypted and the drives are connected to a 9500-16i with a SATA breakout cable.

In maintenance mode I checked the filesystem of the drive and got "No file system corruption detected." so the GUI won't suggest any fixes yet with the drive still assigned to it's slot it remains emulated. No option appeared to change the flags on the command.

I then tried doing it in the command lin with xfs_repair -v /dev/md2p1

but only got these errors:

/dev/md2p1: No such file or directory

/dev/md2p1: No such file or directory

fatal error -- couldn't initialize XFS library

Before I do anything more I'd really appreciate some experienced input. I have a spare drive on hand but from what I understand the issue with the drive is present in parity data so just replacing the drive with a new one is not the path forward.

7 minutes ago, serverfan said:

/dev/md2p1: No such file or directory

/dev/md2p1: No such file or directory

Those are incorrect for encrypted disks. Better if you don't try to do this from the command line anyway. Other ways to get the command wrong but webUI will use the correct command.

And it seems likely that you don't have any unmountable disks so you are looking at the wrong documentation. Disabled and unmountable are different independent conditions with different solutions.

The word "mount" means the OS loads the filesystem to allow the files and folders to be accessed. A disabled disk is emulated, and the emulated disk is often mountable, so its contents can be read and written. That is what parity is all about. The drive can be completely missing or even destroyed and its contents can be recovered.

Attach Diagnostics ZIP to your NEXT post in this thread.

dobby-diagnostics-20260320-1406.zip

Hi trurl,

Thanks for chiming in, here are my Diagnostics.

If no filesystem corruption is found on the emulated disk, you should be ready to rebuild, but if you haven't yet, start the array once in normal mode with the disk unassigned and confirm the emulated disk is mounting and contents look correct before rebuilding on top.

We can't tell anything about your filesystems without the array started in normal mode.

9 minutes ago, JorgeB said:

start the array once in normal mode with the disk unassigned

And then post new diagnostics

dobby-diagnostics-20260321-1059.zip

I did just that, here are the new diagnostics. Can you tell me how you'll evaluate the condition of the filesystem from this? I'm familiar with "filesystem check" on a single drive but that requires the array to be in maintenance mode.

Emulated disk2 is mounted and showing data, as you should be able to see in MAIN - Array Devices. And you can examine the contents if you want.

Thanks guys, the disk contents looked fine based on the few files I opened, the emulated disk also tested fine in Maintenance mode so I started the disk rebuild.