JorgeB

There appear to be other issues with the filesystem, but it didn't mount initially because of a bad log tree, this may help getting past that:
 
btrfs rescue zero-log /dev/sde1  
Then re-start the array, if the pool mounts good idea to make sure backups are up to date.

Syslog starts over after every boot, so not much to see, if it keeps happening enable the syslog server and post hat one after a crash/hang.

Currently you need at least one device assigned to the array, an old flash drive can fulfill that requirement.

It's missing from the System Devices, similar to Windows device manager, at least I'm not seeing it there, you can confirm by going to Tools -> System Devices.

This is a bug, it will be fixed for v6.12.7, it happens if the drive has an existing partition starting on sector 2048, and it did:
 
Jan 16 09:44:53 Flint kernel: mdcmd (5): import 4 sdc 2048 9766435820 0 WDC_WD100EFAX-68LHPN0_JEKXKXVZ  
For now if you manually wipe the drive (or use UD to do it) and reboot first this will not happen.
 
 
 

Regular Tp-link should work, though it's a Realtek.

That is correct, and there's no other way I know off other than limiting the disks for that share, but like you mentioned, you'd need to change once it gets full.

Likely GiB vs GB.

Jan 15 09:39:21 Hyperion root: Warning: The kernel is still using the old partition table. Jan 15 09:39:21 Hyperion root: The new table will be used at the next reboot or after you Reboot and try again.

If it's a one time thing you can ignore, if it keeps happening 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/

There are other issues with the filesystem, suggest backing what you can and re-format the pool, also since checksum errors are being detected it would be a good idea to run memtest.

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.

ATA errors should not crash the server, but check/replace cables for disk3 to see if they go away.

Yes, Unraid cannot format an encrypted drive without the encryption key.

Not for pools, trim works with pools.

Check filesystem on disk2, run it without -n, and if it asks for -L use it.

You can do it manually, they are saved on /boot/config/parity-checks.log

The filesystem is now detected but there's an issue with the log tree, if that is the only problem this may help:
 
btrfs rescue zero-log /dev/nvme0n1p1  
Then re-start the array.

Check this:
https://forums.unraid.net/topic/103938-69x-lsi-controllers-ironwolf-disks-disabling-summary-fix/?do=getNewComment
 

Looks more like a power/connection issue with the SSD, replace cables, also having a similar issue with this unassigned disk:
Hitachi_HDS721010CLA332_JP2940HD0D5TBC

Check filesystem on disk5, run it without -n

ixgbe 0000:03:00.0: The EEPROM Checksum Is Not Valid  
Similar to this, look for a firmware update:
https://forums.unraid.net/topic/146542-x10sdv-4c-tln2f-does-not-recognize-mb-10g-nics/?do=findComment&comment=1319716
 

In this case 100% is good (and normal), it means all RAM allocated to the ARC (1/8 by default) is being used, it helps zfs performance.

That suggests a network (or client) problem.

If you are using a board with a Realtek 2.5 GbE NIC make sure you are not using jumbo frames, or you can have that issue, if you are, you can edit /config/network.cfg on the flash drive and remove the MTU=9000 line and reboot.