JorgeB

It's not logged as a disk problem, and the disk dropped offline and reconnected again, suggesting a power/connection issue, or controller problem, but power/connection is much more likely, cancel the rebuild, check/replace cables or PSU and try again

Mar  7 19:30:11 outland emhttpd: device /dev/sdm problem getting id  
This means one of the devices is being detected twice, make sure there's only only cable from the shelf to the controller.

Try updating the disk location plugin.

Lots of crashing on that log, looks more hardware related to me, but post the complete syslog next time, it may have more info.

Feb 25 17:54:01 Tower kernel: mpt2sas_cm0: SAS host is non-operational !!!!  
Make sure the controller is well seated and sufficiently cooled, you can also try a different PCIe slot.

Try looking for one, to see if it's somwhere else, e.g.:
 
find /mnt -iname '2 Days*'  

You can boot using the GUI mode.

Test passed so the disk is OK for now, keep monitoring, any more errors in the recent future you may consider replacing, monitor especially this attribute:
 
Total uncorrected errors  

Update the Chinese language pack to latest.

I have confirmed it only happens with zfs, it works fine with two devices, with three (or more, most likely) it doesn't, it works correctly until the two first devices are below 50%, once they both get to 50% it starts doing the almost most free thing, keeping the last disk with twice of the free space of the other ones.
 
I'll report this issue to LT and it should be fixed for the next release.

Based on the diags the rebuild never started, it crashed partitioning the disk, and recon position is at 0, reboot and try again.

Not sure I follow, start the array, pool will be unmountable, run the command at that time, since the pool is encrypted you cannot run it with the array stopped, another reason I don't recommend encryption, unless you really really need it.

According to the screenshot those shares are not being exported, click on each share and change export to yes.

Try booting in safe mode.

It means it's a cache only share.

You should not mount anything else under /mnt/user, that is reserved for Unraid, use a different mountpoint, like the UD created /mnt/addons for example

Unfortunately there's nothing relevant logged, this usually points to a hardware issue, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

There are no errors logged, this looks more like a USB problem to me, can you connect the disks to a SATA controller and re-test?

Disk issues could be this:
https://forums.unraid.net/topic/103938-69x-lsi-controllers-ironwolf-disks-disabling-summary-fix/
 
Sync issues could still be RAM, reboot to clear the log then run two consecutive parity checks without rebooting and post new diags.

That's normal with an odd number of devices and btrfs, used space will be correct and free space will get closer to correct as you fill up the pool.

It doesn't, but with the default allocation method it will now start writing to that disk exclusively until it's half full.

Activation codes don't expire.

You are using a controller with SATA port multipliers, those are not recommended, they can cause those sort of issues, could also be a power/connection issue.

Feb 28 17:49:22 Tower kernel: usb 2-4: USB disconnect, device number 2  
USB problems, use SATA if possible.

I assume it's the data zpool?
 
Mar  5 10:16:10 SERVER1 root: cannot import 'data' as 'data': I/O error Mar  5 10:16:10 SERVER1 root: #011Recovery is possible, but will result in some data loss. Mar  5 10:16:10 SERVER1 root: #011Returning the pool to its state as of Tue Mar  5 09:14:09 2024 Mar  5 10:16:10 SERVER1 root: #011should correct the problem.  Approximately 16 seconds of data Mar  5 10:16:10 SERVER1 root: #011must be discarded, irreversibly.  Recovery can be attempted Mar  5 10:16:10 SERVER1 root: #011by executing 'zpool import -F data'.  A scrub of the pool Mar  5 10:16:10 SERVER1 root: #011is strongly recommended after recovery.  
If you are OK with losing the 16 secs of data, and that's probably the only recovery option, type
zpool import -F data once it's imported type
zpool export data Then restart the array, pool should import normally, run a scrub.