Hi all,

I've gotten myself into a tricky situation and want to make sure I don't lose my data. My data is currently still intact via parity emulation, so I'd rather ask before touching anything.

Setup:

• Unraid 7.3.0

• Parity: Seagate 16TB (ST16000NM000H)

• Disk 1: Seagate IronWolf 12TB (ST12000VN0007) — failed

• Disk 2: Seagate IronWolf 12TB (ST12000VN0007) — healthy

• Array disks are encrypted ZFS (luks:zfs)

What happened:

1. Disk 1 developed massive errors. I unassigned it ("no device") and started the array in normal mode, so Disk 1 has been running emulated via parity. This worked fine — all data accessible.

2. My first replacement was a 14TB drive (ST14000NM001G). I assigned it to the Disk 1 slot and started the rebuild — but I aborted it shortly after because of a warranty issue with that drive, and returned it.

3. I got a new 12TB replacement (Seagate IronWolf Pro, ST12000NT001), expecting this to be fine since the original Disk 1 was a 12TB.

4. Now when I assign the new 12TB to the Disk 1 slot, the array won't start: mdState=ERROR:NEW_DISK_TOO_SMALL — "Replacement disk is too small."

The cause (I think): It looks like the aborted 14TB rebuild left the expected size for Disk 1 stored as the 14TB value. From mdcmd status:

diskSize.1=13672382412     <- expected (this is the 14TB drive's size)
rdevSize.1=11718885324     <- the new 12TB replacement
rdevId.1=ST12000NT001-3MD101_ZZ30DW1W
rdevStatus.1=DISK_DSBL_NEW
diskSize.2=11718885324     <- Disk 2, the healthy 12TB
rdevSize.2=11718885324
rdevId.2=ST12000VN0007-2GS116_ZJV5BD4Y
rdevStatus.2=DISK_OK

So the new 12TB (11,718,885,324 sectors) has the exact same sector count as Disk 2 and as the original failed Disk 1 — it's only "too small" relative to the 14TB size that got stored after the aborted rebuild.

What I've already tried / ruled out:

• I did NOT click Start during a "New Config" attempt — I realised it would wipe the emulated Disk 1 contents, restored my super.dat backup and rebooted. Back to the same emulated state.

• mdcmd set diskSize.1 11718885324 returns write error: Invalid argument (array not in the right state, I assume).

My question: How do I safely reset the expected size for Disk 1 back to the 12TB value (11,718,885,324) so I can rebuild onto the new 12TB drive — without losing the parity-emulated Disk 1 data? Is editing this via the GUI / a specific procedure the right way, or is there a safe mdcmd sequence with the array stopped?

I have a backup of super.dat (super.dat.bak).

Thanks in advance

kunas-diagnostics-20260601-1749.zip

If the rebuild started with the 14 TB disk, the filesystem was already expanded, so there's not an easy way to reduce it now. You can mount the new 12TB disk with UD, copy all the data from the emulated disk there, then do a new config with the 12 TB disk in use and resync parity.

Thanks for the suggestion. I dug deeper and you appear to be right that the filesystem was expanded, even though the rebuild only ran to ~20-30% before I aborted it.

Evidence from the Main tab: Disk 1 (currently "Not installed", emulated via parity) shows SIZE 13.8 TB, while my real Disk 2 (identical 12TB model) shows 11.9 TB. So the emulated Disk 1's ZFS pool seems to have been resized to the 14TB geometry during the aborted rebuild.

Good news: all my data is intact and readable via the emulation — /mnt/disk1 shows USED 5.93 TB, zfs list -r disk1 reports no errors, and du -sh /mnt/disk1/Media returns 5.4T. Nothing lost so far.

So I understand the path now is: copy the data off the emulated disk onto the new 12TB drive, then New Config with the 12TB as Disk 1 and resync parity. Since ZFS can't shrink, I get why the smaller disk is rejected.

My remaining questions before I start:

1. My array disks are encrypted ZFS (luks:zfs). When I mount the new 12TB via Unassigned Devices to copy the data onto it — does it matter how I format it there (e.g. ZFS encrypted vs plain), given that I'll be assigning it as an array disk afterwards anyway?

2. After copying, when I do New Config and assign the new 12TB as Disk 1: as long as I do not tick the Format checkbox, will Unraid read the existing data and just rebuild parity around it? Or does the array disk need a specific encrypted-ZFS layout that UD won't produce, meaning I'd have to let the array format it (and lose the copy)?

3. Is rsync from /mnt/disk1/ the right approach, or should I use zfs send | zfs receive to preserve the datasets (Media, isos, etc. are separate ZFS datasets)?

10 hours ago, madiz said:

does it matter how I format it there (e.g. ZFS encrypted vs plain), given that I'll be assigning it as an array disk afterwards anyway?

No, but it will keep the same one you choose.

10 hours ago, madiz said:

After copying, when I do New Config and assign the new 12TB as Disk 1: as long as I do not tick the Format checkbox, will Unraid read the existing data and just rebuild parity around it?

Yes, it will import the existing filesystem, as chosen above.

10 hours ago, madiz said:

Is rsync from /mnt/disk1/ the right approach, or should I use zfs send | zfs receive to preserve the datasets (Media, isos, etc. are separate ZFS datasets)?

Whatever you prefer, but if you want to presrver datasrts, zfs replication is the best option.

The zfs send/receive replication is done — all datasets copied successfully to the new disk's pool disk1new (5.39T, matches source). Two things before I do the New Config:

1. The replicated datasets inherited mountpoint=/mnt/disk1 from the source (via send -R). When I assign this disk as array Disk 1 and start without formatting, will Unraid import it cleanly, or do I need to fix the pool name / mountpoint first? I've seen forum cases of "Unmountable: unsupported or no file system" after New Config with replicated ZFS disks.

2. Should I delete the @migrate and old @backup_now snapshots on the new disk before the New Config, or leave them?

Just want to confirm the exact safe sequence for unraid7.3 before I commit. Thanks!

It should import it cleanly, and you can delete the snapshots after.

Update: After New Config + start, Disk 1 shows "Unmountable: wrong or no file system", while Disk 2 mounts fine. LUKS is open on both (cryptsetup status md1p1 = active, LUKS2).

Note: I was not prompted for my encryption passphrase at array start — I assume because there was no reboot and the key was still in the keyring from before.

zpool list shows:

disk1new  10.9T  5.39T alloc  ONLINE   (my replicated data, intact)
disk2     10.9T  1.95T alloc  ONLINE   (mounts fine in array)

The replicated pool is still named disk1new (the name I gave it in UD), while the working Disk 2's pool is named disk2. Could the pool name be why Disk 1 won't mount as the array disk — and if so, what's the safe way to fix it (rename/export/import)? Or is something else causing the "unmountable" state? Parity-Sync is running (~5%). Data on disk1new is intact and I want to avoid risking it.

Important detail: despite the "unmountable" status, my data IS accessible — the pool disk1new is actually mounted at /mnt/disk1 (inherited mountpoint), ls /mnt/disk1/Media shows all my folders, and Jellyfin plays the media fine. So ZFS has the pool mounted, but Unraid's array layer reports Disk 1 as unmountable (pool named disk1new, not matching the array). Parity-Sync is running over /dev/md1p1 right now.

My concern: is the parity being built consistently given this name/mount mismatch? Should I cancel the sync now, and what's the safe sequence to rename disk1new→disk1 so the array layer mounts it properly? Data is intact, want to keep it that way.

---
Follow-up on my own reasoning: I initially thought the inherited ZFS mountpoints might be the cause, but that can't be it — Disk 2 has the exact same inherited mountpoints (its datasets also mount under /mnt/disk2) and it mounts perfectly. The only difference between the two is the pool name: Disk 2's pool is named disk2 (matches its slot), Disk 1's cloned pool is named disk1new (doesn't match the expected disk1).

