Squid

What @trurl stated. But, the reason why I wanted to see the diagnostics is that there's a likely scenario (couple of them actually), but one of them is quite easy to fix and to catch. If you have Fix Common Problems installed, then go to Tools - Update Assistant. It explicitly looks for the most like scenario on the VM page not starting as part of upgrading (depending upon which version of unRaid you upgraded from) - Just make sure that VM's are enabled prior to running the Assistant.

What I would do: On the flash drive, delete /config/plugins/community.applications and /config/plugins/community.applications.plg Highly recommended to upgrade the OS to 6.5.3 (Tools - Update OS) Reboot the server, and reinstall CA. Grab a screenshot of the popup when its done (just in case) See if the Apps tab is there once you hit done and reload the page If its not, post the screenshot. Should've been the first

Diagnostics

Almost sounds like the database is being stored on the array, and the drive(s) are spun down Sent from my LG-D852 using Tapatalk

Probably the best place to peruse for a question like that is the Plex project pages.

You can also try stubbing the controller card in syslinux https://forums.unraid.net/topic/50288-basic-questions-about-stubbing/

The only limitation is that if you access the server via HTTPS then all external pages have to be HTTPS

Doesn't matter to me, but I would think that the Docker Page is simply a rough tool to determine the CPU usage of the container (in which case it is divided by number of cores). If you want actual details, then you should be hitting NetData or even cAdvisor

But then the next post / defect report will be about why is the total CPU percentage (adding up the column) go over 100%?

Really. I always thought that Plex was their only exception, mainly due to Plex's release schedule of a new version every 2 minutes, and the inane need for Plex users to insist on always being on the latest buggy version.

All relevant configs for you scenario's are on the flash drive.

LSIO's weekly updates (Friday @23:00 GMT) on all their containers (with the exception of Plex) updates the application to the latest version (if one is available), applies any security CVE's etc to the base image, etc. Its all automated, so you're not going to find a changelog per se.

Not that the display is correct, but the CPU load being reported is identical to docker stats which means that the % needs to actually be divided by the number of cores in the system to get a value from 0-100

Is your gateway set correctly? Alternatively, github could be blocked from your physical location (Iran / China maybe). You can always forgo pfSense as a test and see how things work without that complication and then work backwards.

Unless you're changing the motherboard or something like that, downtime would usually be in minutes (time to change a harddrive / add memory, reboot, etc)

Can't be done. Couple of feature requests already for this, but thus far nothing has come of it. Probably due to underlying complications.

Prior behavior on the Update Assistant was that it checked for a version of dynamix.plg with a file time before Jan 1, 2016 and told you to delete them (since latter versions checked on the OS version prior to installing). Since there's some bug or something in the version check on some of dynamix.plg, Update Assistant now will always tell you to delete dynamix.plg no matter the time stamp.

It's not that there's a correct way to do it. It's all how you want to do it. Myself I don't see why you need to have separate IPs for my use case. Yours may be different if you are trying to limit bandwidth via pfsense Sent from my LG-D852 using Tapatalk

Couple of times I've seen you post this. Is there a problem that say my Update Assistant should look for? Since he was coming from 6.5.3, I thought that an old version of dynamix.plg shouldn't attempt to load since it checked for OS versions. (Only really ancient versions didn't check the OS version)

Could be wrong (usually am), but isn't he assigning the container to a specific IP, which implies it now runs in HOST mode, and ports are unaffected? If you need to change the ports the app runs on, then switch the network mode back to bridge, which will allow you to change the host side. What you've got is the app running on a separate IP address which means that it's port settings are law, and cannot be changed (ie: change the environment variables you've changed for port settings back to their default values). TLDR: When assigning a container to a specific IP, you cannot change the port assignments

As best it can. It's not like it can read the directions or anything. If the container author included the various environment variables, paths, etc within the dockerfile, then it should properly fill out the template (minus any help text like what you posted above), and certain assumptions are made about network type, webUI port etc which is impossible to determine, and may or may not be correct. But, there is zero requirement that the dockerfile contains that information within it, and no matter what you still have to read the docs on the dockerhub page for the container - Hence why its an option in CA that the user has to specifically enable and then have another click in order to display the results from dockerHub

Close enough:

Not sure. Maybe post your diagnostics during the same period a backup attempted to occur

You got it. Except that the VM Manager setting for Hibernate won't actually do anything unless Guest Agent is installed.

It creates it itself by either downloading the dockerfile or scraping the docker page if it can't locate the dockerfile for as much relevant information as it can find