JorgeB

Correct

Enable the syslog server and post that after the next crash.

Unless you are over the annual transfer limit, you can replace the license yourself: https://docs.unraid.net/unraid-os/system-administration/maintain-and-update/changing-the-flash-device/ If you are over the limit, contact support with the old and new GUIDs and they should do it soon.

You are using a controller with an STA port multiplier, causing issues for multiple drives, example: Jul 7 16:35:38 Kaokulk kernel: ata12.03: hard resetting link Jul 7 16:35:38 Kaokulk kernel: ata12.03: SATA link up 6.0 Gbps (SStatus 133 SControl 330) Jul 7 16:35:44 Kaokulk kernel: ata12.04: link is slow to respond, please be patient (ready=0) Jul 7 16:35:48 Kaokulk kernel: ata12.04: softreset failed (device not ready) Jul 7 16:35:51 Kaokulk kernel: ata12.15: qc timeout after 3000 msecs (cmd 0xe4) Jul 7 16:35:51 Kaokulk kernel: ata12.04: failed to read SCR 0 (Emask=0x4) Jul 7 16:35:51 Kaokulk kernel: ata12.04: reset failed, giving up Jul 7 16:35:51 Kaokulk kernel: ata12.04: failed to recover link after 3 tries, disabling Recommends replacing that with one from the recommended list, then post new diags after array start

Log was being spammed with these for hours: Jul 10 09:42:53 Zeke smbd[2935295]: [2026/07/10 09:42:53.474647, 0] ../../source3/smbd/smb2_service.c:755(make_connection_snum) Jul 10 09:42:53 Zeke smbd[2935295]: make_connection_snum: canonicalize_connect_path failed for service Disk_Test, path /mnt/disks/Disk_Test Nothing else there.

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.

It would depend if they are on the same controller and the order they are connected, if they are on the same and port 1 corresponds to slot 1 and so on, then it would likely show up first (if the same size) Remember that you also need to know the two data disks order, since parity2 is only valid id the order for all the data disks is correct. The final part of the procedure I posted above only works after a normal mount, and possibly one or more filesystem check, meaning if the disks are in the wrong order, it will likely do a little more damage, but it there's no other record of which drive was which, you can still try it, but honestly not very hopefully it will work given the circumstances.

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.

Yes, but you still need to know which one was parity and parity2

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

The only option that I can see is if it's possible to find out how the disks were assigned before, by looking for some old digs, or a flash backup, and even so, it may fail because the array was started and used with the wrong assignments, so parity will never be 100% valid, even with the disks correctly assigned, but it's worth a try as described above; if the assignments are known, there's nothing to lose at this point, but I don't see a way to find the correct assignments if old diags, backup, screenshot, etc., are not available

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.

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

I see that you did. This will make it very difficult to recover, but there's a small possibility if you know which drive was parity and which wsa parity2 and the correct order for all the data disks, and parity is still mostly valid, that is, not much was written since the wrong start. If you want to try, that would require doing a new config: -Tools -> New Config -> Preserve current assignments: All -> Apply -Check all assignments and assign any missing disk(s) if needed; both correct parity drives need to be correctly assigned as they were; they are not interchangeable, as well as the remaining data disks in their original order, or it will never work. -IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked) -Stop array -Unassign both disks that were wrongly assigned as parity before -Start array (in normal mode now), and post new diagnostics

Did you start the array with the wrong parity drives?