JorgeB

If it happens again, make sure you save the diags.

Older versions would not require a partition layout to exist, but since 7.2 it's required. Parity should still be 100% valid, assuming it was before, but it may be good to run a check when you can, or at least just the first couple of GBs to confirm.

Partition #1 is used for legacy (BIOS) boot, the smaller #2 is the EFI system partition.

If the containers are working fine it should be OK, but you can also recreate the Docker image to correct that.

I would change one or both to use different ports or cables, then do a new config and check "parity is already valid", then run a correcting parity check.

Sounds good, you can also keep all the assignments when doing the new config, the missing disks won't show

You need to rebuild to resolve that, see the link above.

Can you access the flash drive if you export that publicly?

You can try at least to replace the cables/splitters for the affected disks, then try rebuilding again (check that the emulated disks are still mounting and contents look correct before rebuilding on top)

Disks were already disabled at boot, so we can't see what happened, but they look healthy, so most likely a power/connection issue. If you are happy with the emulated disk1 contents, check/replace cables for those disks, especially if they share something like a power splitter, then rebuild: https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

Not logged as a disk problem, do those disks share anything like a power splitter?

Parity disk doesn't have a partition; open a terminal window and type sgdisk -o -a 8 -n 1:32K:0 /dev/sdX Replace X with the correct parity identifier, sdg from the diags, but this can change if you reboot. After that, reboot the server and see if it now works.

Device is still dropping. If it still happens on a different m.2 slot, best bet it to use a different brand/model device (or a different board if that's easier)

That is for LT internal use, you should disable Enable Developer Sandbox in Settings - Management Settings - Unraid API settings.

Also looks like a power/connection issue with disk1. Any power splitters in use?

Diags still show plugins being installed, can you confirm what you mean by plugins gone? Don't they not show in the plugins page?

Read bandwidth increased substantially; the last one shows 743MB/s, but writes still seem low, any improvements in the expected resilver time?

How are you trying to re-enable the disk, are you doing this? https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

Don't see any obvious issues logged; is it better in safe mode?

When it's the CPU, it's not detected by memtest; the best way to detect it is what you are seeing, Unraid driver crashing during a parity check or sync, there can also be other issues logged.

Please post the diagnostics to see if there's something there

Since no errors were found, clear the stats for the pool and keep monitoring, they are likely old errors.

This suggests some hardware issue, did you save those diags?

Sorry, my mistake, this is a different issue, the issue that is resolved is when you get sent back to the login page: https://product.unraid.net/b/unraid-os-bugs/p/7-3-1-connect-login-loop-from-unraid-api-socket-path-mismatch For the issue you are having, you can follow this bug report: https://product.unraid.net/b/unraid-os-bugs/p/cannot-register-server-into-connect

It's not logged as a disk problem and SMART looks fine, so most likely a power/connection issue. Check/replace cables for that disk, then start the array, confirm the emulated disk is still mounting, and if yes and contents look correct you can then rebuild on top https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself