JorgeB

The pool currently has a missing device, and the GUI is not reflecting that. You should still be able to fix it and keep its data using the CLI. You can then keep that disk as a pool or move it to the array as data if you prefer; I can post more detailed instructions if you like

Do you have the time codes? It would be good to see how long the crash happens after the rebuild start, if it always immediate or just a couple of seconds; I would no longer consider it a hardware issue. If you enabled the syslog server it should have that, as long as keep it all in a single file, where there could be multiple crashes logged for comparison. My suggestion for now, to see if there's really a specific issue when trying to rebuild that disk, would be to copy all the data from the emulated disk to the actual disk, then do a new config and resync parity, and see if that doesn't crash. Can post more detailed instructions if needed.

Just to be clear, licenses cannot be transferred to an SSD, it can only be tied to a flash drive or TPM, even if using an internal boot pool.

I meant the diags posted, not all those individual files, there's no chance for me to be going through all of them. Please just post that file

Do that for half the installed plugins; retest and they are the other half if needed.

Something weird happened there to corrupt so many filesystems, likely a hardware issue. You can try the read-only option, or even -FX as a last resort, but possibly the only option is also using a file recovery app or destroy and recreate.

You will need to zero the log, it's the only option to try and fix the filesystem, and most often it is not a problem.

Post the output from btrfs fi show

You can rename *.plg in /boot/config/plugins to *.bak, then reboot and retest. If the same, try the other half, then keep drilling down.

It's worth a try, but in my experience, if it doesn't mount read-only, most times this requires a pool destroy and restore. If you don't have backups, I recommend cloning the disk with dd before proceeding so that you also have the option to use a file recovery app like UFS Explorer. For a single disk zfs pool, the standard cheaper version may be able to recover the data, and the free trial should show if it can recover.

Both show this, mening zfs cannpt write to them, try a read-only import zpool import -o readonly=on -d /dev/md1p1 disk1 zpool import -o readonly=on -d /dev/md11p1 disk11

That looks like a bad flash drive, you can try recreating it first, if the issues persist, best to replace it.

Not seeing anything that would explain crashes, though the syslog is being spammed with USB manager messages, making it much more difficult to analyze; see if you can quiet that. Regarding the hardware, and since it's a Ryzen CPU, make sure this has been taken care of: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-819173

It's still logging the same errors; suggest using a bigger hammer: try redoing the flash drive, backup the current one first and then recreate it using the USB tool and just restore the bare minimum, like the key, super.dat and the pools folder for the assignments, also copy the docker user templates folder (\config\plugins\dockerMan\templates-user), if all works you can then reconfigure the server or try restoring a few config files at a time from the backup to see if you can find the culprit.

Swap both cables with a different disk, re-enable the disk, and see if there are any more errors: https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself