Hey there,

today I finally switched my Unraid 7.3.2 from usb boot to internal boot on a brand new, additional nvme drive.

I used the Internal boot Wizard to do the switch and selected "boot + data partition" option, so I can use the rest of the nvme as cache drive.

Internal boot is working, but the data partition is "unmountable: wrong or no filesystem".

What I've done:

• rebooted the system

• the data partition was set to "filesystem: auto" after the Internal Boot wizard had finished, so I manually switched it to "zfs" - same error

• then clicked "erase pool", hoping that this would renew and format the new data partition, but the error still persists

• switched the data partition filesystem setting back to "auto".

What else could I do to get the data partition to work?

You need to click format to create the filesystem for the data partition; the default "auto" will format it as Btrfs. You can change it before that.

thanks for your reply! I did miss the "format" button down there, but formatting didn't fix the issue, the data partition remains "unmountable: wrong or no filesystem".
Interestingly, the ZFS pool itself is ONLINE, mounted, writable and in active use.

here's claude's analysis of the issue:

## Setup

- Unraid 7.3.2

- Internal boot device: /dev/nvme1n1 (Kingston 1 TB), configured as Boot + Data

- Pool name for the data partition: cacheappdatavms (ZFS, single device)

- Partition layout: p1 BIOS boot, p2 EFI, p3 "Unraid Boot Partition"

(zfs_member, label "flash"), p4 data partition (/dev/nvme1n1p4)

## What I did

1. Migrated from USB boot to internal boot, data partition enabled.

2. Pool showed "Unmountable: wrong or no file system", no Format button at first.

3. Later found the Format button, formatted. Pool is now created, but GUI still shows the same error.

4. Stopped and restarted the array. Error persists.

## What works

- zpool status -P cacheappdatavms: ONLINE, device /dev/nvme1n1p4, 0 errors

- zfs list: mountpoint /mnt/cacheappdatavms, mounted=yes, canmount=on

- touch/write on /mnt/cacheappdatavms works

- /boot/config/pools/cacheappdatavms.cfg has diskFsType="zfs", the correct

disk ID, and diskUUID matches zpool get guid cacheappdatavms

- folder "appdata" exists on the new partition and contains data from currently running docker containers

## What is odd

On the data partition, userspace tools cannot see the ZFS labels:

- blkid /dev/nvme1n1p4 -> only PARTUUID, no TYPE=

- lsblk -f -> empty FSTYPE and LABEL for nvme1n1p4

- zdb -l /dev/nvme1n1p4 -> "failed to unpack label 0/1/2/3"

- zdb -l /dev/disk/by-partuuid/<partuuid> -> same result

For comparison, on my other (older) ZFS pool, lsblk -f shows zfs_member with the label and zdb -l /dev/sdg1 reads all labels fine.

So this is specific to the data partition created via the GUI Format.

Claude's assumption (not verified): the GUI detects the file system via blkid-style userspace tools, which find no signature, and therefore reports

"wrong or no file system", while the kernel ZFS module has the pool imported and working.

## Questions
1. Is this a known issue with Format on the data partition of an internal boot device in 7.3.2?

2. Is there a supported way to fix it without recreating the pool?

Diagnostics attached. Screenshots attached (GUI error, lsblk -f).

Adding output of blkid, zdb -l and zfs status, comparison of new internal boot drive (cacheappdatavms) and old drive (cache_appdata_vms).

=== blkid (neue Data-Partition) ===
/dev/nvme1n1p4: PARTUUID="36872156-b01a-41f1-9c53-f87b9504867e"

=== zdb -l (neue Data-Partition, Device-Pfad) ===
failed to unpack label 0
failed to unpack label 1
failed to unpack label 2
failed to unpack label 3

=== zdb -l (neue Data-Partition, by-partuuid) ===
failed to unpack label 0
failed to unpack label 1
failed to unpack label 2
failed to unpack label 3

=== zpool status ===
  pool: cacheappdatavms
 state: ONLINE
config:

        NAME              STATE     READ WRITE CKSUM
        cacheappdatavms   ONLINE       0     0     0
          /dev/nvme1n1p4  ONLINE       0     0     0

errors: No known data errors

=== zpool guid ===
NAME             PROPERTY  VALUE                SOURCE
cacheappdatavms  guid      4494314595299527425  -

=== zfs list ===
NAME             MOUNTPOINT            MOUNTED  CANMOUNT
cacheappdatavms  /mnt/cacheappdatavms  yes      on

=== pool .cfg (Seriennummer geschwärzt) ===
diskFsType="zfs"
diskUUID="4494314595299527425"
diskAutotrim="on"
diskCompression="on"
diskWarning=""
diskCritical=""
diskExpansion=""
diskShareEnabled="yes"
diskShareFloor="52400000"
diskBootSize="16384"
diskComment=""
diskExport="-"
diskFruit="no"
diskSecurity="public"
diskReadList=""
diskWriteList=""
diskVolsizelimit=""
diskCaseSensitive="auto"
diskExportNFS="-"
diskExportNFSFsid="0"
diskSecurityNFS="public"
diskHostListNFS=""
diskSpindownDelay="-1"
diskSpinupGroup=""
diskFsProfile=""
diskFsWidth="1"
diskFsGroups="1"
diskId="<REDACTED>"
diskIdSlot="-"
diskSize="959985348"

