JorgeB

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.

You can try disabling SSL, type in the CLI:
use_ssl no  

Jan  8 11:28:47 OTS-Server kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Jan  8 11:28:47 OTS-Server kernel: ? _raw_spin_unlock+0x14/0x29 Jan  8 11:28:47 OTS-Server kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan] 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.

Try rebooting, after a crash it may not start correctly before that.

You are having issues with the cache device, looks more like a power/connection, start by replacing the cables, it would also be a good idea to update to latest stable.

You can use a trial key, then see here if you don't know the assignments:
 
https://docs.unraid.net/unraid-os/manual/changing-the-flash-device/#what-to-do-if-you-have-no-backup-and-do-not-know-your-disk-assignments

That should work as long the USB bridge is transparent.

Set test to primary=cache, secondary=array, and mover cache->array, then run the mover.

SMART looks looks fine, and the drive is dropping offline, suggesting more a power/connection issue, but if you already replaced cables could be the disk.

Just set the remote server IP to be the same as that server's IP, it will log locally to that server.

root       293 59.5  0.0      0     0 ?        R    15:44   7:35  \_ [kworker/3:1+usb_hub_wq]  
See if this helps:
https://forums.unraid.net/topic/129514-high-cpu-load-caused-by-kworker-and-ksoftirqd-usb-auto-suspend/?do=findComment&comment=1179867
 

The logs you posted shows continuous disk errors, I would like to see if if they persist using a different controller and cables, if yes it's likely a disk issue.

Scrub is aborting, suggest copying what you can from the pool and reformat, also see here for better pool monitoring in case the devices drop again.

Run it again without -n or nothing will be done, if it asks for -L use it.

A reboot should bring the shares back.

Disk dropped offline and reconnected, this is usually a power/connection problem, since there are also UDMA CRC errors start by replacing the SATA cable.

Prefer was the old setting, now you set primary storage as the pool, secondary as the array, mover action array -> pool, that's the new equivalent of cache prefer.

Recreate the docker image:
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file

If xfs_repair cannot fix the filesystem your options are limited, you can restore from a backup or use something like UFS explorer to see if it can recover most data.

Pool is going read-only during the balance due to being completely full, you should avoid completely filling up a COW filesystem, like btrfs or zfs.
 
Jan  8 12:52:56 SDCHONITower kernel: BTRFS: error (device sdh1: state A) in __btrfs_free_extent:3075: errno=-28 No space left Jan  8 12:52:56 SDCHONITower kernel: BTRFS info (device sdh1: state EA): forced readonly  
You can try canceling the balance to see if it then allows you to move some data, stop the array and type:
mkdir /x mount -t btrfs -o skip_balance /dev/sdh1 /x btrfs balance cancel /x umount /x  
Now restart array and post new diags
 
 
 

Contact support from the registered email and send the invoice, that will be enough.

Yes.

If the log tree is the only issue this may help:
 
btrfs rescue zero-log /dev/sdf1  
Then re-start array, also change docker network to ipvlan.