JorgeB

Log out from Connect and then log back in.

If you mean to then rebuild disk12, there's a way, but it will only work if parity is still valid, it won't hurt to try though:
 
-Tools -> New Config -> Retain current configuration: All -> Apply
-Check all assignments and assign any missing disk(s) if needed, including the new disk12, replacement disk should be same size or larger than the old one
-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 disk12
-Start array (in normal mode now) and post new diags.

This is a non issue since 6.10.3

Choose cache as primary and then change mover action from array to cache, it's in the link above.

Unmountable disk is usually fixed by check filesystem, not by replacing the disk, that will just rebuild another unmountable disk, but I don't see any unmountable disk in your diags, did you format it?

It's not logged as a disk problem, and SMART looks fine, a lot of CRC UDMA errors so the SATA cable would be the main suspect.
 
P.S. lots of OOM errors logged, they appear to be caused by Frigate.

That won't create a dataset, it would have if you had used the mover for example, like you mentioned the plugin can convert it to a dataset for you, or use the mover to move to the array, then back to cache.

Due to all the log spam the start of the problem is missing, but looks like a HBA problem, reboot and post new diags after array start.

ATA1 is not the flash drive, it should be the device connected to first motherboard SATA port.

Known issue, v6.12.10 should be out soon with a fix.

Yes, that's fine, unfortunately there's nothing relevant logged, this usually points to a hardware issue, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

Looks like a NIC problem:
 
Apr  1 11:55:05 EasternEXT kernel: atlantic 0000:06:00.0 eth0: failed to kill vid 0081/1  
Do you have a different NIC you could test with?

It means supporting zfs pools with cache, logs, dedup, special and/or spare vdevs.

If you still have appdata you can recreate the image:
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
Also see below if you have any custom docker networks:
https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks

You may have a network problem, you can try deleting/renmaming /boot/config/network.cfg to go back to default DHCP and re-rest, it may also be a good idea to re-start your router, if the same it basically can only be a router or network/internet problem.

Unfortunately there's nothing relevant logged in the latest syslog, this usually points to a hardware issue, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

Usually the key is named for the license type, i.e.: Basic.key, Plus.key or Pro.key.

Check filesystem on disk1, run it without -n and if it asks for -L use it.

It was logged as a disk problem.

If you still have the appdata try recreating the docker image:
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
Also see below if you have any custom docker networks:
https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks
 

Try installing the Nvidia driver plugin for the GUI mode to work, but note that you can access the GUI from another computer.

Known issue, v6.12.10 should be out soon with a fix.

You need to re-enable the disks first:
 
https://docs.unraid.net/unraid-os/manual/storage-management#rebuilding-a-drive-onto-itself
 
P.S. No need to do it in maintenance mode, or the array will be offline.
 
 

Check filesystem on the emulated disks 9 and 12, also post the complete diagnostics.

Those SSDs won't be able to maintain high sustained write speeds, also please note that trim is not supported for array devices, I would recommend creating a raidz zfs pool instead, it will perform much better, you can use an old flash drive to fulfill the current array device requirement.