madiz

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!

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?

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.

Here you go. Thanks kunas-diagnostics-20260603-1458.zip

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?

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: 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. 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!

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: 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? 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)? 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)?

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: 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. 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. I got a new 12TB replacement (Seagate IronWolf Pro, ST12000NT001), expecting this to be fine since the original Disk 1 was a 12TB. 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

erstmal Danke für diese super Anleitung. Wieso genau ist da geschrieben, dass diese veraltet sei? Funktioniert doch nach wie vor alles perfekt. Der Lancache funktioniert ja soweit, was mich aber jetzt etwas wundert... ich habe eine 1 gbit Internetleitung die "meistens" auch auf nem guten Speed funktioniert (800Mbit - 1Gbit). Nun ist mein Server über 2,5Gbit mit meinem Rechner verbunden, aber beim "Download" aus dem LanCache erhalte ich max. 1,2 Gbit. Ist natürlich noch mal 20% - 30% schneller als direkt ausm Netz, aber ich hätte da dann doch schon gerechnet das ich da mehr rausbekomme. Wenn ich die Daten normal über smb ziehe komme ich auf ca 200-250 MB/s. Hab ich da irgendwo nen fehler? Muss ich den Cache erhöhen wenn ich den container erstelle?