JorgeB

Not really, but it's OK for powerline, with gigabit it should be around 300GB per hour.

Known issue of the MX500, disable monitoring that attribute:
 
 

Those are not recommended, avoid splitting a SATA plug into more than 2 plugs, Molex can usually be split into 4, but if possible also just 2.

I would suggest recreating the flash drive.

Try a new power cable, or swap with a different disk.

Diags are still not working correctly, so other things also may not, recreate the flash drive again, but this time don't restore anything from the backup initially, then see if the GUI works.

Yeah, that disk needs to be replaced, so you cannot rebuild disk3, but disk3 and parity look, so most likely they got disabled due to a power/connection error, I would try the following:
 
-Tools -> New Config -> Retain current configuration: All -> Apply
-Check all assignments are correct, unassign parity2 since that one is bad
-Check "parity is already valid" next to array start button and start the array
 
Disk3 should hopefully mount, if it does run a correcting parity check, if it doesn't, post new diags.

Something is causing the data corruption, and 9 times out of 10 it's RAM related, but it could be a different issue, after any change you make, scrub the pool, then reset the stats, and keep monitoring for more corruption errors, if new ones appear there's still a problem, more info below:
 
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=700582
 

That's normal, but the emulated disk is mounting now, look for a lost+found folder, if all look good get a new disk and rebuild.

Recreate de stock flash drive again, but then restore only the /config folder from the old one.

Jun 12 00:23:05 Tower kernel: SQUASHFS error: xz decompression failed, data probably corrupt Jun 12 00:23:05 Tower kernel: SQUASHFS error: Failed to read block 0x270a57c: -5 Jun 12 00:23:05 Tower kernel: SQUASHFS error: xz decompression failed, data probably corrupt Jun 12 00:23:05 Tower kernel: SQUASHFS error: Failed to read block 0x270a57c: -5  
These usually mean a flash drive problem, you can try redoing it, if the errors persist, you will need to replace it.

One of the disks is failing to identify:
 
Jun 18 18:31:10 Tower kernel: ata10.00: supports DRM functions and may not be fully accessible Jun 18 18:31:10 Tower kernel: ata10.00: ATA-9: WDC WD140EDGZ-11B1PA0, 85.00A85, max UDMA/133 Jun 18 18:31:10 Tower kernel: ata10.00: qc timeout after 5000 msecs (cmd 0xef) Jun 18 18:31:10 Tower kernel: ata10.00: failed to enable AA (error_mask=0x4) Jun 18 18:31:10 Tower kernel: ata10.00: 27344764928 sectors, multi 0: LBA48 ÿ� Jun 18 18:31:10 Tower kernel: ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jun 18 18:31:10 Tower kernel: ata10.00: supports DRM functions and may not be fully accessible Jun 18 18:31:10 Tower kernel: ata10.00: ATA-9: WDC WD140EDGZ-11B1PA0, 85.00A85, max UDMA/133 Jun 18 18:31:10 Tower kernel: ata10.00: qc timeout after 15000 msecs (cmd 0x2f) Jun 18 18:31:10 Tower kernel: ata10.00: Read log 0x00 page 0x00 failed, Emask 0x4 Jun 18 18:31:10 Tower kernel: ata10.00: NCQ Send/Recv Log not supported Jun 18 18:31:10 Tower kernel: ata10.00: Read log 0x00 page 0x00 failed, Emask 0x40 Jun 18 18:31:10 Tower kernel: ata10.00: 27344764928 sectors, multi 0: LBA48 NCQ (depth 32) Jun 18 18:31:10 Tower kernel: ata10.00: Security Log not supported Jun 18 18:31:10 Tower kernel: ata10.00: Features: NCQ-sndrcv Jun 18 18:31:10 Tower kernel: ata10.00: failed to set xfermode (err_mask=0x40) Jun 18 18:31:10 Tower kernel: ata10: limiting SATA link speed to 3.0 Gbps Jun 18 18:31:10 Tower kernel: ata10.00: limiting speed to UDMA/133:PIO3 Jun 18 18:31:10 Tower kernel: ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 320) Jun 18 18:31:10 Tower kernel: ata10.00: supports DRM functions and may not be fully accessible Jun 18 18:31:10 Tower kernel: ata10.00: qc timeout after 15000 msecs (cmd 0x2f) Jun 18 18:31:10 Tower kernel: ata10.00: Read log 0x13 page 0x00 failed, Emask 0x4 Jun 18 18:31:10 Tower kernel: ata10.00: Read log 0x00 page 0x00 failed, Emask 0x40 Jun 18 18:31:10 Tower kernel: ata10.00: NCQ Send/Recv Log not supported Jun 18 18:31:10 Tower kernel: ata10.00: Security Log not supported Jun 18 18:31:10 Tower kernel: ata10.00: failed to set xfermode (err_mask=0x40) Jun 18 18:31:10 Tower kernel: ata10.00: disable device  
Swap cables between both and see where the problem follows.

If you have/had any custom networks try recreating the docker image, since that will delete them.

I meant a degraded link, that can happen at anytime, try rebooting or using a different USB cables, but I'm afraid I cannot really help troubleshooting USB enclosures, and they can be a lost cause.

User shares can basically do that, main limitation is that a single file cannot span multiple disks, but if you really want a single volume, use a zfs pool.

This is likely the problem, do you remember where/how that device was formatted before?
 
As for the current issue, reboot, before array start wipe the SSD with
blkdiscard -f /dev/sdX start the array, and it should now format correctly.

The VM is what was killed, but immich/gunicorn was also using a lot of RAM, probably what is causing the issue, try running with tha disabled to confirm.

This is usually a plugin problem, make sure all plugins are up to date, especially the Connect plugin.

AFAIK yes.

xfs_repair is unbale to fix that filesystem, you can try a file recovery app like UFS Explorer.

Correct command is
 
xfs_repair -v /dev/md1p1 or use the check filesystem option in the GUI.

That's the most likely reason.
 
Everything goes through memory.
 
Definitely it's more at risk, but other thing can cause data corruption, though RAM is probably the biggest one.
 
Most likely it won't find anything.
 
I would just wait for the next scheduled one.

Check filesystem on disk7, run it without -n, also recommend running an extended SMART test, since SMART is showing some issues.

Difficult to say without starting to swap some parts, if you have multiple RAM sticks try with just one, if the the same try a different one, that will basically rule out the RAM

Jun 11 16:40:22 tank network: reload service: nginx Jun 12 04:02:06 tank webGUI: Successful login user root from 192.168.1.15  
These are the last two lines logged, suggesting it's not a server problem, when this happens again, see if the server still has internet connectivity, you can for example type in the CLI:
 
ping -c 4 google.com