Squid

It installs a different version if you're over 6.4...

Not quite sure I'm following exactly what the problem you're having is.

You must've picked that up off of today's avatar. While Polish, today I treat simply as an excuse to be able to throw a water balloon at my wife and (hopefully) get away with it

It is. But that won't change the fact that the system and your plugins are still using up the memory. 2G is the bare minimum required for unRaid. 4G is the functional minimum.

Disable SSL?

You have a docker container that is referencing (probably it's /config appdata path) /mnt/cache instead of /mnt/diskX or /mnt/user This is creating the appdata for the container in RAM, and since /mnt/cache exists, FCP is running that test. You're going to wind up with other issues until you change that (besides the fact that whatever container is doing this, it's appdata will get lost on every reboot of the server)

Not really. It will take noticeably longer to back up with it enabled.

You'll have to do the manual method. Download the 6.8 zip file from limetech's website, and extract all of the bz* files within the archive onto your flash drive.

Pull the stick. Check for corruption on a windows box (check disk). If need be, re-run Make_bootable.bat (it's in the root of the flash) as administrator and try again.

In a nutshell, just go for the upgrade. Review this thread though https://forums.unraid.net/topic/66327-unraid-os-version-650-stable-release-update-notes/ You will not lose any data.

And then ask Microsoft to actually use the correct unit. This is their issue.

With most BIOS, you set the boot order so that the hard drive is the first (and ideally, the only) boot device, and under the hard drive priority, you select the flash drive as the hard drive (select the "normal" flash drive, not the UEFI one)

/config on the flash drive

Yes. If you've put the drives into the same positions as the above, then you can check off Parity is already valid. If you have moved them around, then you have to rebuild parity. Either way, you should run a parity check.

Assign it as a data drive. If it comes up as unmountable, then it was your parity drive. The reassign it as parity. These were your assignments when you last posted a diagnostics (Dec 2018) Only you would know if this is still valid. Note that your parity was assigned as parity 2, not parity. There is a difference.

cAdvisor does resolve them to the containers. I guess you would have to investigate the docker command reference to figure that one out.

The names are dynamic and change from start to start of the containers

I have no idea what you're using there, so you're better off than me there. Since the drive isn't readable under normal means at all, I'd go with Create a new drive Contact Limetech (https://unraid.net/contact) to recover your licence. In the meantime, you can set the stick up as a trial. You're going to have to reassign your drives. If you don't know what was what, then assign everything as data drive. Whatever comes up as unmountable was your parity drive(s). If you have more than 1 unmountable drive and were only working from a single parity drive then stop and ask here for more help. The docker containers already installed will be up and running as-is. You will not however be able to "edit" them or hit the webUI from the context menu. The data the system needs for that is on the flash drive. Any chance you have a backup of the flash drive or were running the appdata plugin?

There is no filesystem on the parity drive at all, so nothing to defrag.

You can try running a file system check on it within any of those OS's. But if you can't gain access, you can't gain access. You will not lose data on the array if you can't.

You can get a preview by installing the vfio cfg plugin. Probably no where near what the final version is, but it'll get the point across

Disk 1 you should really consider replacing 5 Reallocated_Sector_Ct PO--CK 095 095 036 - 228 Your unassigned drive is sitting on the fence as to whether or not to replace 5 Reallocated_Sector_Ct PO--CK 099 099 036 - 50

Drive labels don't matter, and even if you don't switch hardware, they aren't guaranteed to stay the same from one boot to another. IE: unRaid doesn't care Same thing with the ports. unRaid only cares if you switch from a controller to an actual RAID controller (ie: IR mode) as the drive serial numbers will change at that point.

It's an annoyance more than anything, but unfortunately not a bug but a design choice. But I've never actually had any noticeable performance hits from Most Free and read/write/modify modes. I never would have noticed this behaviour had I not been transferring back and forth terabytes of information back and forth between 2 servers. Tried everything to mitigate it and the solution was to switch to highwater to avoid the overlapping reads at the end of a file. Unless your drives all have the same amount of free space and you're transferring over a lot of information you may never even notice the degradation. But, under the circumstances I had, once it switched to read/write/modify it tended to stay there all the time (90%+ of the time) with a huge hit to the performance that was very noticeable.