Hi all,

Today i went to check up on my Unraid media server and i was greeted with an array showing 1 (of 2) parity drive and 1 data drive as disabled. The server itself seems fine and all drives short SMART report came out clean so i rebooted the server, hoping it would clear up. Unfortunately, things got worse - the missing data drive came back showing as "new disk" and the parity drive continues to be disabled for no apparent reason.

Removing the data drive from the array and mounting it with UD works fine, all of its content seems to be there and accessible. But for some reason Unraid is reading it as a new replacement drive.

Furthermore, the parity drive's file system seems to have shifted and now it no longer reads the same size as the other parity drive that is still working. As a result, the array cannot be started:

Indeed looking at the logs of the server, the second parity drive (sdc) now shows FS starting at sector 2048 like a data drive, as opposed to sector 64 like Parity disk 1 (sdf).

Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdf 2>&1

Jul 9 16:12:22 Nexus emhttpd: disk sdf 10000831348736

Jul 9 16:12:22 Nexus emhttpd: part sdf1 64 10000831299072

Jul 9 16:12:22 Nexus emhttpd: device sdf partition: sdf1 type: gpt start: 64 size: 9766436812, code: 0xee (3)

Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdd 2>&1

Jul 9 16:12:22 Nexus kernel: mdcmd (1): import 0 sdf 64 9766436812 0 HGST_HUH721010ALE600_7PG5JY9R

Jul 9 16:12:22 Nexus kernel: md: import disk0: (sdf) HGST_HUH721010ALE600_7PG5JY9R size: 9766436812

Jul 9 16:12:22 Nexus emhttpd: disk sdd 10000831348736

Jul 9 16:12:22 Nexus emhttpd: part sdd1 2048 10000830283264

Jul 9 16:12:22 Nexus emhttpd: device sdd partition: sdd1 type: gpt start: 2048 size: 9766435820, code: 0xee (5)

Jul 9 16:12:22 Nexus kernel: mdcmd (2): import 1 sdd 2048 9766435820 0 HGST_HUH721010ALE600_7PG5JA6R

Jul 9 16:12:22 Nexus kernel: md: import disk1: (sdd) HGST_HUH721010ALE600_7PG5JA6R size: 9766435820

Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sde 2>&1

Jul 9 16:12:22 Nexus emhttpd: disk sde 10000831348736

Jul 9 16:12:22 Nexus emhttpd: part sde1 2048 10000830283264

Jul 9 16:12:22 Nexus emhttpd: device sde partition: sde1 type: gpt start: 2048 size: 9766435820, code: 0xee (5)

Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdg 2>&1

Jul 9 16:12:22 Nexus kernel: mdcmd (3): import 2 sde 2048 9766435820 0 HGST_HUH721010ALE600_7PG5LEDR

Jul 9 16:12:22 Nexus kernel: md: import disk2: (sde) HGST_HUH721010ALE600_7PG5LEDR size: 9766435820

Jul 9 16:12:22 Nexus emhttpd: disk sdg 10000831348736

Jul 9 16:12:22 Nexus emhttpd: part sdg1 2048 10000830283264

Jul 9 16:12:22 Nexus emhttpd: device sdg partition: sdg1 type: gpt start: 2048 size: 9766435820, code: 0xee (5)

Jul 9 16:12:22 Nexus kernel: mdcmd (4): import 3 sdg 2048 9766435820 0 HGST_HUH721010ALE600_7PG5MT8R

Jul 9 16:12:22 Nexus kernel: md: import disk3: (sdg) HGST_HUH721010ALE600_7PG5MT8R size: 9766435820

Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdh 2>&1

Jul 9 16:12:22 Nexus emhttpd: disk sdh 10000831348736

Jul 9 16:12:22 Nexus emhttpd: part sdh1 2048 10000830283264

Jul 9 16:12:22 Nexus emhttpd: device sdh partition: sdh1 type: gpt start: 2048 size: 9766435820, code: 0xee (5)

Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdi 2>&1

Jul 9 16:12:22 Nexus reload_services: execute queued job 3

