I replaced a failing drive in a 5-disk raidz1 pool using the command line while the array was running:

zpool replace storage_one sdd1 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F0GR77

The resilver completed successfully (2.00T in 09:54:11, 0 errors), and a previously stuck raidz expansion finally finished. I then stopped the array, powered down, physically removed the old drive, and rebooted.

Now the UI marks Device 3 as "Wrong" and warns: "All existing data on this device will be OVERWRITTEN when array is Started". I have not started the array.

The pool itself is healthy. zpool import -d /dev storage_one works and shows:

NAME         STATE     READ WRITE CKSUM
storage_one  ONLINE       0     0     0
  raidz1-0   ONLINE       0     0     0
    sdb1     ONLINE       0     0     0
    sde1     ONLINE       0     0     0
    sdd      ONLINE       0     0     0
    sdc1     ONLINE       0     0     0
    sdh1     ONLINE       0     0     0
errors: No known data errors

The issue appears to be that the new member is the whole disk (sdd) rather than a partition (sdd1) like the other four members, because I passed the by-id path instead of a partition.

Unraid 7, pool has 7.4T of data, scrub currently at 78% with 0B repaired. My services are down and I need to bring them back up.

What is the correct way to make Unraid recognise this pool member? Is there a way to fix the partition mismatch without a second 10-hour resilver?

tower-diagnostics-20260831-0909.zip

Unraid doesn't support using whole disks; why didn't you use the GUI to replace it? If you like to use the CLI, you still can, but use a partitioned disk as the new one.

19 minutes ago, JorgeB said:

Unraid doesn't support using whole disks; why didn't you use the GUI to replace it? If you like to use the CLI, you still can, but use a partitioned disk as the new one.

You're right, and that was my mistake. I should have used the GUI. I went with zpool replace on the command line because I wanted to use a stable by-id path rather than /dev/sdX, but I passed the whole disk instead of a partition — which is what broke the UI's view of the pool.

For anyone landing here later, here's what happened and how it was resolved without a resilver.

The pool was always healthy. zpool import showed it ONLINE with all five members throughout. The issue was entirely in /boot/config/pools/storage_one.cfg.

For the four members Unraid recognised:

diskId.N="<identifier>"
diskIdSlot.N="-"

For the CLI-replaced drive, the two fields were swapped:

diskId.2=""
diskIdSlot.2="ST3000DM001-9YN166_Z1F0GR77"

With no member declared in diskId.2, Unraid treated the identifier in diskIdSlot.2 as a foreign drive to format — hence the "Wrong" flag and the OVERWRITTEN warning.

Fix, array stopped: back up the file, move the identifier into diskId.2, set diskIdSlot.2="-", reboot. The array started normally, all 26 containers and the HA VM came back, and the interrupted scrub resumed on its own.

The member still shows as sdd rather than sdd1, so the underlying asymmetry is still there — I'll redo the replacement properly with a partition when I can afford another 10-hour resilver.

Two suggestions I got elsewhere would have destroyed the pool, worth flagging: unassigning the drive to start "degraded" (a raidz1 config with a missing slot won't import, and Unraid then offers to format all remaining members), and running zpool labelclear/wipefs on the drive (it's a live member holding 2TB of resilvered data). Neither is safe on raidz.

Lesson learned: on Unraid, replace pool drives through the GUI, or if using the CLI, always pass a partition.