JorgeB

Problem with the onboard SATA controller, quite common with some Ryzen servers, reboot and post new diags after array start, if this continues to happen best bet is to get an add-on controller (or use a different board).

Looks like a power/connection problem with the parity disk, check/replace cables and try again, look at the syslog to confirm the ATA errors are gone, or post new diags.

Filesystem is going read-only due to lack of space, but I'm not seeing why it's running out of space at mount time, this usually happens when a balance was started but not signs of "balance resumed" in the log, in any case please try this, with the array stopped type:

 
mkdir /temp mount -o skip_balance /dev/sdf1 /temp btrfs balance cancel /temp umount /temp  
Then start the array and post new diags.

Backup the licensed key, after the backup is done recreate the flash drive with a new install, copy the /config folder from the trial key to the licensed key, restore only the key from the backup.

Try rebooting in normal mode, if you get stale config again uninstall all the plugins then re-install one at a time.

Go to Settings -> Network Settings -> Interface rules and make the Gbit NIC eth0, then reboot, it will have the same settings as the older eth0.
 
eth1 should then use a different subnet for the direct PC connection.

Constant crashing, start by running memtest.

That's usually a flash drive problem, try using a different one to test.

Sdc is part of a different filesystem, should still be able to recover data from the NVMe device using the recovery options here, use the ones that have 'degraded' in the mount options.

Cache replacement is broken in v6.9, I did a bug report some time ago but it's still not fixed.

And the GUI is still inaccessible correct? If yes, I'm not seeing anything obvious, try rebooting in safe mode, disable docker/VM services and start the array to see if there's any difference.

Not possible, but these addresses can change if you change/add/remove any harware, it's done by editing the VM config, in the end, it should be under "other PCI devices", just unselect it with the VM stopped, e.g.:
 

Delete the file manually, on the console type:
rm /mnt/disk4/system/docker/docker.img  

Couple of DIMMs are dual rank, so speed should be set @ 1866MT/s, also make sure power supply idle control is correctly set:
 
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173
 

Only eth0 should have a gateway assigned, remove it from the other interfaces.

OK, logs is clean now, first lets cancel the btrfs balance, to do that:

 
mkdir /temp mount -o skip_balance /dev/sdj1 /temp  
If mount is successful type:
btrfs balance cancel /temp  
then
umount /temp  
Now unassign cache1, start array, stop array, re-assign both cache devices, start array and post new diags.

Please don't create multiple threads about the same thing, see my reply in your other post.

Run a scrub, then check that in the output all errors were corrected.

Unassign all cache devices, start array, stop array, re-assign all cache devices, start array, that should do it.

Try adding 30 secs or so to the shutdown timeout.

This device is being pass-trough to the Windows VM:
 
<hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </source>  
And it is the NIC:
06:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-V [8086:15f3] (rev 03) Subsystem: Micro-Star International Co., Ltd. [MSI] Ethernet Controller I225-V [1462:7d32]  
When you change/add/remove hardware it's normal for some devices to change address, so you might need to adjust.

Docker image is corrupt, delete and recreate.

Looks more like a flash drive problem, also make sure it's using a USB 2.0 port.

I can't see unassinged devices number in the diags, but since there's only one unassigned disk I assume it's the 6TB Seagate, if yes the disk looks OK, so just mount it UD and if all looks good format disk 14 and copy the data over.

See if this applies to you, if yes, upgrading to v6.10 and switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info.:
 
https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/
See also here:
https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/