Looking for assistance in recovering two of my data disks (all disks are xfs-encrypted) that have suddenly become "unmountable".  I was moving a bunch of small files to the array in Krusader that caused the user mount to go away.  I had seen this issue before, as this is a new server setup and I've been mass transferring files, so I made sure everything was stopped and restarted the machine.  After entering the decryption key and starting the array, two array disks with content are showing as unmountable and persists through subsequent restarts.

 

From looking at the diagnostics (attached), it appears it's related to:

 

PGVault emhttpd: error: ckmbr, 2263: No such file or directory (2): open: /dev/sdj1
...
PGVault emhttpd: error: ckmbr, 2263: No such file or directory (2): open: /dev/sdx1

 

Now into my speculations:

Somehow it appears these disks have lost their partition table?  This is my 1st time dealing with issues on encrypted disks, but I've had to conduct a similar rescue in the past.  Is it as simple as re-applying the partition table and viola, the data is accessible again?  If so, anyone have a good reference for doing so?  It's been awhile and I've got multiples of the same disk type to reference partition layout of.

 

Unraid v6.9.2

 

Spoiler

Unfortunately this was the last batch of information to move to the array before adding my parity disks (needed the raw write speed so I didn't spend 6 months transferring 205TB), so recovery via parity calculations isn't an option.

 

pgvault-diagnostics-20211116-1927.zip

Edited November 17, 20214 yr by Phuriousgeorge
Unraid version

Post the output of:

fdisk -l /dev/sdX

for both disks.

root@PGVault:~# fdisk -l /dev/sdx
Disk /dev/sdx: 9.1 TiB, 10000831348736 bytes, 19532873728 sectors
Disk model: WDC WD100EMAZ-00
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 8881A93C-7815-4B51-BB9C-B79A125EB4A8

 

I didn't include the other disk because it consisted of easily-replaceable "Linux ISOs", so I've been experimenting with its headers...and failing.

So it's not partition corruption, it's completely missing, easiest way is to rebuild the disk(s), assuming parity is still valid, partition information is outside parity, and Unraid will recreate the partitions, you can easily test by unassigning one of the disks and start the array, if the emulated disk mounts correctly rebuild on top, then repeat for the other one.

I have no parity in this system at the moment.

Then can't really help, redoing the partition table is something I never done and have no experience with.