Squid

Remove that xmod line you added to go and see if that makes a difference
 

No driver is being loaded.
 
6.8.3 is rather ancient.  Update to 6.9.2 or 6.10.0-rc4+ and see if that fixes it

2 possibilities can cause this:
Certain combinations of hardware will issue an mce upon processor initialization (probably related to firmware update) and can be safely ignored. Your wife has asked you to sweep the floors and you've lifted up the carpet and swept the dirt there. Under either scenario, you're safe (except for the wrath of a woman)

You have a docker container referencing "CamelCase" in it's path mappings

Disable mover logging in Settings - Scheduler
 
Also, generally the appdata share should be set to use cache: Prefer. 
 
Mover keeps trying to move it to the array (and the logs fill up because most of the files are in use)  You will get far far better performance by setting it to Prefer, running mover (with the entire docker service disabled in Settings Docker).  Use the appdata backup plugin to make weekly backups of it to the array

Post your diagnostics

If you're running 6.9.2, then you need to delete the /config/BTRS.key file
 
 

There's 1.3G which the containers have written directly into the image.  A bit on the high side, but still within the realm of possibility.  All in all I'd say just expand to 30G and not worry about it.

Delete it.  I'm not doing an exception for a backup of a backup

super.cfg is not a file which is used by the OS (it uses super.dat)  I'd just rename it to be an extension other than .cfg and check to make sure that nothing else was potentially using it.

This is the workaround here:
 
 

Reseat all the cabling to the drives at both ends.  

Try deleting /config/plugins/corefreq.plg from the flash drive and reboot
 
If that doesn't solve it, then try safe mode

the appdata share vs any other random share is simply a convention and nothing your particularly have to stick with  Change the default appdata location in settings - docker.  This will NOT however change anything already installed.
 
The docker image does not exist on the flash drive, so if you boot with another flash and the image location etc is the same, then your apps will all show up (but won't be editable etc without the applicable files on the flash drive.  This includes references to the icons (Admittedly, this is a scenario I never tested with the various changes to the way icons are handled). 
 
The docker image is very safe to delete (Settings - docker with the service disabled) and then recreate (via Apps - Previous Apps), assuming you did an actual backup of your original flash drive which had the templates stored on it.
 

Just an error from the controller basically stating "Huh! The drive was here and now it isn't"

By using Krusader, you are effectively bypassing the "system", resulting in this behaviour
 
The way that every OS in existence operates on a move is that first the file / folder is attempted to be renamed to the new location.  Only if it fails does the copy / delete process (physical move) take place.
 
Because Krusader is working from the single mount point (/mnt/), the rename will always succeed, resulting in files being location in apparent violation of the rules.
 
Options to avoid this is once 6.10-rc3 is released to install a File Manager plugin at the same time, or 2 do file operations via Windows and move between the shares, or map the shares to Krusader individually and move between those mounts

rename the file to be docker.img instead and try again.  I seem to recall an issue with that.

Which ever gets you back to 6.9.2 Alternatively you can always download the zip file from the webpage (downloads) and extract all of the bz* files from the zip and replace them on the flash drive and reboot.

Run the check filesystem against disk 5
 

https://unraid.net/contact

The error is quite simply that the particular file is corrupted.  Because of privacy, actual XML's are never going to be included in the diagnostics, so it can't be determined exactly why, but based upon the fact that you're actually running the OS, and the file names within the diagnostics appear to be OK, then hopefully that's your only issue.
 
The solution is to either edit the file to see what's wrong with it and fix it or simply delete it.  The interesting thing is that the file listed is ..../templates/zigbee2mqtt.xml  This means that you've added (in Docker - Template Repositories) another entry other than the default one to point to the author's repository.  With CA, this isn't necessary at all.  Your best bet is to remove that additional lines you've added in Template Repositories so that this issue won't re-occur on the next check for updates.  (The "corruption" could simply mean that whatever repository you've added has a syntax error in it, and isn't in fact "corrupt")

It did definitely drop.  If problems continue, transfer to another flash.  Sandisk FITs run hot due to their very small size

Some routers (including yours) try and be "helpful" by purposely attempting to hack into your devices on the network.  It can be disabled in the router's setting (don't know what it's called though)

Corruption on that file (docker.cfg) at the very least
LOCKER_ENABLED="yes" DOCKER_IMAGE_FILE= 'mnT.user/system/docker/docker.img" DOCKER_IMAGE_SIZE<b40" DOCOER_APP_CONFIG_PA]H="/mnt/user/appdata/" DOCKGR_QPP_UNRAA_PATH5"" DOCKER_CUSTOM_NETGORKS=" " DOCJER_TIMEOUT}"10# DOCKER_LOG_ROTAION="yes" DOCKER_LOÇ_SIZE="µ0m" ÄNCKER_LKG_FILES="1" DOCKER_AUTHOBING_MMDE=#no" DOCKER_USER_NETWORKS="remove"  
Restore the flash drive from a backup.  Or if none available, delete the file from the flash and reboot (it looks to be basically stock anyways)

/config/plugins/dynamix/dynamix.cfg on the flash drive