So my working theory is that Unraid maps a ZFS array disk by pool name = slot name (disk1, disk2, ...), and that's why Disk 1 won't mount while the data is otherwise perfectly accessible via ZFS.

Could you confirm whether that's correct (or whether Unraid identifies the disk by pool GUID instead)? And if renaming is the fix, what's the safe sequence — export disk1new and re-import as disk1? The pool is currently mounted at /mnt/disk1 and a parity sync is running over /dev/md1p1, so I'm unsure whether to cancel the sync first. Want to avoid leaving the pool in a half-state. Thanks!

Another observation: the disk ZZ30DW1W still appears under "Historical Unassigned Devices" in the UD plugin (since was mounted via UD for the data copying). Could this leftover UD claim be preventing the array layer from adopting the pool on md1p1? Should I remove it from UD history as part of the fix, or leave it alone?

Edited June 3Jun 3 by madiz
Additional observations and marks

Post the diagnostics after array start.

Here you go. Thanks

kunas-diagnostics-20260603-1458.zip

The UUID doesn't match the pool, how did you format that disk?

Also post the output from

zpool import (withthe array started)

zpool import returns "no pools available to import" (with the array started — the pool is already active as disk1new, mounted at /mnt/disk1).

How I formatted it: I assigned the disk in Unassigned Devices and used the GUI "Format" button, chose ZFS encrypted, gave it the pool name disk1new, and that was it. Then I did the zfs send/receive replication onto it, and afterwards assigned it to the array Disk 1 slot via New Config.

Should I export the pool and re-import it under the correct name to fix the UUID mismatch, or is there a different safe procedure? Data on disk1new is intact and I'd like to preserve it.

1 hour ago, madiz said:

the pool is already active as disk1new, mounted at /mnt/disk1).

Did you import it before or after the array started? If it was mounted, Unraid cannot import it, and it will show unmountable.

Timeline to be precise: after the zfs send/receive finished, I ran zfs list -r disk1new (all datasets present, 5.39T). Then I stopped the array - at that point the GUI only offered "Mount" for the disk, not "Unmount", so the array stop had already released the UD mount automatically. Then I did New Config (array stopped, so the pool was not mounted), assigned the disk to Disk 1, and started the array -> unmountable.

So at New Config / array start the pool wasn't UD-mounted. Given the UUID mismatch you saw in the diagnostics, what's the actual cause and the safe way to fix it without losing the data on the pool?

You are using encryption, which makes things more complicated, but stop the array; if disk1 was imported, manually export it with zpol export

Start the array, when disk1 is showing unmountable, and post the output from zpool import -d /dev/mapper/md1p1

That fixed it! After zpool export disk1new + array start, Unraid imported the pool correctly as disk1, Disk 1 now mounts fine showing all my data (5.37T), and parity sync is running. The pool being active as a separate disk1new was blocking the array import. Thank you so much!