Squid

If nothing shows up in the logs for the container itself, then very hard to diagnose. Either post in the applicable support thread, or presumably you're using a container from dockerHub you found, double check your configuration of the template and read all the applicable information available.

The reason for this is because you're using a mapping of /data <--> /mnt/user The way every OS (including Unraid) works is that when moving a file, it first attempts to rename it to accomplish the move. In this case, you're attempting to move a file from /data/completed/... to /data/TV Shows/... Because both references are within /data (the same mount point), the rename will succeed. This has the result that the file never actually "moves" and may in fact be technically outside of the constraints imposed by included / excluded disks, the use cache settings etc. Your solution is to ether set TV shows share to be use cache:yes, or to go back and use separate references for the downloads and for the media share. I wouldn't consider the time it takes to physically move the file from the cache drive to the array as being "forever". If you've just spent the time to download a file, the extra time required to move it into it's final resting place shouldn't be a major issue.

Just a few comments on the ability to use a folder / share for docker If you're one of those users who continually has a problem with the docker image filling up, this is the solution, as the "image" will be able to expand (and shrink) to the size of the cache drive. Just be aware though that this new feature is technically experimental. (I have however been running this on an XFS formatted cache drive for a while now, and don't see any problems at all) I would recommend that you use a share that is dedicated to the docker files, and not a folder from another existing share (like system as show in the OP). My reasoning for this is that If you ever have a need to run the New Permissions tool against the share that you've placed the docker folder into, then that tool will cause the entire docker system to not run. The folder will have to be removed (via the command line), and then recreated. All of the folders contained within the docker folder are not compatible with being exported over SMB, and you cannot gain access to them that way. Using a separate share will also allow you to not export it without impacting the other shares' exporting. (And there are no "user-modifiable" files in there anyways. If you do need to modify a file within that folder, (ie: a config file for a container and that config isn't available within appdata), you should be doing it via going to the container's shell) You definitely want the share to be cache only (although cache prefer should probably be ok). Setting it to cache:yes will undoubtedly cause you problems if mover winds up relocating files to the array for you. On this beta (until the GUI properly supports this new feature), you also cannot use Settings - Docker to stop / start the service if you've made the change to the .cfg file to utilize this feature. (You can stop the service, but in order to restart it you have to enable it via the config file and then stop / start the array) I did have some "weirdness" with using a Unassigned Device as the drive for the docker folder. This may however been a glitch in my system. Fix Common Problems (and the Docker Safe New Permissions Tool) will wind up getting updated (once the GUI properly supports these changes) to let you know of any problems that it detects with how you've configured the folder.

From the 6.8 announcement

Delete the /config/ssl folder on the flash drive and reboot. It'll get recreated

Does the path (and the folder isos) actually exist?

Certain combinations of cpu's / motherboards/ microcode (or if you live on a farm an impending Locust invasion) will issue an MCE when the system is initializing the cores. Perfectly normal and can be safely ignored.

From the terminal on the GUI, enter in diagnostics It'll get saved to the flash drive in the logs folder. Post the entire zip file on your next post

Everything now implies problems with the flash drive, especially plugins disappearing.

It never does 2 moves at the same time. As already explained, it's simply the write-caching of the system as a whole. But, the reason for the delay is that when it also has to switch between drives, then read operations also take effect (to gather directory information, etc). At this point, the system also switches from reconstruct write down to read/modify/write mode (by design) and that impacts your speeds. It takes a bit for it to switch back to reconstruct write mode, and depending upon file sizes, how much gets cached to ram, speed of the drives and how often the system actually has to switch from drive to drive, you may see a huge impact in transfer speeds. As your screenshot shows, the system is currently in read/modify/write mode.

To gain access to the flash drive, simply use Windows explorer and navigate to your server and go to the "Flash" network share. If it's not there then it's not exported, and you can do that via Main, Boot Device, Click on Flash, and then SMB Security Options

Have you turned off the XMP profile for the memory? XMP is an overclock. You pretty much always want to run at SPD speeds. Also (even though you've already ruled this out), the road to stable servers dictates matching memory modules. If it's impossible to match the memory, then the most stable configuration with mismatched sets is when they all have the same CAS latency.

Mover Tuning Plugin

Post your docker run command https://forums.unraid.net/topic/57181-docker-faq/#comment-564345

One possibility is that any Windows VM was preventing the VM from shutting down (ie: you haven't saved your work, it was doing updates etc). Always best practice to install the virtio-client in Windows and within VM settings have it hibernate VMs instead of shutting down.

Only manually via the "tar" command

Not particularly helpful, and without diagnostics and what browser you're using there's not much anyone can do to help.

Certainly looks like a bad ram stick

The flash is set up to boot non EFI by default. IIRC there's a checkbox in the USB creator for that.

Did you set up the flash drive as "EFI"? (Or simply rename the folder on the flash from EFI~ to be EFI)

It took ~2 hours to do the backup. It'll take at least another 2 hours to verify the backup.

That snip shows that it's still verifying. Until that's done, it won't restart the apps. Personally, I find it pointless to verify the backup as there's so much redundancy built into Unraid and any given hardware that you'll know if a write fails via other methods.

Unraid (with a single parity drive) is somewhat akin to RAID-4 but without the striping of the data. Pros and cons for it's approach, but IMO the pros far exceed the cons.

That change? I could've sworn they did

8 All storage devices (hard drives, DVD-R's, flash drives (excluding the boot device) count.