Jul 9 16:12:22 Nexus kernel: mdcmd (5): import 4 sdh 64 9766436812 0 HGST_HUH721010ALE600_7PG5LVMR

Jul 9 16:12:22 Nexus kernel: md: import disk4: (sdh) HGST_HUH721010ALE600_7PG5LVMR size: 9766436812

Jul 9 16:12:22 Nexus kernel: md: import_slot: 4 replaced

Jul 9 16:12:22 Nexus emhttpd: disk sdi 10000831348736

Jul 9 16:12:22 Nexus emhttpd: part sdi1 2048 10000830283264

Jul 9 16:12:22 Nexus emhttpd: device sdi partition: sdi1 type: gpt start: 2048 size: 9766435820, code: 0xee (5)

Jul 9 16:12:22 Nexus kernel: mdcmd (6): import 5 sdi 2048 9766435820 0 HGST_HUH721010ALE600_7PG5KVYR

Jul 9 16:12:22 Nexus kernel: md: import disk5: (sdi) HGST_HUH721010ALE600_7PG5KVYR size: 9766435820

Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdb 2>&1

Jul 9 16:12:22 Nexus emhttpd: disk sdb 10000831348736

Jul 9 16:12:22 Nexus emhttpd: part sdb1 2048 10000830283264

Jul 9 16:12:22 Nexus emhttpd: device sdb partition: sdb1 type: gpt start: 2048 size: 9766435820, code: 0xee (5)

Jul 9 16:12:22 Nexus kernel: mdcmd (7): import 6 sdb 2048 9766435820 0 HGST_HUH721010ALE600_7PG5LX3R

Jul 9 16:12:22 Nexus kernel: md: import disk6: (sdb) HGST_HUH721010ALE600_7PG5LX3R size: 9766435820

Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdc 2>&1

Jul 9 16:12:22 Nexus emhttpd: disk sdc 10000831348736

Jul 9 16:12:22 Nexus emhttpd: part sdc1 2048 10000830283264

Jul 9 16:12:22 Nexus emhttpd: device sdc partition: sdc1 type: gpt start: 2048 size: 9766435820, code: 0xee (5)

Jul 9 16:12:22 Nexus kernel: mdcmd (30): import 29 sdc 2048 9766435820 0 HGST_HUH721010ALE600_7PG5JL3R

Jul 9 16:12:22 Nexus kernel: md: import disk29: (sdc) HGST_HUH721010ALE600_7PG5JL3R size: 9766435820

Now here's the real pickle: How do i recover this array without losing any data? Removing the parity 2 drive assignment causes a notification to pop-up that upon start of the array the missing data drive will be overriden (im guessing it's going to try to rebuild it?)

Im currently running a full SMART check on Parity drive 2 (sdc), it's taking a long while. But i dont feel like it's going to reveal anything more than the short SMART check. To me it looks like a corrupted array config rather than failed drives. Any ideas?

Attached is the diag zip for further info.

nexus-diagnostics-20260709-2138.zip

Edited Thursday at 08:42 PM1 day by alexfsr

Upon further inspection, it seems drives sdc and sdh may have somehow switched places in UnRaid. Drive sdh appears to have the same FS size parameters as Parity drive sdf.

But curiosly, mounting drive sdh via UD shows it to have the expected data drive contents, while drive sdc is unmountable (as i would expect from the parity drive - my understanding is that the parity drives hold raw bit data for doing the bitwise parity math with the other drives in the array). How can one resolve this situation??

Edited yesterday at 01:33 AM1 day by alexfsr

Unassign disk4, start the array, and post new diags.

3 hours ago, JorgeB said:

Unassign disk4, start the array, and post new diags.

Started in Maintenance Mode.

nexus-diagnostics-20260710-1335.zip

Diags after start in normal mode, please; maintenance mode will not mount the disks.

5 hours ago, JorgeB said:

Diags after start in normal mode, please; maintenance mode will not mount the disks.

Ok, here it is. I hope mounting it normally doesnt let apps and dockers to start messing with it.

nexus-diagnostics-20260710-2025.zip

Emulated disk 4 is mounting. Assuming contents look correct, you can rebuild on top and resync parity2 at the same time

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