=== Vergleich: alter Pool, blkid + zdb -l ===
/dev/sdg1: LABEL="cache_appdata_vms" UUID="13510623164928815722" UUID_SUB="7650696493048011050" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="476c4596-01"
------------------------------------
LABEL 0 
------------------------------------
    version: 5000
    name: 'cache_appdata_vms'
    state: 0
    txg: 10698597
    pool_guid: 13510623164928815722
    errata: 0
    min_alloc: 4096
    max_alloc: 4096
    hostname: 'Tower'
    top_guid: 7650696493048011050
    guid: 7650696493048011050
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 7650696493048011050
        path: '/dev/sdg1'
        whole_disk: 0
        metaslab_array: 132
        metaslab_shift: 32
        ashift: 12
        asize: 500102070272
        min_alloc: 4096
        is_log: 0
        DTL: 118918
        create_txg: 4
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data
        com.klarasystems:vdev_zaps_v2
    labels = 0 1 2 3 

tower-diagnostics-20261009-1331.zip

Edited Friday at 11:56 AM2 days by chrismuc

Thanks for the diagnostics. The pool is fine, but Unraid isn't managing it. The syslog doesn't show Unraid formatting that partition at any point in the current boot: at the first array start the partition was still empty, and no format or pool creation from the GUI is logged after that. So it looks like the pool was created some other way, e.g., from the command line. Because Unraid never imported it, it doesn't export it when the array stops. On array start it doesn't detect the filesystem, so it shows it as unmountable, and then a generic zfs mount -a mounts it anyway. That's why it works but the GUI shows the error.

Please don't click Format or Erase on that pool again, since it now holds your appdata. Make a backup of anything important on it first, then try this:

1. Post the output of zpool history cacheappdatavms | head -5. This shows how the pool was created.

2. Stop the array. Docker and VMs will stop.

3. Run zpool export cacheappdatavms

4. Run blkid /dev/nvme1n1p4. It should now show TYPE="zfs_member".

5. If it does, start the array. Unraid should import and mount the pool normally.

If step 4 still shows no TYPE, don't start the array yet. Post the output and new diagnostics

hey, thanks for your support!
this is the zpool history (just to make that clear, I did not manually create the zpool, all was done via the Unraid GUI):

root@Tower:~# zpool history cacheappdatavms | head -5
History for 'cacheappdatavms':
2026-10-09.12:54:48 zfs create cacheappdatavms/appdata
2026-10-09.12:54:49 zpool create -f -o ashift=12 -O dnodesize=auto -O acltype=posixacl -O xattr=sa -O utf8only=on -m /mnt/cacheappdatavms cacheappdatavms /dev/nvme1n1p4
2026-10-09.12:54:51 zfs program -jn -m 20971520 cacheappdatavms /usr/local/emhttp/plugins/zfs.master/scripts/zfs_pool_get_datasets_snapshots.lua cacheappdatavms 
2026-10-09.12:55:07 zfs program -jn -m 20971520 cacheappdatavms /usr/local/emhttp/plugins/zfs.master/scripts/zfs_pool_get_datasets_snapshots.lua cacheappdatavms 

after zfs export, blkid looks good:

root@Tower:~# zpool export cacheappdatavms
root@Tower:~# blkid /dev/nvme1n1p4
/dev/nvme1n1p4: LABEL="cacheappdatavms" UUID="4494314595299527425" UUID_SUB="4917460552146201760" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="36872156-b01a-41f1-9c53-f87b9504867e"

after array start, the partition is now mounted - thank you very much for your help!

Let me know if I can provide any additional information that might help to permanently avoid this issue for other users that are migrating to internal boot!

Thanks for the follow-up, and glad it's working now.

I need to correct what I said before: you're right, the pool was created by the GUI Format. The zpool history shows the exact command Unraid uses to format a ZFS pool. I missed it because the syslog in your diagnostics stops at 12:42 and only picks up again around 13:10, and the format happened at 12:54. Sorry for the confusion.

So the pool was formatted fine, but afterwards Unraid didn't detect the new filesystem on the data partition. That's why it showed as unmountable and wasn't exported when the array stopped, even though ZFS was using it. Exporting it cleared that, and on the next array start Unraid imported it normally.

I'll try to reproduce this with a boot + data partition and report it so it can be fixed for other users, but it's not a common issue, so it could be some corner case. If you get a chance, please confirm that after your next reboot the pool still mounts normally and Main shows its size and usage. If it shows unmountable again, don't format it. Post new diagnostics instead.