Array Data drive became unmountable: Unsupported partition layout

[kowbbwbj]

Hello,

 

I just updated from Version 6.9.0-beta35 to rc2. After rebooting, one array disk has gone, telling me it's unmountable because of an unsupported partition layout. The disk contains (contained) nearly all data and it should be xfs (unencrypted). Last successful partition check was yesterday - 1st sunday of a month. I read the partition table of all 3 array drives with fdisk, and there seems to be no partition on the failing drive, whereas the remaining parity and data drives have a Linux Filesystem partition. I tried going back to beta35, same error.

 

Array is stopped, no rebuild attempts.

 

My idea would be to manually mount all array drives and copy all readable data to a spare drive, then trying to rebuild the array. Is there a safe way to mount the drives one by one? 

 

Attached is the diagnostics.

 

 

Many thanks in advance,

Markus

 

 

 

unhutzel-diagnostics-20210104-1919.zip

[JorgeB]

Please post output of:

 

gdisk /dev/sdf

 

[kowbbwbj]

1 minute ago, JorgeB said:

Please post output of:

 

gdisk /dev/sdf

 

Hi JorgeB,

root@UnHUTZEL:~# gdisk /dev/sdf
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sdf: 7814037168 sectors, 3.6 TiB
Model: WDC WD40EZRZ-00G
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): E750EE82-162F-424E-8426-FE1BF70353C6
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 2048-sector boundaries
Total free space is 7814037101 sectors (3.6 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name

Command (? for help): q

 

 

 

[JorgeB]

Was expecting a corrupt GPT header, but just looks like the partition is missing, best bet then is to rebuild the disk and let Unraid re-create the partition.

 

This assumes parity is valid: Stop the array, unassign disk2, start array, check that emulated disk2 is mounting and contents look correct, if yes, and only if yes, re-assign it to rebuild.

[kowbbwbj]

15 minutes ago, JorgeB said:

Was expecting a corrupt GPT header, but just looks like the partition is missing, best bet then is to rebuild the disk and let Unraid re-create the partition.

 

This assumes parity is valid: Stop the array, unassign disk2, start array, check that emulated disk2 is mounting and contents look correct, if yes, and only if yes, re-assign it to rebuild.

Just to be sure: by "unassign disk2" you mean changing the disk2 to "no device" in the array settings, correct?  

[kowbbwbj]

40 minutes ago, kowbbwbj said:

Just to be sure: by "unassign disk2" you mean changing the disk2 to "no device" in the array settings, correct?  

Ok, I figured out a drive is unassigned by setting it to "no device" in the array manager...

 

Array is started, and data on the emulated drive looks very promising! I'll copy the most important files to a backup drive mounted via unassigned devices and will rebuild afterwards.

 

Panic is fading... Thank you so much!

[trurl]

41 minutes ago, kowbbwbj said:

I'll copy the most important files to a backup drive

Best to have a backup plan already in place instead of waiting until you have a problem to try to copy important files.

[kowbbwbj]

Lesson learned.