JorgeB

Make sure it's not the SATA 3.3v pin issue, google that.

If you don't have a key backup (or the email) you need to contact support, you can then replace the flash drive, to recover the array see here.

With single parity you can only emulate one disk at a time, if the emulated disk doesn't mount check filesystem on it and post the output.
 
 

2023-08-08T19:24:04+10:00 Tower kernel: macvlan_broadcast+0x10a/0x150 [macvlan] 2023-08-08T19:24:04+10:00 Tower kernel: ? _raw_spin_unlock+0x14/0x29 2023-08-08T19:24:04+10:00 Tower kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan] Try switching to ipvlan (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)).

The NVMe device dropped offline, this can sometimes help:
 
on the main GUI page click on the flash drive, scroll down to "Syslinux Configuration", make sure it's set to "menu view" (top right) and add this to your default boot option, after "append initrd=/bzroot"
nvme_core.default_ps_max_latency_us=0 pcie_aspm=off e.g.:
append initrd=/bzroot nvme_core.default_ps_max_latency_us=0 pcie_aspm=off
Reboot and see if it makes a difference, if it doesn't best bet it to replace it with a different brand/model device (or try a different board).

Disk1 issue appears to be USB related, we don't recommend USB devices for pool or array, cache was never formatted because of this:
 
Jul 26 09:05:40 Tower root: wipefs: error: /dev/nvme0n1: probing initialization failed: Device or resource busy  
Reboot, try to format again and post new diags.

It should not cause an unclean shutdown, disk is already offline.
 
Disk already dropped so it won't be any worse, but after manually disconnecting it won't likely allow the disk to be remounted before a reboot.

Either one will work, you can just unassign both parity drives, start array, stop array, then assign new 20TB disk as parity and start array to re-sync, once that's done you can add old parity as a new data drive.

This may help if the log tree is the only problem, type in the CLI:
btrfs rescue zero-log /dev/sdb1 Then re-start the array
 

It's the Marvell controller, they are known to have issues, don't use or replace with a different one if possible:
 

Test passed so disk is OK for now, replace/swap cables to rule that out and run another check.

It solves them, to suppress it's a different flag.
 
That look more like a hardware caused issue, run memtest.

Try renaming /boot/config/network.cfg and reboot, settings will go to default DHCP, then reconfigure.

Yes, click the check filesystem link.

Check that the USB port is using 2.0, not a slower speed, or try a different port.

It's usually plug and play if no RAID controllers are involved, if using VMs with passed-through devices they will likely need adjusting.

Aug  8 09:25:35 xephyr kernel: ahci: probe of 0000:06:00.0 failed with error -22  
Controller is detected but it's failing to initialize, try this:
 
https://forums.unraid.net/topic/132930-drives-and-usb-devices-visible-in-bios-not-available-once-booted-asus-wrx80-sage-5965wx/?do=findComment&comment=1208035
 

That's not a filesystem error, it's a bad disk that should be replaced.

You can add another pool at any time.

You can try to force enable disk1 to rebuild disk2, depending on the filesystem you are using it may work but need a filesystem check:
 
-Tools -> New Config -> Retain current configuration: All -> Apply
-Check all assignments and assign any missing disk(s) if needed
-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 disk2
-Start array (in normal mode now) and post the diagnostics
 
 
 

There's nothing logged, suggesting a hardware problem, you can also try using just one DIMM at a time, if both crash alone (with XMP disabled) it basically rules out a RAM issue, memtest doesn't catch everything.

Does it stop doing it if you disable the Deluge container or the VM?

Not that I know of, and I'm not certain the driver is the problem, 
 
with the current connection.

You need to set them to yes, not auto, also make sure you are aware that you cannot copy from a user share to disk share or vice versa.

Try updating to latest stable, also look for a board BIOS update and/or test with just one stick of RAM at a time.