JorgeB

Do you have a monitor plugged in? If not using a VGA or HDMI dummy plug *might* help.

IPADDR="192.168.68.111" NETMASK="255.255.224.0" GATEWAY="192.168.681.1"  
Note that the gateway is wrong (x.x.681.x)

Start here:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173
 

Try clearing the browser cache and/or using a different browser, if that fails boot in safe mode.

Start here:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173
 

This.

Once there's corruption updating won't fix anything, but it should prevent more, run a scrub, if corrupt files are found they will be listed in the syslog, delete/replace them from backups.

Sep 19 23:36:23 Coruscant kernel: XFS (md7): Internal error rec.ir_free != frec->ir_free || rec.ir_freecount != frec->ir_freecount at line 1558 of file fs/xfs/libxfs/xfs_ialloc.c. Caller xfs_dialloc_ag_update_inobt+0xd0/0x121 [xfs]  
Check filesystem on disk7.

NIC problems:
 
Sep 22 02:16:58 Tower kernel: e1000 0000:03:01.0 eth0: Detected Tx Unit Hang Sep 22 02:16:58 Tower kernel: Tx Queue <0> Sep 22 02:16:58 Tower kernel: TDH <1000001> Sep 22 02:16:58 Tower kernel: TDT <1000001> Sep 22 02:16:58 Tower kernel: next_to_use <1> Sep 22 02:16:58 Tower kernel: next_to_clean <0> Sep 22 02:16:58 Tower kernel: buffer_info[next_to_clean] Sep 22 02:16:58 Tower kernel: time_stamp <fffbd99a> Sep 22 02:16:58 Tower kernel: next_to_watch <0> Sep 22 02:16:58 Tower kernel: jiffies <fffbe940> Sep 22 02:16:58 Tower kernel: next_to_watch.status <0> Sep 22 02:17:00 Tower kernel: e1000 0000:03:01.0 eth0: Detected Tx Unit Hang Sep 22 02:17:00 Tower kernel: Tx Queue <0> Sep 22 02:17:00 Tower kernel: TDH <1000001> Sep 22 02:17:00 Tower kernel: TDT <1000001> Sep 22 02:17:00 Tower kernel: next_to_use <1> Sep 22 02:17:00 Tower kernel: next_to_clean <0> Sep 22 02:17:00 Tower kernel: buffer_info[next_to_clean] Sep 22 02:17:00 Tower kernel: time_stamp <fffbd99a> Sep 22 02:17:00 Tower kernel: next_to_watch <0> Sep 22 02:17:00 Tower kernel: jiffies <fffbf140> Sep 22 02:17:00 Tower kernel: next_to_watch.status <0> Sep 22 02:17:01 Tower dhcpcd[1478]: br0: probing for an IPv4LL address Sep 22 02:17:02 Tower kernel: e1000 0000:03:01.0 eth0: Detected Tx Unit Hang Sep 22 02:17:02 Tower kernel: Tx Queue <0> Sep 22 02:17:02 Tower kernel: TDH <1000001> Sep 22 02:17:02 Tower kernel: TDT <1000001> Sep 22 02:17:02 Tower kernel: next_to_use <1> Sep 22 02:17:02 Tower kernel: next_to_clean <0> Sep 22 02:17:02 Tower kernel: buffer_info[next_to_clean] Sep 22 02:17:02 Tower kernel: time_stamp <fffbd99a> Sep 22 02:17:02 Tower kernel: next_to_watch <0> Sep 22 02:17:02 Tower kernel: jiffies <fffbf940> Sep 22 02:17:02 Tower kernel: next_to_watch.status <0> Sep 22 02:17:04 Tower kernel: ------------[ cut here ]------------ Sep 22 02:17:04 Tower kernel: NETDEV WATCHDOG: eth0 (e1000): transmit queue 0 timed out  
Do you have a different one you could try with?

Clear the browser cookies and try again.

Cache2 dropped offline:
 
Sep 14 04:40:02 Tower kernel: sd 2:0:0:0: [sdk] tag#22 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=0s Sep 14 04:40:02 Tower kernel: sd 2:0:0:0: [sdk] tag#22 CDB: opcode=0x2a 2a 00 00 00 08 80 00 00 08 00 Sep 14 04:40:02 Tower kernel: blk_update_request: I/O error, dev sdk, sector 2176 op 0x1:(WRITE) flags 0x3800 phys_seg 1 prio class 0 ### [PREVIOUS LINE REPEATED 1 TIMES] ### Sep 14 04:40:02 Tower kernel: BTRFS warning (device sdj1): lost page write due to IO error on /dev/sdk1 (-5)  
Check/replace cables and also see here for better pool monitoring.

Forgot to mention, you must run without -n or nothing will be done.

/mnt/user permissions are wrong, don't ask me why they work with v6.9, but they are still wrong, type
chmod 777 /mnt/user reboot and try again.

Yes.

It's logged as a disk problem but SMART looks mostly OK and the extended test passed, I would keep if for now, but any more errors on the next parity checks would recommend replacing.

Check fans and CPU temp, if the server shuts down vs crashing it's usually a hardware problem and not something easy to diag remotely, one thing you might want to confirm is that no shutdown command is being sent to Unraid, by for example a faulty power button, you can do that by enabling the syslog server and checking it or posting after the next shutdown.
 
P.S. next time please post the diagnostics.zip, not all the files inside it.

2TB 2.5" drives will be SMR, what brand/model? Some SMR models, particularity by Seagate performe decently, SMR drives by Toshiba or WD can have several minutes writing below 5MB/s, even when doing sequential writes.

Sep 19 12:25:53 Tower kernel: BTRFS error (device sdf1): block=2395218591744 write time tree block corruption detected This usually means bad RAM or other kernel memory corruption, Ryzen with overclocked RAM like you have is known to corrupt data, so you should fix that, then run memtest.
 
 
Sep 17 16:59:52 Tower kernel: macvlan_broadcast+0x10e/0x13c [macvlan] Sep 17 16:59:52 Tower kernel: macvlan_process_broadcast+0xf8/0x143 [macvlan] Unrelated, macvlan call traces are usually the result of having dockers with a custom IP address and will end up crashing the server, upgrading to v6.10 and switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), or see below for more info.

Seems related to the RAID controllers, make sure JBOD mode is enable and the disks are being passed through, Unraid isn't detecting those devices, like if they don't exist.

Disk3 looks OK, 13 mostly OK, run an extended SMART test on 13, both show several UDMA CRC errors so it could have been cable related.

System share has files on disk1, move them to cache, services must be disabled first.

They will be under /mnt/disks/UD_label, e.g. /mnt/disks/TV

Sorry posted the wrong link:
https://forums.unraid.net/bug-reports/stable-releases/6100-vnc-no-longer-connects-r1902/?do=findComment&comment=19127
 

With the array stopped set pool slots to 0, that will delete that pool.

Stop shaking reboot and the shares will come back.