Squid

Due to a change over at docker, unRaid always sees that there's an update available whenever you check for updates. See bug report and fix within the thread https://forums.unraid.net/bug-reports/stable-releases/dockers-wanting-to-update-but-dont-in-the-end-r618/

Sep 7 13:09:07 Tower root: Fix Common Problems: Warning: Dynamix SSD Trim Plugin Not installed Easy fix. Install the plugin. Your SSD will thank you. Sep 7 13:09:04 Tower root: Fix Common Problems: Warning: Share appdata set to cache-only, but files / folders exist on the array Shares, Appdata, change use cache: Only to be use cache: Prefer. Settings - Docker, Stop the service. Main, Array Operations, Run Mover. Once its finished re-enable the Docker Service Sep 7 13:09:07 Tower root: Fix Common Problems: Warning: irq 16: nobody cared found on your server At the end of the day, do you see any slowdowns during say parity checks? If not, then ignore the error.

You should ask on Plex's forum about those errors, as they are internal to the container itself. And when no one responds, you should then switch to either binhex's or lsio's containers as they are actually supported.

Not until you fix the invalid XML file Sent from my NSA monitored device

It's a change with the docker API causing this. The temporary fix is detailed in the bug report. But, it is a minor thing. Any container that does actually have an update available for it will download and install.

Closest you can get is hourly itll run (or even say every 10 minutes if you set a force move custom cron) Sent from my NSA monitored device

That's not the problem it's what happens to the share system While knowing nothing about this app at all, I'd prefer if none of the drives were in the template and force the user to add them to lower problems elsewhere Sent from my NSA monitored device

One problem with adding all of the mounts is that IIRC the docker system will automatically create the paths and they will wind up in RAM if they dont get deleted from when the user adds the template. Not sure how the user share system will respond to that. But, fix common problems has had a test in place for this situation for quite awhile Sent from my NSA monitored device

Generally only reason for a container to "disappear" is an error in the template. Reading via apps, previous apps will show the docker run command and the error present Sent from my NSA monitored device

In CA's settings, enable reinstall default then from installed apps click reinstall default, change the name and assign new host ports and paths as applicable done Sent from my NSA monitored device

Just check for updates again on the plugin page

You need to be running 2019-09-01e or greater. A series of errors on my part resulted in that, and very quick updates

If you install the Fix Common Problems App does it say anything about Write Caching?

It's not a problem with the OS, but rather how the manufacturers choose to configure their hard drives. Which is why Fix Common Problems is telling you about it. Not sure if I'd want unRaid (or any OS) automatically doing this for me. On the other hand though, a setting in Disk Settings would make life easier.

The entire contents of the syslog is basically this over and over again Aug 31 14:59:26 Unraid ntfs-3g[7715]: Index buffer (VCN 0x0) of directory inode 89742 has a size (24) differing from the directory specified size (4096). Aug 31 14:59:26 Unraid ntfs-3g[7715]: ntfs_mst_post_read_fixup_warn: magic: 0x00000000 size: 4096 usa_ofs: 0 usa_count: 0: Invalid argument Aug 31 14:59:26 Unraid ntfs-3g[7715]: Index buffer (VCN 0x0) of directory inode 89466 has a size (24) differing from the directory specified size (4096). Kinda stood out

Looks like one of your unassigned devices (can't tell which one -> only that its formatted NTFS) has some corruption on it. Probably best to plug them into a windows box and run chkdsk on them.

The update available thingy has nothing to do with CA at all.

Interesting... Torn through the code over the last few days, and what you just saw is basically impossible where the one file (currentServer) doesn't exist but the templates have been loaded (all of the rest of the error). Only thing I can come up with as to why is a weird circumstance of having multiple browser windows open to CA simultaneously, then on one of them hitting New / Previous / Random / Top / Trending (which reloads the feed) having it fail and displaying the "Download Error message" on the main screen, and then on the second instance of CA in the browser surfing around without hitting one of those aforementioned links. Either way, I'll modify the code slightly so that in this case the 2nd instance will also display the download error.

This looks to be an issue on docker's side (But I could be completely out to lunch -> wouldn't be the first time) It doesn't appear that they are reporting the proper sha for the manifests remotely Manifest URL: https://registry-1.docker.io/v2/linuxserver/radarr/manifests/latest Token URL: https://auth.docker.io/token?service=registry.docker.io&scope=repository%3Alinuxserver%2Fradarr%3Apull HTTP/1.1 200 OK Content-Length: 1788 Content-Type: application/vnd.docker.distribution.manifest.v2+json Docker-Content-Digest: sha256:4c08590e968819112de4533298c2859d128afb449a704301bcfd647dfe38e327 Docker-Distribution-Api-Version: registry/2.0 Etag: "sha256:4c08590e968819112de4533298c2859d128afb449a704301bcfd647dfe38e327" Date: Sat, 31 Aug 2019 02:17:43 GMT Strict-Transport-Security: max-age=31536000 Remote Digest: sha256:4c08590e968819112de4533298c2859d128afb449a704301bcfd647dfe38e327 Update status: Image='linuxserver/radarr:latest', Local='sha256:eec8bb0287a5cb573eb5a14a5c2e1924ad7be66f89ea5e2549440defdafba02b', Remote='sha256:4c08590e968819112de4533298c2859d128afb449a704301bcfd647dfe38e327', Status='false' Now if I pull the image (ie: delete the container, and reload it), in theory the digest sha should be 4c08590e968819112de4533298c2859d128afb449a704301bcfd647dfe38e327 but it's not if I'm reading everything correctly docker images --digests --no-trunc REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE linuxserver/radarr latest sha256:eec8bb0287a5cb573eb5a14a5c2e1924ad7be66f89ea5e2549440defdafba02b sha256:cae2333bf55d51bbf508c333bdbbc70978d41baf0a23207de8bc3251afb73e6d 3 days ago 550MB Therefore an update shows as being available... IIRC, this issue pops up every year or so with docker.

Quite impossible actually.

Interestingly enough, only my containers from LSIO are suffering from that. Everything else (binhex, djoss, etc) does not show an update unless one actually is available. To my workflow however it's irrelevant as I use the auto update plugin to just handle everything for me daily, and never ever go to the docker page and check for updates.