Squid

It appears that you've got a poor connection to one or more of the drives attached to your HBA. Reseat power / sata to the drives (they keep resetting). Also, disable Mover Logging within Settings - Scheduler - Mover. It serves no real function unless you've got issues. And, not sure (or at least not what I would do) why you have your downloads share set to user cache:yes. Slows everything down as it'll keep moving from the cache drive to the array, and IMO is pointless. Set it to Use cache: prefer so that it'll tend to stay on the cache drive, and only use the array for an overflow.

Top of my head, your memory is very fragmented and the VM is unable to allocate what it needs. A reboot should fix it, but you might want to consider limiting the memory available for Duplicati (I would think that it's a pig on resource usage)

Its starting, so any further problems you need to post within its support thread as it's now application specific

It started no problems. What's happening is a template error by @Jidovu Marius Adrian. Edit the container, switch to Advanced View in the top right and on the Web-UI line change it from http://[IP]:[PORT:9000] to instead be http://[IP]:[PORT:8080] The webUI on the context menu should then work.

The usual (and recommended solution) is to NOT have any downloads from SAB be stored within the docker.img file. 1.5TB is WAY overkill, and for the vast majority of people, 20GB is more than sufficient. A few entries in the Docker FAQ about the image becoming full Might not be a bad idea to post your diagnostics

Post your docker run command. See the first recommended post in the Docker FAQ thread.

Share the drive / folder within the VM. Within Unassigned devices, add a new SMB share

Yeah, I seem to recall that. Haven't used Plex forever as it sucks locally, and long ago switched to Jellyfin. Can't remember if the change in behaviour was due to an update in Plex (IMO, required as it was effectively streaming your media to them and then disseminating it to the clients) or if it's because of a change in active streams to disregard it.

On the add / edit screen for the template, you can simply type in the appropriate port you want to use (all assuming you're on bridge mode). If you do decide to hit the edit button, only change the HOST port. This is from one of my apps (cops). It is set for its webUI to be on port 807.

Create a new trial key for the new system. After everythings all done, use the existing key (and reassign the drives accordingly), or transfer the licence from the old to the trial.

Yeah, but that's not a "backup" because that's not how you normally run the appdata share, and in your first scenario you wouldn't have the opportunity to do that since your cache "died"

Within Settings - Scheduler - Mover Settings, you can enable Mover logging to determine what's going on. Then you can post your diagnostics with a note about what share you're playing around with.

Try installing the nVidia or unRaid DVB plugin. Via it you can also upgrade to stock OS. Not 100% sure though what servers they use for hosting though.

And it always will say that because internally the app is using port 8080, but the docker system will accept the connections on port 8090 (assuming you're using bridge mode) and forward it to the app on it's port 8080. A vast number of apps all use port 8080 internally and can be run simultaneously no problems doing exactly what you've done. BUT, if you've change the container port via the EDIT button, then you've messed around with the whole system and it won't work. You just need to change the HOST port and leave everything else alone.

To just get the system running again, just take a backup of the flash drive (for safety sake), rebuild the system, and boot normally with the existing flash. Should be no problems except that it will complain that your parity drives are wrong. Assign them appropriately and start the array. The VM (especially since you're presumably using passthrough) will take some more work.

Works for me. It is however way at the bottom on the right.

I *think* its completely safe to cancel the parity check. It did appear that everything was unmounted correctly.

Also, while it's not necessarily your problem, but the utmost in stability in any computer system comes when using matching memory sticks (which you're not). If you do have to mix and match between manufacturers (which you are), then try and ensure that the CL spec on them match (which yours don't). It's not a given, but it is a distinct possibility.

First thoughts are power problems or bad memory. Have you run a memtest for a couple of passes recently from the boot menu?

presumably its just going through the appdata share for plex which can potentially contain hundreds of thousands of files and can take quite a while to get through (and no disk activity means that it's checking it via the cached file structure.) One user IIRC had it finally complete after 24 odd hours. I wouldn't worry about it. You'll be notified whenever it completes. It won't cause any issues while it does it's thing.

Certain combinations of cpus / motherboards / poltergeists deciding to just hang out issue an MCE when initializing the processor during boot up. This is what's happening to you, and is normal (assuming the poltergeists weren't involved) and can be safely ignored.

Just reboot. I think the problem is that the virtual drives of yours keep getting reattached. IE: I can't really think of any other solution right now other than to bite the bullet.