JorgeB

You are issues with the cache2 Samsung disk, check/replace cables then post new diags after array start.

Try removing the Realtek NIC (if it's more practical you can also bind it to VFIO-PCI), then boot/reboot, one of the Intel NICs should become eth0, then install it again.

Yes.

Look for a BIOS update, this issue has been much less frequent with the newer kernel, so a future one might help more, but if you continue having issues I would recommend using an add-on controller. 

Nope, you'll need to create a regular copy.

First try recreating the flash drive, backup first, if that fails then replace it.

Assuming you have valid parity update again, unassign that disk and start the array, Unraid will recreate the partition so the emulated disk should mount, if yes and contents look correct rebuild on top.

Now stop the array, unassign the new cache device, start array (without any device assigned as cache), stop array, assign old cache device, start array, old cache fs should be back.

Disk dropped offline and reconnected, check/replace cables and post new diags after array start.

Sorry, not sure what exactly needs to be modified, but you can ask the OP of this thread, he was the one with the same issue, also because of While Label drives, so you can even ask him for the new modified file, it should also work for you.

Dec 8 00:13:32 Beast kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Dec 8 00:13:32 Beast kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]  
Macvlan call traces are usually the result of having dockers with a custom IP address and will 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)).

Set all those shares to cache=yes, disable docker and VM services and run the mover, once done everything should now be on the array, then set the shares to cache=prefer and select the destination pool you want for each one then run the mover again.

Nov 28 11:53:25 nugget kernel: BTRFS error (device md1): parent transid verify failed on 4376705761280 wanted 36734 found 36690  
This error is fatal, it means some writes were lost, it can happen if a storage device lies about flushing it's write cache, this is usually a drive (or controller) firmware problem.
 
