Hi Team,

During the 7.2.3 to 7.2.4 upgrade, one of my cache pool NVMe devices had its partition table and all btrfs superblocks wiped. The pool is a 4x NVMe btrfs RAID1, so no data loss thanks to redundancy, but this shouldn't be happening during a routine OS upgrade.

The affected device is a Samsung 980 PRO 2TB (S6WRNJ0W927023H), devid 1 in the pool. After the upgrade reboot, btrfs shows it as missing:

Label: none uuid: 90a81836-6970-408b-9e30-178f1e83e873

Total devices 4 FS bytes used 466.30GiB

devid 2 size 1.82TiB used 487.03GiB path /dev/nvme2n1p1

devid 3 size 931.51GiB used 487.03GiB path /dev/nvme1n1p1

devid 4 size 931.51GiB used 487.03GiB path /dev/nvme0n1p1

*** Some devices missing

The device is physically fine - it's present, SMART is healthy, no errors in dmesg. What's happened is surgical: the GPT partition table has been zeroed, and all three btrfs superblock locations (64KiB, 64MiB, 256GiB) have been zeroed. The actual data regions on disk are still intact. This is exactly the pattern you'd see from sgdisk -Z followed by wipefs -af.

Which is interesting.... because strings in /usr/libexec/unraid/emhttpd show exactly those commands:

sgdisk -Z /dev/%s

/sbin/wipefs -af --lock /dev/%s

/sbin/blkdiscard /dev/%s

debug: %s: %d data disk: clear target, repartitioning

My best guess is that during the upgrade reboot, NVMe device enumeration changed (PCIe bus order isn't deterministic), and emhttpd's pool startup logic matched the wrong device to the wrong slot, then treated it as a new/blank device needing initialisation. The pool config in /boot/config/pools/cache.cfg has been unchanged across three diagnostic sets (Nov 2025, Dec 2025, Mar 2026) - the config is correct, so it's the runtime matching that went wrong.

Timeline:

- Pool healthy and clean before upgrade (verified in prior diagnostics)

- Upgrade initiated, array cleanly stopped, reboot

- Post-reboot: device wiped, pool running degraded

Second issue:

the UI is showing this device as green/healthy (DISK_OK, color="green-on") despite having no partitions, size of 0, and a pool running in degraded mode with a missing device. The device detail page does show "missing" in the btrfs info table, but the dashboard gives no indication anything is wrong. A degraded RAID1 pool should be screaming at you, not showing green.

Diagnostics from before and after the upgrade attached. The cache pool config is identical across all three - this isn't a config drift issue.

I can provide the hex dumps of the zeroed superblock regions if useful.

Cheers

niavasha

FYI @JorgeB

fallout-diagnostics-20260312-0748.zip

Unfortunately, the syslog rotated already. There's a lot of SSH spam, so can't see the array start. This is certainly not a general problem; it didn't happen to anyone else AFAIK, so possibly there was already some issue with the pool or its config that caused the issue with the most likely the reboot, not the upgrade itself.

Thanks @JorgeB - appreciate you taking a look.

Yeah, syslog is my fault - should have grabbed it before it rotated. Lesson learned. I do have three diagnostic zips though (Nov 2025, Dec 2025, and day of upgrade Mar 2026) and the pool config is identical across all three - pool was healthy and cleanly unmounted before the reboot.

I'd agree it's more likely the reboot than the upgrade itself. My best theory is NVMe enumeration changed across the reboot (PCIe bus order isn't deterministic) and emhttpd's pool startup logic mismatched a device, treating it as needing initialisation. The damage pattern fits - GPT zeroed, all three btrfs superblocks zeroed, data regions intact - which is exactly what sgdisk -Z + wipefs -af would do.

Separately, the UI was showing the pool green/healthy with a missing device - no dashboard indication it was degraded. That one might be worth a look regardless?

Happy to attach the diagnostic zips if useful?

9 hours ago, niavasha said:

That one might be worth a look regardless?

There's currently no pool monitoring in Unraid, you can use a script, but there will be in 7.3, so now maybe just wait a little more.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-700582

Roger that - great!

Any recommendation on how to restore the null'd volume - or should i just remove it, set the pool to three disks, and then grow it back to 4 ?

You can fix it like this:

With the array running type

btrfs dev remove missing /mnt/cache

Then stop the array and reimport the pool with just the 3 devices that are currently being used:

on main click on the first device for that pool and then "remove pool"

back on main, create a new pool with the same name and 3 slots

assign the 3 pool device, leave the filesystem set to auto

start the array to import the pool

Now stop the array again, add a slot to the pool and assign the 4th device, start the array, and that should do it.