Squid

Disable logging in the Folder Caching settings

diagnostics The zip file will get stored in /logs on the flash drive

But can you install new apps from the Apps tab?

It's not. DONE is the same as everywhere else in the WebGUI. It goes to the previous page you were at (ie, in the URL, you'll see something like /Settings/FixProblems. Hitting Done takes you to Settings

Its included in v7+

It's in Markdown format. Any attempt at HTML gets automatically stripped

You'd need to attach a monitor to the system and then see what state the server is in during the reboot

AFAIK Theme engine should still be fine on 7.0.1. It will not as is work on 7.1.0. We do have a code change for compatibility if the author sees it, but otherwise someone will likely fork this plugin and publish it with the compatibility changes

Because "edit" is based upon the name matching the template. If the template doesn't exist, the implication is that you either created the container yourself at the command line and are managing it yourself, or by another application and that application is managing the container. Your situation is closest to the first. Not really sure how to handle the inadvertent change that you had added to the command being issued...

Is there a keyboard and monitor attached? After logging in locally, you can do diagnostics and the file will get saved to the logs folder on the flash drive so you can upload it here

Reason for this would be that the templates store in /config/plugins/dockerMan/templates-user are no longer there. Did you just recreate your flash drive? Also failure Apr 1 18:37:16 Tower in.telnetd[4558]: connect from 192.168.100.1 (192.168.100.1) Apr 1 18:37:16 Tower login: pam_unix(remote:auth): check pass; user unknown You've got a ton of these with varying user names being attempted. Is your server having its ports forwarded direct to the internet or in the routers DMZ?

And this might also be misunderstood. This does not mean that you don't give your server internet access. This is about opening up services directly running on your server to the internet. IE: You wouldn't want to open up the ports on the server so that you can access your files directly via SMB, or to be able to log in to your webUI directly from the outside world. For this you would use TailScale so that you can allow outside connections in a secure manner. Plex is no problem and is perfectly fine to have it serve the files directly over the internet. It is not allowing direct connections to SMB, the webUI etc, but is handling the streaming of the files itself. There is no difference between Plex running on any system and Plex running on Unraid. The risks are akin to allowing any random Windows system to allow direct access to it's files and services over the internet without putting in place adequate security. Unless you are a security expert, I think that most people wouldn't even consider doing it. Unraid is not designed to be have services like SMB directly on the internet. TailScale (and other apps for Unraid) do allow you to remotely access your server's services in a safe and secure manner. Plex allows you to stream your files in a safe and secure manner without having the internet with direct access to the underlying system.

You'd need to set up the syslog server (mirror it to flash), and then after this all happens, post your diagnostics when it comes back, or if you have to force a reboot, post the diagnostics and the syslog.txt file that'll get saved in the logs folder on the flash drive. Create a new thread, as initially I don't think this issue is the same as yours.

Why would you think you are? what are you seeing on the dashboard for instance?

Yes,and @VladoPortos needs to create a template repository with the xml pointed at the plugin.

Doesn't make a ton of sense though either way. Previous apps is just a template to what you've already had installed. Effectively, there is no difference on the docker side of things between taking a template outside of previous apps and one from within.

There's the option on the screen for it to try and avoid disk spin ups. Whether or not they do is dependant upon what is still cached in memory...

Can you guys affected with this add this to your "go" file (/config/go on the flash drive) and reboot. (In particular if you have a dual socket CPU system) sed -i '/worker_processes 1;/a\worker_cpu_affinity 01;' /etc/nginx/nginx.conf So that the go file looks like this: #!/bin/bash # Start the Management Utility sed -i '/worker_processes 1;/a\worker_cpu_affinity 01;' /etc/nginx/nginx.conf /usr/local/sbin/emhttp Does that make any difference in eliminating the out of shared memory issues?

3rd party plugins do require an update to have their communication monitored. This is because not all communication is paused under any circumstances. Notably, notifications will always go through to a browser that is otherwise paused.

Been extremely busy with other things. Tomorrow is the day for going through probably about 50 PMs here

The timeout is 30 seconds. You can disable this entire thing via Settings, Display Settings, Allow RealTime updates. Any issues with nginx_out_of_shared_memory has absolutely nothing to do with any docker containers etc as they don't use the basic internal subsystem at all. But, if you have been receiving the error regularly on previous versions, I'd highly recommend you keep the operation as is. If you still get the error, then I have a good idea as to what the next steps are for the mitigations. If the error completely disappears, then you can try allowing real-time updates, as there is another part of the fix that by itself might have fixed it, we need to know if the default disallowing fixes it first

It looks like you've got a docker container which is continually restarting itself every other second. You should figure out that first. Uptime column on the docker tab should give you the information

You have to actually close the tab, delete the file and then go back. Any tab open to the dashboard that when closes if one of the tabs is huge will immediately cause the same problem

I believe that I've got this issue fixed, and should make it into the next OS release after refinements are done.

Nearly positive I've got it solved. Managed to find a way to replicate it consistently. At least, the way that I found to replicate it is handled, but I have a feeling that your cause might just be the same as mine just manifesting itself differently. Fix should wind up in the next OS release. But, since you've probably noticed that once the tab's memory usage does get that high, even after closing it, chrome etc it will tend to stay high and grow rapidly. Your current fix is to either reboot the server or on the server. rm /var/tmp/charts_data.tmp Only temporary fix though until the OS update.