JorgeB

If the log tree is the only problem this may help:
 
btrfs rescue zero-log /dev/nvme0n1p1  
The re-start array.

It could, there's nothing logged suggesting it's a hardware issue.

SMART test passed but the errors are logged as a disk problem, replace/swap cables to rule that out but if you get more I would replace the disk.

Click the green lock, top -right of the GUI to unlock.

Replace cables on disk3 and try again.

Try uninstalling the
 dynamix.s3.sleep.plg - 2023.03.23  (Up to date)

It is at the moment, pool monitoring is expected to be implemented in the future, you can this for now:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=700582
 

I've seen that before with those Dell RAID controllers, unfortunately no real solution that I know of, other than using a different controller.
 
You also need to check filesystem in disk1 and change from mcvlan to ipvlan.

Try disabling the network bond, it can limit the speed to the slower NIC, and set eth1 and eth0, bottom of network settings, reboot required.
 
 

Try importing read-only:
 
zpool import -o readonly=on ssdraid  
If it works backup and re-create the pool

You can do it but only manually for now, using the CLI (or a script).

A pool should never be set to xfs, stop the array, click on the first pool device and change fs to btrfs.

Not seeing anything that suggests a flash drive problem, I see some older macvaln call traces, make sure you change the docker network to ipvlan, also some miscellaneous segfaults, so good idea to run memtest, issue looks more hardware related.

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.