Squid

Honestly, the problem with AD and Unraid is very few users use it. @limetech has stated that AD works fine in the past, but support from the community in the forums is going to be limited. You might want instead to email LT support for assistance https://unraid.net/contact

USB attached devices while supported aren't recommended. Primarily due to the terrible nature of USB and it's tendency (on all platforms) to disconnect / reconnect for no apparent reason. TBH, most drive "failures" are connection issues (ie: reseat the cabling) vs actual drive failures.

EDIT: AS OF 8/14/21, any all v1 entries are automatically removed from v2 templates in the appfeed Within the next week or so, all v1 template entries will be automatically removed from v2 templates. IE: <Environment>, <Data> and <Publish> will be removed IE: If you're manually editing a template and adding in another variable via the <Environment> <Variable> . . </Variable> </Environment> Without adding the corresponding <Config> entry, your changes won't take effect. This pretty much only affects anyone who manually builds templates without using dockerMan to do it for them. Note that for backwards compatibility, dockerMan will still always save the v1 entries. Just the appfeed and what CA passes back to dockerMan for install will now be strictly v2 Any templates which are not v2 (lacking the <Config> entries) will be unaffected.

The one from Self Hosters doesn't export the /config folder, so it's stored within the docker image and you'd have to enter it's shell to make those changes The one from LinuxServer does export the /config, so presumably (maybe) the file is in /mnt/user/appdata/chevreto. And nothing prevents you from adding another path mapping for your images (ie: /var/www/images mapped to /mnt/user/Photographs)

Not really. The pull counts are kept track of month to month by CA and then the graphs are generated. Closest you can get is that current pull count from dockerHub

Reboot and try it again. I think the original one didn't get unmounted correctly.

Then post your diagnostics

Make sure that in Global Share Settings enable user shares is set to yes

@ljm42

The stats reflect everything. Not just Unraid / Community Applications

Procedure all really depends upon where you were backing it up to.... If backing up to the array, then you have to create a new USB key, assign all of the drives as data drives, then you'll have access to the share you stored the backup on. Copy it over the the new flash and reboot and the system will be back and you'll simply have to transfer your registration key. It's not pretty to do that (far easier to restore from a place you stored outside of the array), but this plugin was doing backups (automated) for years prior to any solution from LT. I do recommend that you look at the flash backup system available when you install the MyServers plugin from LT

It's a bug where the default settings are incorrect when that file is missing (and the file is allowed to be missing). The fix is to simply enable User Shares in Settings - Global Share Settings

hardly.

Have you had FCP automatically fix that error? It's deprecated for maintainers entering it. But it is still used behind the scenes. (No one ever gave it the correct value, so the appfeed automatically fills it out)

Is the share the downloads are happening on name "Downloads"? That share exists on every disk. Do your drives spin down? Most controllers if they have to spin up another drive (if the OS is looking for a file or something) wind up pausing all I/O traffic until that drive is spun up.

Try deselecting the nvme you're passing through in Tools - System Devices, Apply then reselect it and apply followed by a reboot. @ljm42, vfio-pci.cfg shows it being bound, but the OS is still loading the nvme driver for it.

Try this. Settings - Docker. Enable Docker - No. Delete the image. REBOOT. Settings - Docker - Ensure the size is between 10 and 20 then re-enable. If that fails, create a new topic in General Support as it's outside the realm of what this thread is all about.

We you seeing this after you deleted and recreated the docker.img? But I think your issue is that the docker.img can't actually fit on the drive even though it implies it can. Stop the service, Delete the image. Make sure that the size is set to be 25G and then re-enable the service

Copy all of the files contained within the previous folder on the flash drive back to the root and reboot

Thanks guys for pointing it out. Branch installs and searches not including descriptions all fixed up.

You don't need to uninstall if it still works. However you will never be able to reinstall should the need arise. If there's other options available, I'd look at them.

Advanced Settings. Reason why stopping is is the default is because assume this scenario Docker X is accessing files 1 & 2 concurrently. It decides to write changes to both files (and the changes are dependent upon each other) In the middle of all the happening, a backup is also proceding. Because of timing, say the original version of file 1 gets backed up, but the replacement version of file 2 gets backed up. Now on a restore those 2 files are out of sync with each other. Will it cause problems? Impossible to say for sure. The only sure fire way to do any backup / restore is to ensure that all processes that can potentially write to those files are stopped. What are the odds of it happening? Probably small, but the defaults are set to stop the containers for the safest backup. Whether you choose to override it or not is entirely up to you.

Wait for it to be updated to be compatible with 6.10

You have 2GB of memory

You have some corruption on the cache drive Wait for @JorgeB