Btrfs restore (option #2 here) is the best bet to try and recover some data for this, then the device will need to be formatted and the data restore.

You won't be able to get SMART from a RAID volume, also note that you should not use RAID volumes with Unraid.

Try disconnecting and reconnecting and/or using a different USB controller, but note that we don't recommend USB for array devices.

Call traces are related to a btrfs filesystem, so it could be any in use.

Try booting in safe mode to rule out any plugin issues but it could be a compatibility issue between your hardware and the newer kernel.

In the earlier diags there are issues with multiple devices before parity drops offline:
 
Nov 25 07:36:55 Tower kernel: ata14.00: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x6 frozen Nov 25 07:36:55 Tower kernel: ata14.00: irq_stat 0x48000001, interface fatal error Nov 25 07:36:55 Tower kernel: ata14.00: failed command: READ DMA EXT Nov 25 07:36:55 Tower kernel: ata14.00: cmd 25/00:40:48:0d:4a/00:05:f5:02:00/e0 tag 3 dma 688128 in Nov 25 07:36:55 Tower kernel: res 53/84:30:57:10:4a/00:02:f5:02:00/40 Emask 0x10 (ATA bus error) Nov 25 07:36:55 Tower kernel: ata14.00: status: { DRDY SENSE ERR } Nov 25 07:36:55 Tower kernel: ata14.00: error: { ICRC ABRT } Nov 25 07:36:55 Tower kernel: ata14: hard resetting link Nov 25 07:36:55 Tower kernel: ata11.00: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x6 frozen Nov 25 07:36:55 Tower kernel: ata11.00: irq_stat 0x48000001, interface fatal error Nov 25 07:36:55 Tower kernel: ata11.00: failed command: WRITE DMA EXT Nov 25 07:36:55 Tower kernel: ata11.00: cmd 35/00:40:48:f8:49/00:05:f5:02:00/e0 tag 7 dma 688128 out Nov 25 07:36:55 Tower kernel: res 51/84:40:48:f8:49/00:05:f5:02:00/e0 Emask 0x10 (ATA bus error) Nov 25 07:36:55 Tower kernel: ata11.00: status: { DRDY ERR } Nov 25 07:36:55 Tower kernel: ata11.00: error: { ICRC ABRT } Nov 25 07:36:55 Tower kernel: ata11: hard resetting link Nov 25 07:36:55 Tower kernel: ata14: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Nov 25 07:36:55 Tower kernel: ata14.00: configured for UDMA/133 Nov 25 07:36:55 Tower kernel: ata14: EH complete Nov 25 07:36:55 Tower kernel: ata11: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Nov 25 07:36:55 Tower kernel: ata11.00: configured for UDMA/133 Nov 25 07:36:55 Tower kernel: ata11: EH complete Nov 25 10:11:49 Tower kernel: ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 Nov 25 10:11:49 Tower kernel: ata14.00: irq_stat 0x40000001 Nov 25 10:11:49 Tower kernel: ata14.00: failed command: READ DMA EXT Nov 25 10:11:49 Tower kernel: ata14.00: cmd 25/00:40:a8:16:ed/00:05:6d:03:00/e0 tag 24 dma 688128 in Nov 25 10:11:49 Tower kernel: res 53/84:c0:27:17:ed/00:04:6d:03:00/40 Emask 0x10 (ATA bus error) Nov 25 10:11:49 Tower kernel: ata14.00: status: { DRDY SENSE ERR } Nov 25 10:11:49 Tower kernel: ata14.00: error: { ICRC ABRT } Nov 25 10:11:49 Tower kernel: ata14: hard resetting link Nov 25 10:11:54 Tower kernel: ata14: link is slow to respond, please be patient (ready=0) Nov 25 10:11:59 Tower kernel: ata14: COMRESET failed (errno=-16) Nov 25 10:11:59 Tower kernel: ata14: hard resetting link Nov 25 10:12:02 Tower kernel: ata14: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Nov 25 10:12:02 Tower kernel: ata14.00: configured for UDMA/133 Nov 25 10:12:02 Tower kernel: ata14: EH complete Nov 25 10:12:03 Tower kernel: ata11.00: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen Nov 25 10:12:03 Tower kernel: ata11.00: irq_stat 0x80400000, PHY RDY changed Nov 25 10:12:03 Tower kernel: ata11: SError: { PHYRdyChg } Nov 25 10:12:03 Tower kernel: ata11.00: failed command: WRITE DMA EXT Nov 25 10:12:03 Tower kernel: ata11.00: cmd 35/00:40:28:71:ee/00:05:6d:03:00/e0 tag 3 dma 688128 out Nov 25 10:12:03 Tower kernel: res 50/00:00:28:71:ee/00:00:6d:03:00/e0 Emask 0x10 (ATA bus error) Nov 25 10:12:03 Tower kernel: ata11.00: status: { DRDY } Nov 25 10:12:03 Tower kernel: ata11: hard resetting link Nov 25 10:12:03 Tower kernel: ata11: SATA link down (SStatus 0 SControl 300) Nov 25 10:12:09 Tower kernel: ata11: hard resetting link Nov 25 10:12:09 Tower kernel: ata11: SATA link down (SStatus 0 SControl 300) Nov 25 10:12:14 Tower kernel: ata11: hard resetting link Nov 25 10:12:14 Tower kernel: ata19: SATA link down (SStatus 0 SControl 300) Nov 25 10:12:14 Tower kernel: ata20: SATA link down (SStatus 0 SControl 300) Nov 25 10:12:15 Tower kernel: ata11: SATA link down (SStatus 0 SControl 300) Nov 25 10:12:15 Tower kernel: ata11.00: disable device  
This is usually a power/connection problem, could also be a controller issue, save the current syslog
cp /var/log/syslog /boot/syslog.txt then reboot and post new diags after array start.

SMART looks fine, looks like it just dropped:
 
Dec 2 11:57:47 Tower kernel: usb 2-1.7: USB disconnect, device number 3  
Note that we don't recommend USB for array/pool devices, very prone to issues.

You can use:
 
mount -o remount -o autodefrag /mnt/pool_name  
Note that you should not use this if you use snapshots.

What size is you cache device/pool? Also note that split level overrides allocation method.

At least some of issues appear to be caused by free space cache v1, on the console type:
btrfs check --clear-space-cache v1 /dev/sdh1 then post new output of btrfs check

Looks like you were not running in safe mode, do you have the S3 sleep plugin installed? If yes try without it.

See if you can still access /boot, if yes make a copy of /boot/config, if not rebooting might bring the flash drive back, if it doesn't try running chkdsk on it.

If they are still there make sure the share settings are still including them, also Unraid would have created new docker and libvirt images if they resided there, but just starting with a different fs doesn't delete anything, assuming you didn't format the device.