Squid

Your CPU doesn't support VT-d (IOMMU). You can still use VMs, but you cannot passthrough any device (video card, etc)

@SpencerJ

Get rid of the quotes on the UD mounted drive is part of the problem failed to start daemon: error initializing graphdriver: failed to make /var/lib/docker/btrfs a mount: Parsing '/mnt/disks/"3rdDisk"' failed: unable to unquote mount point field: invalid syntax Also, you've got a unmountable disk #3 (I assume you know about that).

docker login sets the credentials for v1 API. IE: it only takes effect on actual usage from the command line. Unraid uses the v2 API. Unraid 6.9 beta30+ supports credentials on v2 via scripting to change two lines of code.

Settings - syslog server (there should also be a link next to the warning in FCP to take you directly there IIRC)

Every check for an update to a container counts as a pull. Every update performed counts as a pull. To hit the 100 / 6 hours, you would have to have 50 containers all showing an update and all of them you decide to update. Unlikely to happen (but still possible). Unraid itself has a maximum check rate of 4 times / day (every 6 hours), and this plugin (unless you configure it with a custom cron expression) has a maximum check rate of every 24 hours. Of course (as has been noted previously in this thread), there is zero reason to enable Unraid checking for updates (Settings - notification settings) if you are using this plugin.

That url works fine on 6.9+ (the icon system is more refined in 6.9, but it still should work in 6.8) Usual reason for the "?" is that your server can't actually download it, or download it within (IIRC) 15 seconds.

Just a tad Maximum update check rate that Unraid supports is every 6 hours, so it would take 50 containers installed all with an update available and installed to any normal user to hit the threshold. But, that's not to say that easily supporting login credentials for dockerHub isn't being investigated.

Unplug and replug the network cable?

On 6.8.3+, the images folder on the flash drive aren't actually used. They're a remnant from a previous version of the OS. They are actually stored within the docker image itself. Using https://i.imgur.com/Q2gquX7.png should work....

No. At least not if you didn't previously have the syslog mirroring to the flash drive (only recommended to do for constant / recurring reboots)

Up to you, but if you add in to one of the .page files $(function() { caPluginUpdateCheck("iSCSI.plg",{name:"iSCSI GUI"}); }); It'll let everyone know if there's any updates to the plugin whenever they hit the page. Doesn't require CA itself to be installed. https://forums.unraid.net/topic/79010-ca-api-for-plugin-update-checks/

An obvious question is are you accessing the internet via a proxy?

Are any of the lost containers using any custom networks, or running the network through another container?

😁 I personally don't see the point in split levels. I can understand why people might want to do it, but just can't understand why they actually do use it.

Both of you are having updates to the system (docker auto update) being done in and around the same time as your parity checks. There is however no fundamental reason why the system would "lose" the containers. What do you exactly mean by "lose"

Name them as you choose. Doesnt make any difference to the system

Except that it doesn't delete any backups until a successful backup is completed. But yeah, retain x number of backups will partially alleviate this if you catch it prior to the threshold being reached

Main, Cache Settings, click on Cache, deselect the appropriate monitored attribute in SMART section. But first try simply acknowledging the error in question (click the thumbs down and acknowledge). It shouldn't bug you again unless it increases further

Nov 1 22:15:39 Tower emhttp: get_config_idx: fopen /boot/config/shares/Backups.cfg: No such file or directory - assigning defaults This line *implies* that there's a problem with the flash drive. Not a guarantee as there's usually other lines (at least in v6) that go hand-in-hand with it, but it is suspicious. Unfortunately, further help may be harder to come by as v5 is very old, and not too many users can still remember it (myself included) Hardware wise (outside of the flash drive), the first thing to check is to run a memtest from the boot menu for a minimum of 1 pass (preferably at least a couple, ideally for 24 hours)

It looks like it stopped correctly. Did a refresh of the page do anything?

I know... scheduled fix week of the 8th

Maximum check period is 4 times per day, so you'd have to have 50 containers installed and all 50 show an update to get nailed by it. (Settings - Notification settings) Yup. Because the system works by the repository entry. It all works out in the end, and will adjust itself over time. But, I do have a couple of pet peeves with how some apps are handled by the maintainers that modifying how this works will fix my OCD

I believe that dockerMan already does support other registries on 6.9. (https://github.com/limetech/webgui/pull/650 unless I'm misreading what this is for ) Tomorrow, once the change actually takes effect, I will be testing whether it's a container pull or an image pull (multiple images in a container) that counts towards the quota. Realistically, it shouldn't affect many users around here (uber power users and some developers being the exceptions). On a quick look at the coding, it's not that hard to add in dockerHub credentials to the system to allow you 200+ pulls every 6 hours. But, yeah if you're checking for updates to your containers every hour, then you may run into it. CA itself doesn't particularly care which registry is used. There's a few apps currently which do not utilize dockerHub.