3 minutes ago, JorgeB said:

Emulated disk 4 is mounting. Assuming contents look correct, you can rebuild on top and resync parity2 at the same time

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

The problem is i cannot start the array in this configuration. When i re-assign the drives to their original assignements, it gives an error that Parity drive is not biggest. The content of disk 4 does otherwise look correct, yes.

Parity2 is 1 MiB aligned, instead of the default 4 KiB. Update to 7.3.2, it should be able to handle that automatically. If not, post new diags after updating since it provides better partition info on the syslog.

16 minutes ago, JorgeB said:

Parity2 is 1 MiB aligned, instead of the default 4 KiB. Update to 7.3.2, it should be able to handle that automatically. If not, post new diags after updating since it provides better partition info on the syslog.

Updated the server to latest version. Still cannot start the array. Do i need to start the array without disk 4 again to provide good diags?

You need to unassign it and reassign it at least once, then post the diags.

17 minutes ago, JorgeB said:

You need to unassign it and reassign it at least once, then post the diags.

Ok this diag is after Parity 2 was unassigned and re-assigned, without starting the array (still unable).

nexus-diagnostics-20260710-2143.zip

Also, looking into the array drives, it appears all drives except for Parity 1 are using 1-Mb alligned GPT. Which is probably what causes the issue, but why now? How did it work fine for 1 year up until now with 0 issues?

Edited 13 hours ago13 hr by alexfsr

OK, the sizes match the expectation; I think the code is not accepting the 4k/1M layouts because parity2 is disabled.

Try this:

• unassign parity 2 and you should be able to start the rebuild (if not, unassign and reassign disk 4 as well).

• After the rebuild finishes, reassign parity2 (you may need to delete it's partition first, don't remember if Unraid will recreate a new one if there's an existing one, since 1 MiB aligned partition will no longer work; if you need to wipe it, you can use wipefs -a /dev/sdX)

4 hours ago, alexfsr said:

How did it work fine for 1 year up until now with 0 issues?

It's fine until you have to rebuild a data disk; a rebuild will create a new 4K aligned partition, it woudl work with 7.3.x if all disks are the same size, which is the case, but both parity drives were enabled.

3 minutes ago, JorgeB said:

OK, the sizes match the expectation; I think the code is not accepting the 4k/1M layouts because parity2 is disabled.

Try this:

• unassign parity 2 and you should be able to start the rebuild (if not, unassign and reassign disk 4 as well).

• After the rebuild finishes, reassign parity2 (you may need to delete it's partition first, don't remember if Unraid will recreate a new one if there's an existing one, since 1 MiB aligned partition will no longer work; if you need to wipe it, you can use wipefs -a /dev/sdX)

It's fine until you have to rebuild a data disk; a rebuild will create a new 4K aligned partition, it woudl work with 7.3.x if all disks are the same size, which is the case, but both parity drives were enabled.

Removing Parity 2 disk allows the array to start but gives warning that all data on disk 4 will be overriden. Is that ok?

Also should i start the array in Maintenance mode? Help page you linked earlier says it speeds up the process.

Also are you sure the rebuild of disk 4 will make it 4k-alligned? All other data drives are also 1MB-alligned like Parity 2.

Edited 12 hours ago12 hr by alexfsr

That's expected since it will be rebuilt; since the emulated disk was mounting you can proceed, you can do it in maintenance mode if you prefer, but it's fine in normal mode as well if you need to access the array; just avoid array heavy activity to not slow down the rebuild.

8 minutes ago, JorgeB said:

That's expected since it will be rebuilt; since the emulated disk was mounting you can proceed, you can do it in maintenance mode if you prefer, but it's fine in normal mode as well if you need to access the array; just avoid array heavy activity to not slow down the rebuild.

Alright, ive started the array rebuild without parity 2. Im guessing i'll have to indeed clear it out before re-adding it as Parity 2 in order to match Parity 1's configuration (4k-alligned). Disk 4 is now showing 4k-alligned system as well.

Thanks for the help!

Edited 12 hours ago12 hr by alexfsr