Squid

I think you should always be running the latest stable. Personally, my two production servers always run either the latest stable or the latest RC (whichever is newer).

Try running make_bootable.bat as an administrator

CA does it like this https://github.com/Squidly271/community.applications/blob/master/source/community.applications/usr/local/emhttp/plugins/community.applications/scripts/updatePluginSupport.php But I use a wrapper for the _() function that sees if translations are supported and calls _ accordingly (tr function - only called on the last line)

The values should be correct, But, in order to modify the dockerfile you actually have to build the container yourself.

User scripts docker restart mariadb

@bonienl

Unraid does not support running ARM applications. Most applications if it supports ARM would also support x86 (look at the available tags on dockerHub)

Using Windows / SMB is actually awfully close to the speed of Krusader. SMB / Windows is smart enough that if it knows that both the source and the destination are on the same server then all copies / moves happen directly on the server and no data goes through the network. (ie: Depending upon your cache drives, hard drives etc you can quite easily exceed the maximum 110MB/s transfer rate when using a 1 Gig network.

You're bypassing the system when doing that. Usually no problems, but if the use cache / include / exclude settings differ, then the file may wind up be in *apparent* violation of the rules you've set. Basically the way everyone sets up Krusader is by having a single mount point of something like /UNRAID mapped to /mnt/user (or /mnt) The way every OS works is that when moving files it first tries a rename. Only if the rename fails then does a copy / delete operation take place. In your case, Krusader tries to rename the file to the new share and it succeeds and the file stays put where it is. An identical situation happens via SMB and using "root" shares. Normal moves via SMB and Unraid's shares will always honor the rules because the two shares you're moving between are different mount points, so the initial try Windows does at renaming fails so it has to physically move the file.

This means that your server is unable to reach GitHub to access the primary application feed, and is instead utilizing a mirror of it hosted on amazonaws. Since a fair amount of icons and all of the plugins are hosted on GitHub, the message is a warning that those aspects may be affected within CA (and also the Plugins Page won't be able to check for updates etc) EDIT: And it should also be noted that the only place this will ever appear is within the APPS tab

Because you have a note on that page

First thing is to make sure in Settings - Global Share Settings that user shares are enabled.

Without you actually going into the flash share and deleting them yourself, there's only 2 ways via the WebGUI to delete the templates Via CA, previous Apps and clicking the "X" on the card or selecting a bunch of templates and then clicking the "X" on the top right. Both times a popup asks are you sure. Via Add Container screen, selecting the template from the drop down and then clicking the "X" next to it after selecting. No clue if that brings up a confirmation or not, as I never use Add Container.

If you can't ping say 8.8.8.8 then you have definite internet connectivity issues. Are you running something like pFsense that may be blocking requests?. Have you rebooted the router / switch?

This is a known issue with 6.10-rc1 and I believe is fixed on the next release.

The plugin does not delete any templates

My opinion: Presumably, you bought ECC memory so that once errors started occurring you would replace the stick(s). While the errors are being corrected now (due to the ECC), at some point (maybe never) the sticks won't be able to correct the error. At that point many systems will simply completely stop all execution of everything (making it appear to be a hard lockup) which is a pain to diagnose unless you think to go into the System EVent Log to see what happened. Or to put another way, why did you buy ECC memory in the first place?

You're adding it as an environment variable. When you edit the container there is (advanced view) a line that explicitly says Extra Parameters. Enter --memory=500m there

Most likely it's definitely a sensor thats not on the CPU

Setting Theme there to be white and then deleting the entries for the custom colors on that page will basically set the display back to default.

Settings - Display Settings. (And uninstall the Theme Plugin)

It damn well should... I've never had a problem with it and symlinks. That's the whole point of the backup being valid, and was tested.

What you'd need to do is have 2 separate XML's for the same container being installed. One with the GPU changes, and one without. Then when you need to stop one and start the other you would do a simple docker stop nameOfContainer and then start the other one via https://forums.unraid.net/topic/40016-start-docker-template-via-command-line/?tab=comments#comment-1022006

That's the acpitz - temp 3. If nothing is listed in the Fan section, then sensors detect isn't picking up any valid sensors for it. Not an uncommon problem, and unfortunately outside of bonienl's control.