JorgeB

Also, and just for competition, partition #4 always exists, even for a dedicated pool, but in those cases it will be very small, around 1MB. I believe this was done mostly for code simplification.

Alternatively, you can mount each disk with UD in read-only mode to look for it, the advantage of that is that parity would remain valid.

You can use the link above to recover the assignments; after that, you should be able to access the backup.

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.