Hi all,

I seem to have worked myself into a "no pool uuid" state on a BTRFS RAID1 cache pool after a multi-step pool reconfiguration.

The BTRFS filesystem is provably intact (manual CLI mount succeeds, all data accessible), but Unraid refuses to mount it via the GUI. Looking for the correct procedure to repopulate diskUUID in cache_ssd.cfg and bring the pool back online without data loss.

Diagnostics attached.

I have used AI to try to help understand the docs and diagnose, and also put together parts of this post (the commands I have already run to diagnose), but I don't trust it and thought I'd come to the experts as I think some serious decision needs to be made.

System

• Unraid version: 7.2.2

• Array: 6 data disks + 1 parity, XFS, unchanged throughout this

• Cache pool name: cache_ssd (BTRFS RAID1)

Original pool topology

4-device BTRFS RAID1 with some very old drives in it. I wanted to remove them as it was a stupid set up, held over from old drives in the machine:

• Cache_ssd: Samsung 750 EVO 250GB (S33SNWAH490059A)

• Cache_ssd 2: Samsung 870 EVO 1TB (S75CNL0Y516212P) ← original mirror member, holds full RAID1 copy

• Cache_ssd 3: Samsung NVMe 128GB (S347NY0HB08290)

• Cache_ssd 4: Crucial MX500 1TB (CT1000MX500SSD1_1843E1D35674) ← failing, SMART showing 1% endurance remaining

SSD4 failing was a good time to address this. Or so I thought... I wanted a 2-device BTRFS RAID1 of two matched 870 EVO 1TBs.

What I did (likely where I went wrong)

1. Scrub passed clean, no errors.

2. Removed MX500 via CLI (online, while array running):

   btrfs device remove /dev/sdj1 /mnt/cache_ssd

Completed cleanly. 4-device → 3-device pool. 3. Removed 128GB NVMe via CLI (online):

   btrfs device remove /dev/nvme0n1p1 /mnt/cache_ssd

Completed cleanly. 3-device → 2-device pool. 4. Physical swap: stopped array, shut down, physically replaced MX500 with new Samsung 870 EVO 1TB (S8NBNJ0L300085L). Left 750 EVO and NVMe physically in place. 5. Started array, assigned new 870 EVO to Cache_ssd 4 slot in the GUI. Pool came up as 4-device (Unraid still considered all 4 slots active), Unraid auto-triggered a balance. 6. Removed 750 EVO via CLI (online):

   btrfs device remove /dev/sdc1 /mnt/cache_ssd

Completed cleanly. BTRFS now: 2-device RAID1 of the two 870 EVOs, perfectly balanced (291 GiB allocated on each, identical mirror).

At this point:

BTRFS layer was 2-device pool, both 870 EVOs, healthy.

Unraid GUI = still configured for 4 slots, with 2 marked "Missing" (750 EVO and NVMe) and Cache_ssd 4 marked "Wrong" (new 870 EVO in slot expecting MX500's serial).

This was done on Tuesday but I only noticed today, when my Common Problems Plugin fired and told me.

Attempt to reconcile Unraid config

I followed the docs' "Make Unraid forget the deleted member" CLI procedure:

1. Stopped array, unassigned all 4 pool slots to "no device". Tried to Start array → hit "Wrong Pool State - cache_ssd - too many wrong or missing devices", couldn't proceed.

2. Reassigned the two 870 EVOs to Cache_ssd 2 and Cache_ssd 4 slots, ran Tools → New Config with "Preserve All" current assignments. Backed up super.dat manually before doing this and New Config completed.

3. Array showed "Parity is already valid" option, started array with that ticked (parity check log shows last clean check was May 2, no array drives changed since). Array started successfully, parity not rebuilt.

4. The issue now is that cache pool showed as "Unmountable: wrong or no file system"

5. I stopped the array again and checked and, navigated to Cache_ssd pool settings, changed File system type from "auto" to "btrfs", left Allocation profile as "raid1". Applied.

6. Started array again. Cache pool still shows "Unmountable: wrong or no file system" in the GUI.

Current diagnostic state

syslog mount attempt:

emhttpd: mounting /mnt/cache_ssd
emhttpd: shcmd (3693): mkdir -m 0666 -p /mnt/cache_ssd
emhttpd: cache_ssd: no pool uuid
emhttpd: shcmd (3694): rmdir /mnt/cache_ssd
emhttpd: cache_ssd: mount error: wrong or no file system

BTRFS state (with array stopped or started, doesn't matter):

# btrfs filesystem show
Label: none  uuid: ca0fc1e8-85fc-4f51-ab2b-0f3b7f922590
        Total devices 2 FS bytes used 279.18GiB
        devid    3 size 931.51GiB used 293.03GiB path /dev/sdd1
        devid    5 size 931.51GiB used 293.03GiB path /dev/sde1

Manual CLI mount works perfectly:

# mount -t btrfs /dev/sdd1 /tmp/btrfs-test
# ls /tmp/btrfs-test/
Documents/  EBooks/  Media/    duplicacy_cache/  nextcloud_data/
Downloads/  Games/   appdata/  isos/             system/
# df -h /tmp/btrfs-test
/dev/sdd1       932G  280G  652G  31% /tmp/btrfs-test

All data is present and accessible.

btrfs check --readonly (minor inconsistency, not data corruption):

[1/8] checking log skipped (none written)
[2/8] checking root items
[3/8] checking extents
[4/8] checking free space tree
We have a space info key for a block group that doesn't exist
[5/8] checking fs roots
[6/8] checking only csums items (without verifying data)
[7/8] checking root refs
[8/8] checking quota groups skipped (not enabled on this FS)
UUID: ca0fc1e8-85fc-4f51-ab2b-0f3b7f922590
found 299762716672 bytes used, error(s) found

Cache pool config (/boot/config/pools/cache_ssd.cfg) — diskUUID is empty:

diskFsType="btrfs"
diskUUID=""
diskFsProfile="raid1"
diskId="Samsung_SSD_870_EVO_1TB_S75CNL0Y516212P"
diskId.1="Samsung_SSD_870_EVO_1TB_S8NBNJ0L300085L"
diskIdSlot="-"
diskIdSlot.1="-"
diskSize="0"
diskSize.1="0"

The empty diskUUID="" field appears to be the direct cause of emhttpd: cache_ssd: no pool uuid.

What I think needs to happen (or at least what AI thinks!)

Unraid needs to be coaxed into populating diskUUID with the actual BTRFS pool UUID (ca0fc1e8-85fc-4f51-ab2b-0f3b7f922590), and ideally also re-record per-device metadata (diskSize is also empty for both members).

I've seen forum threads where JorgeB has solved this with the unassign-all-pool-members-then-start-then-reassign cycle, but I haven't tried that procedure yet because:

• Earlier today, when I tried unassigning all slots, I hit "Wrong Pool State - too many wrong or missing devices" and couldn't Start. State is different now post-New-Config, but I'd rather verify the procedure before attempting it.

• I want to make sure I don't accidentally trigger a format on the pool members — both drives hold the only copies of the RAID1 mirrored data right now.

Next Steps

I would be very grateful if the community could help.

1. Is the unassign-all → start → reassign sequence the right procedure for my current state? If so, are there any specific things to look for (or avoid) given my history?

2. Is there a safer alternative? For instance, directly editing /boot/config/pools/cache_ssd.cfg to add the diskUUID? Or some other operation that I'm missing?

3. The minor btrfs check error ("space info key for a block group that doesn't exist") — is that something to address before the reconfiguration, or after, or ignore?

I definitely won't:

• Click "Format" in the GUI (offered next to the Unmountable pool)

• Click "Erase Pool" or "Remove Pool" in pool settings

• Run any btrfs check --repair operation

Backups etc in place

• Manual super.dat backup: /boot/config/super.dat.before-new-config-2026-05-31

• Automatic super.old from New Config

• Pre-Cache-pool-rebuild snapshot of pool state: /boot/config/pre-swap-pool-state.txt

• The 750 EVO and NVMe are still physically present in the system (now Unassigned) — historical state recoverable if needed

Thank you to anyone who can help. I have reached the stage where I couldn't work out from the docs and am paranoid. I don't trust the AI's randomly guessing commands approach, although it helped me understand the docs and do some diagnosis!

Happy to provide additional diagnostics or run any commands needed.

handaniserver-diagnostics-20260531-1047.zip

Unmount the pool if it's still mounted manually, then 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 2 slots

assign the pool devices, leave the filesystem set to auto

start the array and post new diags

Thank you for the quick reply.

I followed exact instructions, pool unmounted, "Remove Pool" clicked from settings page of cache_ssd, recreated pool with same name "cache_ssd" and 2 slots, assigned both 870 EVOs, filesystem left at "auto", started array.

Pool now shows "Unmountable: unsupported or no file system". diskUUID is still empty in cache_ssd.cfg.
New diags attached.

handaniserver-diagnostics-20260531-1256.zip

There's an unsigned device confusing the pool:

bad superblock on /dev/sdc1

Disconnect or completely wipe this device, then try again.

Thanks.

The two devices are a mirrored pool. Is this possible to do and still save the data?

I’m not physically with the machine but will try this evening to disconnect and test that.

I really appreciate your knowledge and help! Thank you. It is reassuring.

1 hour ago, serhan said:

The two devices are a mirrored pool. Is this possible to do and still save the data?

The pool should be fine, problem is that other device, which is not part of the pool, probably it was before and was not correctly removed, if you remove or wipe that device, the pool should then mount

Thanks, I will try and report back.

Thank you JorgeB, it worked.

I misunderstood on your first comment and thought the issue was with one of the two pool drives I want. But I see it was one of the ones I removed.

I elected to just remove them and I boot fine! Wiping the superblocks via wipefs/btrfs inspect-internal hadn't found anything to clear, but the physical disconnect was apparently what Unraid needed.

Many thanks for the diagnosis and patience, you are a godsend.