Squid

I'm still using my original sticks from 2012-2013. I think a lot of this is "false" failures. Using poor quality sticks or counterfeit Kingston sticks from China, unclean shutdowns corrupting the stick etc. Considering just how little the stick is actually written to, it should easily outlast by far any given hard drive in your system.

There is limited amount of space that I want to use in the suggested fixes for FCP. But it is a valid point

One problem fixed. Now wait and see what happens

diagnostics would tell or df -h

76% what docker or log

the appdata will be safe and the templates will be already filled out and reinstalled the same way.

I missed that being mentioned. Try this Settings - Docker - Disable the service. Delete the image, re-enable the service Apps, Previous Apps, Check off what you want

Nothing particularly changed on the usage of the log.

Thank you I was hoping that you'd do the diagnostics command before rebooting. Wait for the log to start filling up again, then post a new set of diagnostics

from the terminal, diagnostics It'll get saved to the flash drive in the logs folder. Upload that zip

unRaid's webserver ran out of memory for some reason. Not quite sure why, but you're going to reboot to fix.

Regarding <TemplateURL> If having this entry populated with the URL causes problems for you, then going forward (as of Feb 21) maintainers can manually edit the appropriate xml in their repositories and either change the existing entry or add in <TemplateURL>false</TemplateURL> If the appfeed sees false in that entry, then it will not populate it automatically with the URL of your template. This has the result of if a user deletes a variable, then on the next container update dockerMan will not re-add that variable back into their template. This is a manual only edit, and cannot be done via dockerMan's GUI. If any one starts bugging you about FCP complaining about a missing template URL via FCP, then tell your users to simply ignore that error. Note that any of your users will also either have to reinstall the app from scratch or manually edit their user template to get rid of the existing entry. @Roxedus

Programming Board would be the applicable place, but I'll go ahead and let the feed ignore populating that entry and will post somewhere in there with an entry to add to the template to do this.

OK. So how would this scenario work: User installs template X Sets it up and deletes the applicable config Updates happen and that entry never gets repopulated into the user template Buddy decides for whatever reason to start over again from scratch with their appdata. Deletes the applicable appdata folder, uninstalls the app, then reinstalls from previous apps. Now that particular variable is missing from the template, and the container won't install properly It's basically nothing (1 line of code) to have docker updates ignore a config update if an attribute is present. But I can foresee situations like the above happening. I think what I'll do instead is allow on the template instead a flag to have the appFeed skip populating the TemplateURL which will also fix the problem (but has other caveats), but is probably easier to deal with in the long term.

So you think it would be useful to have something like a "noUpdate" attribute on the applicable <Config> entry so that the system when it updates will ignore that element and not add it in again... @binhex?

Post diagnostics when that happens.

Ah. Feature of unRaid itself. Any update to the container will also bring in any missing ports / variables etc under the assumption that the update brings new features that might require that. I'd recommend that the container is set up to ignore variables that aren't actually filled out. Alternatively, you can disable that feature completely by editing the template within /config/plugins/dockerMan/templates-user and removing the <TemplateURL> entry. (Although at that point FCP will complain, but that can be ignored) Over the years, the updating of the template has proved to be useful as the apps themselves evolve, (ie: webUI entry changes), but it's never going to be a perfect system. Because of the maintainers who did fill out that entry in the first place did it wrong (fully 50% of them), CA's appfeed now handles it and there is no more access to that entry in the webUI anymore.

Not really sure what you're meaning here. Whatever is in the template the user has is what CA deals with.

You never (should never have) seen anything after simply logging in. cd / Will get you to where you need to be.

Then to be honest you don't have enough cooling in your system. IMO, any computer (server / desktop / laptop/ phone) has to be able to handle a full CPU load at any given time for extended periods. 3 choices: Increase the cooling Downgrade the CPU to something that doesn't run as hot Experiment with the docker run command to limit the maximum CPU that the app can use (google docker run reference)

Might be better to ask, but which folders are you looking for ?

Not sure. I just spun up a Catalina VM and could access a file created via it no problems on Windows. Utilizing the same network credentials on both systems

Best guess right now is you've gotten nailed by a feature of windows where it caches credentials, and the credentials originally used prior to creating the users don't have access rights. I think this'll work from a windows command prompt net use * /del

Top of my head, I'd guess corrupted docker.img Post the diagnostics

You've got a ton of this Feb 20 05:24:51 Odin kernel: pcieport 0000:00:01.1: AER: Corrected error received: 0000:00:00.0 Feb 20 05:24:51 Odin kernel: pcieport 0000:00:01.1: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID) Feb 20 05:24:51 Odin kernel: pcieport 0000:00:01.1: device [1022:1453] error status/mask=00000040/00006000 Feb 20 05:24:51 Odin kernel: pcieport 0000:00:01.1: [ 6] BadTLP being logged. I would check for BIOS updates and make sure all cards are properly seated.