Squid

I thought the same thing at first, and decided that *maybe* the user could want different isolated CPUs depending upon how they boot. That, and generally once you decided on a boot mode you're pretty much never going to switch.

The disk at the time you grabbed the picture IS at 45C according to its own SMART report (personally, this is hotter than I like). And it HAS hit 53C. The yellow triangle's threshold for temperature is configurable via disk settings (disk temperature threshold), or individually per disk.

That warning from FCP is meant for non-developers

Already a PR in place for this https://github.com/limetech/webgui/pull/381 The page still works (with the errors). The errors are from not already having any isolated CPUs in the first place.

There's something weird going on with your system. Go to Update OS, and then post your diagnostics. It doesn't look like its getting to the internet at all.

Someone would have to run something like Plex (ugh) pinned to a single core, and maxing itself out on a transcode to see what the CPU % returned by docker stats is. My guess would be that docker stats does not take into consideration pinned cores.. (IE: it would return 100% on a single core. Pinned to 2 cores maxed out I'm guessing it would return 200%) Only a guess though

Manually is by clicking the icon for it. No other way than that. Does the Update Assistant recognize that "Next Branch" is RC-2?

Same result. Over 100% is still possible, until someone decides whether to divide the stats returned by docker either by number of pinned cores or my preference, the number of cores present

This will happen if for some reason your flash drive dropped offline. But, you should also have another error regarding that.

Just a couple of comments on the last couple updates to FCP and unRaid 6.6 --cpuset-cpus is deprecated on extra parameters (docker applications) in unRaid 6.6 While the option still works, it is highly recommended to instead utilize the CPU pinning option when editing the application, as unexpected results (both in the GUI and when running the container) may happen if still utilizing --cpuset-cpus, especially if utilizing both the GUI and the extra parameters option. This is flagged as an error unRaid 6.6 (rc2+) now also allows you to isolate CPUs instead of manually editing the syslinux.cfg file. FCP will flag as an error if you pin a docker application to multiple isolated CPUs. Long technical explanation, but this will not give you the results you may be expecting (unless you know exactly what you're doing). Pinning a docker app to a single isolated core however will give you the expected results. This is flagged as an error

Assuming your other apps are from LSIO, they were actually updated August 31st.

You do have to Check For Updates or have it do that on a schedule, or have CA AutoUpdate installed to install for you automatically. It's not that "once it hits the repository"

@bonienl Can you add in to autofan an option to disable logging (preferably disabled by default). Don't think it's really necessary to have it spam logs every 5 minutes with this Sep 7 06:46:55 tidehunter autofan: Highest disk temp is 35C, adjusting fan speed from: 163 (63% @ 1060rpm) to: OFF (0% @ 235rpm) Sep 7 06:52:00 tidehunter autofan: Highest disk temp is 41C, adjusting fan speed from: OFF (0% @ 0rpm) to: 163 (63% @ 1062rpm) Sep 7 06:57:05 tidehunter autofan: Highest disk temp is 35C, adjusting fan speed from: 163 (63% @ 1066rpm) to: OFF (0% @ 202rpm) Sep 7 07:02:11 tidehunter autofan: Highest disk temp is 41C, adjusting fan speed from: OFF (0% @ 0rpm) to: 163 (63% @ 1051rpm) Sep 7 07:07:16 tidehunter autofan: Highest disk temp is 35C, adjusting fan speed from: 163 (63% @ 1073rpm) to: OFF (0% @ 218rpm) Sep 7 07:12:21 tidehunter autofan: Highest disk temp is 41C, adjusting fan speed from: OFF (0% @ 0rpm) to: 163 (63% @ 1057rpm) Sep 7 07:17:26 tidehunter autofan: Highest disk temp is 35C, adjusting fan speed from: 163 (63% @ 1065rpm) to: OFF (0% @ 200rpm) Sep 7 07:22:32 tidehunter autofan: Highest disk temp is 41C, adjusting fan speed from: OFF (0% @ 0rpm) to: 163 (63% @ 1047rpm) Sep 7 07:27:37 tidehunter autofan: Highest disk temp is 36C, adjusting fan speed from: 163 (63% @ 1065rpm) to: 48 (18% @ 368rpm) Sep 7 07:32:42 tidehunter autofan: Highest disk temp is 41C, adjusting fan speed from: 48 (18% @ 334rpm) to: 163 (63% @ 1056rpm) Sep 7 07:37:47 tidehunter autofan: Highest disk temp is 35C, adjusting fan speed from: 163 (63% @ 1061rpm) to: OFF (0% @ 207rpm) Sep 7 07:42:52 tidehunter autofan: Highest disk temp is 41C, adjusting fan speed from: OFF (0% @ 0rpm) to: 163 (63% @ 1055rpm) Sep 7 07:47:58 tidehunter autofan: Highest disk temp is 35C, adjusting fan speed from: 163 (63% @ 1064rpm) to: OFF (0% @ 226rpm) Sep 7 07:53:03 tidehunter autofan: Highest disk temp is 41C, adjusting fan speed from: OFF (0% @ 0rpm) to: 163 (63% @ 1053rpm) Sep 7 07:58:08 tidehunter autofan: Highest disk temp is 35C, adjusting fan speed from: 163 (63% @ 1069rpm) to: OFF (0% @ 214rpm) Sep 7 08:03:13 tidehunter autofan: Highest disk temp is 41C, adjusting fan speed from: OFF (0% @ 0rpm) to: 163 (63% @ 1053rpm) Sep 7 08:08:19 tidehunter autofan: Highest disk temp is 35C, adjusting fan speed from: 163 (63% @ 1072rpm) to: OFF (0% @ 201rpm) Sep 7 08:13:24 tidehunter autofan: Highest disk temp is 41C, adjusting fan speed from: OFF (0% @ 0rpm) to: 163 (63% @ 1049rpm) Sep 7 08:18:29 tidehunter autofan: Highest disk temp is 36C, adjusting fan speed from: 163 (63% @ 1072rpm) to: 48 (18% @ 347rpm) Sep 7 08:23:34 tidehunter autofan: Highest disk temp is 40C, adjusting fan speed from: 48 (18% @ 333rpm) to: 140 (54% @ 934rpm) Sep 7 08:28:39 tidehunter autofan: Highest disk temp is 37C, adjusting fan speed from: 140 (54% @ 938rpm) to: 71 (27% @ 518rpm) Sep 7 08:33:45 tidehunter autofan: Highest disk temp is 39C, adjusting fan speed from: 71 (27% @ 513rpm) to: 117 (45% @ 807rpm)

Barring any further details (which @bonienl) asked for, I see two possibilities You're in Template Authoring Mode and hitting Save. All that does is bring up an XML for you to then copy/paste into a file of your choosing as part of creating your own template for publishing You're in Docker Repositories, and are attempting to add another repository in addition to the built-in one from Limetech. Formatting on the repos listed is important, and if its wrong, it won't work correctly. But, since you do have CA installed, there is fundamentally zero reason to ever go to the Docker Repositories tab.

ep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application binhex-rtorrentvpn is missing. Sep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application CrashPlanPRO is missing. Sep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application duckdns is missing. Sep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application jackett is missing. Sep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application lidarr is missing. Sep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application plex is missing. Sep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application Radarr is missing. Sep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application RadarrPublic is missing. Sep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application Sia is missing. Sep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application Sonarr is missing. Sep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application SonarrPublic is missing. Sep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application StorjMonitor is missing. Sep 7 09:24:58 tidehunter root: Fix Common Problems: Warning: Template URL for docker application tautulli is missing. The entire contents of /config/plugins/dockerMan/templates-user does not exist on the flash drive. This is where the docker system has to get things like the webUI from (and it would stop FCP from complaining) Do you have a backup of the flash drive?

Edit /boot/config/go and add the appropriate line, or install the User Scripts plugin and create a script that does the same thing set to run at first array start

Try it again. The txz is 100% not corrupt on GitHub's end. Nice little issue though on unRaid's OS where the install of the txz failed, but it carried on with the other install scripts in the downloaded .plg anyways. You *may* have to reboot. There is a chance because as far as unRaid is concerned the plugin install was successful even though it obviously isn't that the plugin system may be in a weird state of flux.

Its not the fault of the plugin. Unless of course you are running a script that is doing something causing that.

That was more or less my point. CA never timed out, but rather the GUI hit it's hard limit of 120 seconds on any request at which point the GUI will not return a result for the request (success or failure) What containers are you running?

Its a @bonienl question, if he missed this thread.

The unRaid UI has a 120 second time out. When you hit the docker tab, this happened Sep 4 22:44:28 HomeServer nginx: 2018/09/04 22:44:28 [error] 14423#14423: *321832 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.126, server: , request: "GET /plugins/dynamix.docker.manager/include/DockerContainers.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "1422ea8d47b47bc6e9dc7b17038a996b4f72ed75.unraid.net", referrer: "https://hash.unraid.net/Docker" Along with the Dashboard (This one happened first) Sep 4 19:55:31 HomeServer nginx: 2018/09/04 19:55:31 [error] 14423#14423: *296165 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.126, server: , request: "POST /webGui/include/DashboardApps.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "1422ea8d47b47bc6e9dc7b17038a996b4f72ed75.unraid.net", referrer: "https://hash.unraid.net/Dashboard" The same thing happened when you hit the apps tab Sep 4 22:59:32 HomeServer nginx: 2018/09/04 22:59:32 [error] 14423#14423: *324436 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.126, server: , request: "POST /plugins/community.applications/include/exec.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "homeserver.local", referrer: "https://homeserver.local/Apps" CA times out on any particular download after 45 seconds, so in *theory* you should not have seen the timeout from CA. *in theory* Very hard situation for me to replicate, and try to alleviate. As far as CA is concerned, I can tell you that if the initial popup regarding "Downloading New App List" doesn't disappear within 120 seconds (which it should within max ~90 seconds, usually 1 second), it will never disappear. But, if you wait a couple min, and then go into the Apps tab, everything *should* be good to go. Major Wild Guess: Is it possible that it was your browser that crashed and was unresponsive? Closing the browser, and going back to the server's UI does that fix the problem? There's no real reason that I see for the problems that you've seen beyond that.

Check in Network Settings that your gateway is set to the IP address of your router. Also wouldn't hurt to give the DNS servers a static IP of 8.8.8.8 and 8.8.4.4

An easy test is to remove the image via Docker (make sure that delete image is checked off), then reinstall via Apps -> Previous apps. All your appdata will still be there.

Can you try to enable VMs and then post another diagnostics