Since a certain time I have a problem with my NVME drives on my unraid server.

I have two disks: 1 m.2 pcie use as a cache and 1 U2 in passthrough for a VM

for some time now the U2 NVME has been disappearing from the system causing the loss of the VM, only solution to have the disk again ->restart

At restart drive id change nvme0n1 become nvme1n1 and nvme1n1 become nvme0n1. So the VM try to start on cache nvme drive.

During the last restart, the cache disk became "unmountable", therefore no more VMs, no more Docker.

I therefore started the array in maintenance mode and tried to perform a repair -> failure.

Since the cache disk is 'unmountable', it also starts to disappear.

Do you have any ideas?

root@NorthernLight:~# fdisk -l /dev/nvme0n1

Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors

Disk model: XPG GAMMIX S11 Pro

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: gpt

Disk identifier: 2266E47C-110D-48A5-AF14-500A2BBBCBB0

Device Start End Sectors Size Type

/dev/nvme0n1p1 2048 206847 204800 100M EFI System

/dev/nvme0n1p2 206848 239615 32768 16M Microsoft reserved

/dev/nvme0n1p3 239616 2000408575 2000168960 953.8G Microsoft basic data

northernlight-diagnostics-20260128-1520.zip

Thanks for helping me.

Is there any reason you left the microsoft partitions on the disk?

46 minutes ago, Ossito said:

/dev/nvme0n1p1 2048 206847 204800 100M EFI System

/dev/nvme0n1p2 206848 239615 32768 16M Microsoft reserved

/dev/nvme0n1p3 239616 2000408575 2000168960 953.8G Microsoft basic data

My guess at first glance is unraid is getting confused by the partition layout and doesn't know what to do. I would say it's best to remove these if you're not running Windows OS off of this disk anymore. Also does not appear to be an XFS partition?

Edited January 28Jan 28 by MowMdown

I don't know why the disk have windows partition.

i want recover data of all my docker and then replace the disk (it run until 5 years age and it used above 60%. the disk should be partitionned in XFS file system!

XPG_GAMMIX_S11_Pro_2K482LAAQGXT (nvme0n1) 512 2000409264 => data partition: nvme0n1p3 type: gpt start: 239616 size: 1000084480 code: 0xee (8) 
.
.
.
Jan 28 00:49:50 NorthernLight root: mount: /mnt/cache: wrong fs type, bad option, bad superblock on /dev/nvme0n1p3, missing codepage or helper program, or other error.
Jan 28 00:49:50 NorthernLight root:        dmesg(1) may have more information after failed mount system call.
Jan 28 00:49:50 NorthernLight kernel: XFS (nvme0n1p3): Invalid superblock magic number
Jan 28 00:49:50 NorthernLight emhttpd: shcmd (96): exit status: 32
Jan 28 00:49:50 NorthernLight emhttpd: shcmd (97): rmdir /mnt/cache
Jan 28 00:49:50 NorthernLight emhttpd: cache: mount error: wrong or no file system

So it looks like somehow when your VM tried to boot on the wrong disk if that's what happened, the partition table got altered if that's even possible? It looks as if the disk was re-partitioned if you never used this as a windows disk before.

Youre gonna have to wait for @JorgeB to see if he can suggest any ways to correct this.

Edited January 28Jan 28 by MowMdown

If the VM started with the wrong SD, it may have clobbered the original partitions.

If you sure it was ZFS you can see if it still finds the signature:

dd if=/dev/nvme0n1 bs=16M status=progress 2>/dev/null | hexdump -C | grep 'XFSB'

If it's there, that should show something after a couple of minutes; you can abort with CTRL + C

@JorgeB file system is XFS not ZFS

ZFS was not implemented when i create my unraid server 5-6 years ago

the result after one hour:

Ps array started in maintenance mode.

root@NorthernLight:~# dd if=/dev/nvme0n1 bs=16M status=progress 2>/dev/null | hexdump -C | grep 'XFSB'
29c790a0  7a 37 61 59 59 0a 32 4e  63 4b 51 4e 58 46 53 42  |z7aYY.2NcKQNXFSB|
1b19e62a0  b4 8b 68 58 46 53 42 ad  f9 8e 19 0c a3 95 03 e4  |..hXFSB.........|
2af5c4fd0  3d 00 58 46 53 42 00 62  63 61 63 68 65 00 5f 42  |=.XFSB.bcache._B|
335775a50  54 15 1d f5 97 98 0b 58  46 53 42 ca f9 55 38 12  |T......XFSB..U8.|
3f1125fa0  3d 00 58 46 53 42 00 62  63 61 63 68 65 00 5f 42  |=.XFSB.bcache._B|

Edited January 28Jan 28 by Ossito
add information

I'm afraid none of those looks like a good XFS signature; also, they are not at the beginning of the device where the main superblock is.

My suggestion would be to try something like UFS Explorer, the free trial should show if it can recover anything.