JorgeB

USe -L

Jul 29 18:32:36 Andisvault kernel: macvlan_broadcast+0x116/0x144 [macvlan] Jul 29 18:32:36 Andisvault kernel: macvlan_process_broadcast+0xc7/0x110 [macvlan]  
Macvlan call traces are usually the result of having dockers with a custom IP address, 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.

Start here:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173
 

Sep 29 11:00:02 nas-mass kernel: ata1: SError: { UnrecovData 10B8B BadCRC }  
This really looks like a bad SATA cable, I would try replacing it once more, if issues persist replace the device, could be making a bad connection.

Sep 16 13:39:07 Unraid-1 kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Sep 16 13:39:07 Unraid-1 kernel: ? _raw_spin_unlock+0x14/0x29 Sep 16 13:39:07 Unraid-1 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)).

Looks more like a power/connection issue, try again after replacing the cables, also check power, and make sure the emulated disk is still mounting before rebuilding on top.

You shoudl reboot now, the controller crashed, so the the devices are in an unknown state, a simple reboot should bring the data devices back.

Use the Preclear plugin.

I would recommend being on the latest stable, so 6.12.4

Docker service is disabled, go to Settings and enable it.

I'm going to post an example to replicate the complete appdata dataset, including all all descendent file systems, up to the named snapshot:
 
-stop docker service
-create a new snapshot for appdata manually or using zfs master if you prefer
-on the CLI type
zfs send -R docker/appdata@last_snapshot_name | zfs receive destination_zpool_name/appdata  
after this is done type
zfs list -t all  to confirm all child datasets and snapshots are now also on the new pool, then you just need to change the paths, from /mnt/docker/appdata/container to /mnt/new_zpool/appdata/container, or if you are using /mnt/user delete/rename old appdata, then re-start docker service.
 
For the VMs it would be the same, don't forget to stop the VM service before taking the last snaphot.

Was able to test and it works, but it's quite involved:
 
create new temp pool and assign all the devices you plan on adding
set fs to zfs encrypted, any profile
start array, format pool
stop array
unassign all devices from the temp pool and delete it
open new LUKS devices:
 
cryptsetup luksOpen /dev/sdX1 sdX1 --key-file=/root/keyfile Replace X with correct letter, for NVMe devices it will be '/dev/nvmeXn1p1 nvmeXn1p1', do this for all new devices, if using a passphrase omit --key-file=/root/keyfile and enter the passphrase
Add the new vdevs as explained in the FAQ entry, just need to add mapper to every device, e.g.
zpool add tank -f special mirror /dev/mapper/sdf1 /dev/mapper/nvme0n1p1
stop array
Close LUKS for all new devices:
cryptsetup luksClose sdX1
do the pool import procedure as detailed in the FAQ

Since you have a single device pool, i.e., without redundancy, any share that has files on that pool will appear as unprotected, this is normal.

Looks like the fs is not recoverable, if I understood correctly you've rebuilt on top of the original disk? If yes best bet is using a file recovery util, like UFS explorer, there's a free trial you can use to see if it can find the data.

Disk3 appears to be failing, run an extended SMART test to confirm, that should not cause lockups, but this will:
 
Sep 23 11:46:57 Odyssey kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Sep 23 11:46:57 Odyssey kernel: ? _raw_spin_unlock+0x14/0x29 Sep 23 11:46:57 Odyssey kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]  
Switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)).

Maybe with the mover plugin, at least some of those:
 

Yep.

Disk4 has a lot of reallocated sectors, and the errors are logged as a disk problem, probably should just replace it now, but you can also run an extended SMART test to confirm, disk2 should also be replaced when possible, since it has a failing now SMART attribute, though one that usually doesn't cause read errors.

Everything looks normal to me, can you access using the IP?
 
Sep 28 15:48:56 [996]: br0: leased 192.168.7.110 for 13000 seconds  
Input http:// before since the browser can default to https

yes, or 
 
 

Yes, with v6.12.4, see the release notes.

You can just resync parity, or if you think parity is mostly valid do a new config, check parity is already valid, then run a correcting check.
 
You also need to check filesystem on disk1.

See here:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=511923
 

That's the kernel version.
 
The call traces mention XFS so check filesystem on all XFS disks, run it always without -n, then reboot and see if it's any better.

SSD is dropping offline, try different cables, probably best also to use the onboard SATA controller instead, since the LSI won't support trim.