JorgeB

Check/replace cables on the Samsung QVO pool device, there are continuous error in the log.

Macvlan call traces will usually end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), then reboot.

I can but didn't notice, we always recommend posting the diags in a new post for better visibility.
 
Unraid driver is crashing when the parity sync starts, this usually suggests a hardware problem, but sometimes could be compatibility, would suggest running memtest and if nothing is found try with a different release, for example v6.11.5
 
 

Server is constantly running out of RAM, try limiting more the RAM for VMs and/or docker containers, the problem is usually not just about not enough RAM but more about fragmented RAM, alternatively a small swap file on disk might help, you can use the swapfile plugin:
 
https://forums.unraid.net/topic/109342-plugin-swapfile-for-691/

Unraid cannot emulate the disks correctly with so many invalid disks, if the disks are healthy you can do a new config and re-sync parity.

Yep.

The test confirms the network is the problem, could be NIC, switch, cabels, etc, also if you get the same speeds over wifi check the routing.

System share is configured to use a pool that no longer exists:
 
shareUseCache="only" shareCachePool="main-data"  

The pool should be imported in the exact same order as the zpool status shows.

Is bridging disabled for eth0? Ipvlan is only an option if bridging is enabled.

Dec 14 10:31:40 GenX-Nas kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Dec 14 10:31:40 GenX-Nas kernel: ? _raw_spin_unlock+0x14/0x29 Dec 14 10:31:40 GenX-Nas kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]  
Macvlan call traces will usually end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), then reboot.

Disk read errors were on spin up, and likely this is the issue:
 
 

Currently is not possible to select another pool as secondary storage, it should be in the near future.

This error usually means the date and time are not correctly set.
 
If NTP isn't working manually set the correct date and time or the key will fail to install.

This may help if the log tree is the only problem:
 
btrfs rescue zero-log /dev/sde1  
Then restart the array

The device failed and needs to be replaced, you cannot create a raid1 with a failed device, since it will abort on the read errors, copy what you can from that pool, then create a new raid1 pool with new devices.

Create a user script with:
 
#!/bin/bash /sbin/poweroff  
And schedule it to run a the time you want.

If you know the assignments, suggest you do a new config and re-assign all the devices, including the pool.

I would recommend removing the IP and gateway from eth1, or set them to a different subnet.

Nov 30 21:22:08 dringenet-MS kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Nov 30 21:22:08 dringenet-MS kernel: ? _raw_spin_unlock+0x14/0x29 Nov 30 21:22:08 dringenet-MS kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan] Macvlan call traces will usually end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), then reboot.

That error is usually fatal with btrfs, since the disk is still mounting backup anything important and then recommend re-formatting.

Try
btrfs rescue zero-log /dev/nvme0n1p1  
Then restart the array

You are using a controller with a SATA port multiplier, and there are 5 disks on the same port, so bandwidth of a single SATA port is shared by all 5.

Not sure what it could be, the dataset appears on the list, so it should exist, did you try an array restart? Or just umnount the fs and remount.

Check filesystem on both disks, run it without -n, next time recommend only rebuilding on top of the old disks if the filesystem can be successfully repaired first.