Squid

Here's one issue.  Not quite sure if it'll affect it or not
 
From your Global Share Settings, 
shareUserInclude="disk2" shareUserExclude="disk2" You're telling the system that user shares should only be put onto disk 2 and you're at the same time telling it that user shares should never go onto disk 2
 
So where are they supposed to go?  Fix Common Problems should have been telling you about that.  Only ever use include or exclude, never both as they are opposites of each other with it never being necessary to specify both.
 
Fix that, reboot and post a new set if problems continue
 
 

It would sound like the flash itself is pooched (unless there's a physical write-protect switch on it).  I would transfer the registration https://wiki.unraid.net/Manual/Changing_The_Flash_Device

You're being bombed with advertisements for IPv6 addresses from DHCP.  Don't know why, but wondering if static addresses being assigned won't help

Odds on you slightly wiggled the cabling to the other drive...  No one ever in the world has ever said sata is a good connector (or the phrase "as pretty as an airport")
 
Reseat the cabling and start over again.
 
 

Perhaps the mover tuning plugin has the ability to selectively move based upon file type.  Not quite sure.  The base OS makes no provisions for this.

The share named "D.......s"?
 
# Generated settings: shareComment="" shareInclude="disk2" shareExclude="" At some point you had a disk 2 in the system, set the share to only use that drive.
 
Go to the share settings and reset that setting to disk 1 (or ideally all)

Yes, a 20GB docker image is the default set up.
 
It's the actual applications (or in Windows terms it's what's stored within c:/ProgramFiles).  In terms of what an "image" actually is, think of an ISO that you mount on Windows that you can read and write to.
Yes.  (Although this is configurable by you in changing the /config path mapping -> hidden option on most apps).  In terms of Windows it's somewhat akin to C:/ProgramData
 
 
The beauty of how Unraid, docker, and the Apps tab handles things is that at any given random point in time it's 100% safe (in the vast majority of cases) to recreate the docker image file, as it only stores the executables for the apps (Plex) itself.  Everything else is stored in appdata (which is untouched by the process), so after recreating it (and reinstalling from Apps - Previous Apps) it's all back the exact same way as it was originally, with no configuration changes on your part at all.  On average I redo my docker image about once every 3 months.  Not because there's any problems with it, but rather to ensure that the Apps tab works properly in this fundamental feature of it.
It really is.  Stop the service, delete the image, re-enable the service, followed by Apps - Previous Apps.  Use the check boxes and then hit Install at the bottom.  (If you've experimented with multiple plex containers, there may be more than 1 listed, but only check off what you were actually using (you can delete the ones you weren't using).  
 
Total its a couple of clicks and the speed of your internet.  But, you may be correct and I understated the time.  Call it the amount of time to start the process and then grab a coffee and return.
 
My opinion is yes. 
The docker container is part of the docker image.  Terminology is always a difficult thing.  As an example, I try and force myself to refer to everything as an "App" because it makes more sense to everyone with a cell-phone, but the correct term is "container", and sometimes I will bounce back and forth between the two without noticing.
 
Yes.  You tell Plex that your media library is at /data  Similarly, you tell Plex in it's settings that your temporary transcode directory is at /transcode
 
The concept of mappings, containers etc throws everyone for a loop.  It is also paradoxically concepts that once you understand it it's hard to explain everything.  This is a good video however.
 
 

It *appears* that the docker image is completely empty.  Apps - Previous Apps, check off everything you want and hit install.
 
I see that you're currently restoring the appdata.  While it's not a problem to store the docker.img within appdata (usually it's stored within system), it is 100% excluded from the backup set because its just too easy to simply recreate it.
 
Can he hit the mediashare via \\192.168.50.217\Media ?

At the time of the OOM, nano was open and was consuming ~15Gig.  Quite possible you opened the wrong file and then did the correct one, but it was the cause of the OOM

It *appears* that the flash is actually failing.  Nothing but critical medium errors throughout the logs.  Doesn't appear to have ever dropped offline, so changing ports isn't going to do anything for you.
 
I've never been a fan of any super super small flash device like the Ultra Fit's.   They are USB3 (run hot), and a very small form factor (run hot).  Run hot + run hot = very hot
 
I'd replace it (but avoid SanDisk as there are now a ton of counterfeits making the rounds)
 

Shouldn't make a difference.  Ensure that disk down down is still set correctly (change it to 30, then reset it back to 15 and hit apply)
 
Failing all else, post your diagnostics

The share system does not support that.  It will support separate shares with varying permissions for the users on them.

A rebuild doesn't care if the drive is empty or if it's full.  It's simply a sector by sector calculation needed to recreate the drive.  
 
The alternative to a rebuild of the drive is to do a New Config and assign the drives appropriately, but in that case the parity needs to be rebuilt to reflect the actual sector contents of the drive in question.
 
IE:  No real way around the rebuild.

Yeah, you've got physical 2 nics, but 3 are listed in the config (must be a ghost from a previous configuration or something)
 
I've only got 1 (and no easy method for adding another without destroying the WAF while she's watching movies), but you can try making a change to Network settings and reverting it and finally applying to fix you up.
 
Worst case you delete those 2 files and reconfigure accordingly.

Settings - Management Settings, use SSL to be either Auto or Yes and get a certificate via the button at the bottom.
 
Browsers automatically append :80 as it's the default if you don't specify a port.  If you've changed it, append the port

Both your shares screenshot and the diagnostics show that the system isn't what the individual shares may say.  (They may be showing that because there is no "cache" drive and that's what it's defaulting to).  Make a change (any change) and revert it then apply and the continue with my directions.
 
And yes by disable all services I mean to disable the docker service, disable the VM service in settings, not just stop the individual apps.  appdata for sure contains files on the array due to how this was working for you and it is going to significantly affect your performance.

Nothing to worry about.  Related to a current issue under active investigation / resolution by the MyServers team

Anything outside of the array is a "Cache Pool".  Previously you would accomplish something like what you want via mounting the drive in Unassigned Devices.  But, it's easier to let the OS itself manage it as a cache pool.
 
No physical disconnecting is required.  You're just rearranging how the system thinks the drives are assigned.
 
Your new config allows you to remove the drive from the array (parity will need to be rebuilt).  And you hit add pool to add another cache pool that is specific to the security drive.
 
Writes etc to that drive won't involve parity at all, and you can still access it via the user shares, so no adjustment to any VM's or Docker containers is required.  Just the shares that exist on that drive you set to be "Cache Only" and to use that new cache pool.

It's something with the script that he's got running to set stuff up.  No idea.  Post in the support thread.

sdd (disk 1) seems to have connection problems and is suffering from device resets slowing everything down.  Reseat the cabling

Look in your download client for an option to set permissions (advanced view?)  Then change it to 0777

Can't see where it all started, but a ton of write errors to the cache pool.  But, the one drive (...3042) isn't showing as being online in the SMART reports, so you might want to check cabling etc (or maybe it just died). 
 
@JorgeB will be able to assist in any recovery operation

Does your VM's attached monitor (you're obviously doing a GPU passthrough) normally display the bootup sequence from the BIOS of the server itself?
 
Since you had to go into the BIOS to set the date and time, it implies your battery (probably a CR2032) is shot and the primary GPU you're using for the server (I'm assuming you have 2 -> one for passthrough, and the other (iGPU / cheapie card) is used for Unraid.  You've got to set the primary video card to be iGPU / el cheapie.  Then we'll be able to make some more progress

My first thought when I did the text was "FIRE FIRE FIRE BEES!", but decided to settle on what is there now.
 
Surprisingly, the webGUI itself (and the underlying emhttp) required memory, none was available so Linux killed off some Plex on Jan 3 (which was based upon what it needed / was last used was the best candidate).  Looks like you possibly noticed that and restarted the array since
 
Currently, nothing is any unusual amount of memory so its possible that on 1/3 something was just going nuts (without really diving into every file) with download / transcoding to RAM, etc etc.  
 
Suffice it to say that the system operated as intended and killed off what was required for it to stay running as the linux programmers designed.  It doesn't appear to be a common issue for you, so you're probably going to be safe from the bees (or anaphylactic shock)