strike

Well, after resuming the parity-check again and keeping an eye on the CPU usage I'm not entirely convinced on your theory. The total CPU usage never goes over 55%. Idle when the parity-check is not running the usage is about 20%. I don't have any emby users on right now but my VM started to lag/freeze almost the second I resumed the parity-check. The 4 first cores are barely being used (10-30%), occasionally some of the threads spikes to about 70% for one second. The 4 last cores which my VM uses is another story though. 3-4 of the total 8 threads are almost constantly at 100%, it goes down for a few seconds occasionally but right back to 100%. Which threads it is varies, but it seems to for the most part be one full core and one-two HT. And the others spikes as well, but they never stay at 100%. My emby container only uses the first 4 cores and the vm uses as I said the last 4. Every other container uses, for the most part, the first core, as they don't do any heavy lifting anyway. I've never heard anything from my emby users about lag/stop when I'm not running a parity-check So I'm assuming 4 cores (even when transcoding) is enough. I use high priority on transcoding so the 4 cores will have some workout, but only for about 1-2 min until the whole movie is done transcoding. I can see that maybe be a problem for the emby users when the parity-check is running, but it should only last like I said 1-2 min. But my emby users are reporting stop/lag very frequently and that was long after it was finished transcoding too. So I don't think it has anything to do with the transcoding either. I even think they reported lag when there was no transcoding involved too IIRC, but I might be wrong about that. I have no Idea how this works either but from what I'm seeing it can use all cores. And had it only been one I would have thought it would favor the first core? But yeah, as I said the first 4 cores are barely being used. For the emby problem, I guess I could change the transcode priority to low to check if that solves it. It would just take longer to transcode the whole movie. But I have no idea on how to solve the VM issue.. Any thoughts? I could maybe reverse the workload (put the VM on the first 4 cores and emby on the last 4) and see if that helps. But I can't see any logical reason why that would work either, unless the parity-check heavily favors the last 4 cores.. I could work around it all by using the parity-check tuning plugin of course and I most certainly will, but I would like to know the root cause so if I have to I can leave the parity check running regardless of what the server is doing (well not any gaming or heavy use of course). What happens when I need to rebuild a disk for example, is my server unusable for like 20 hours?

I may have missed something as I only skimmed through your post. Or I misunderstood something. But to me, it seemed like the only way you got it to work was when you used the root user (which is the way it's supposed to work) and when you tried to put in another user it didn't work because it still used root (?). That's the way I read it anyway. So to me, your statement is wrong. You can only get it to work the way it's supposed to, but not the way you want to would be more correct imo.

Then I understand, as I said I'm no nginx expert and never had the usecase to try this. But I still I can't see how this app would know that you're using nginx reverse proxy and that header. I'm also not a programmer but I don't think this app supports what you're trying to do.

@mikeydk I've only skimmed the last posts, but I see you mention that nginx takes care of the login and you also mention other users than root. I assume by nginx you mean reverse proxy? Can you explain what you think the reverse proxy part of nginx is doing in your setup? How exactly do you tell nginx what user to log into unraid with? You say that nginx runs as root, and it will always log into unraid with root no matter what user you use. how do you do that? Do you change the PUID,PGID of the container? And do you expect it to then log into other services with the user you run the container as? Either I'm missing something or maybe you have misinterpreted on how "nginx" (reverse proxy) works. What the reverse proxy does is serves you your local services through the internet via a domain. So what happens when you go to your domain/IP it serves the unraid webui as you were sitting locally. And since the only user that can log into the webui is root how do you expect to log into "nginx" with another user than root and except "nginx" to magically put in the root user and password? I'm no nginx expert, so I'd like to know how you do this. I see you mention .htpasswd file all this does is serve up a simple login to get access to the service behind the reverse proxy, once logged in it will still serve the local login to the service if it has one. So essentially you have to log in twice, once with whatever user you set up in the htpasswd file, and once with the REAL username and password to the service. So if you understand all this I'm still at a loss on how you expect this app (or any app really) to log into the webui (which ONLY accepts the root username and password) with another user. I don't care what magic the app (nginx) does, if it doesn't put the root username and password into the unraid webui login box it isn't going to work, as simple as that.

That must be it, if I'm not mistaken I upgraded to dual parity about 8-10 months ago. But those call traces, are they related to the fact that the CPU has too much to do, as in it almost can't handle it? I must admit, I can't remember I've looked at the CPU usage during a parity check for a long time. The CPU has always been powerful enough for my use. But yeah, it isn't really exactly new..

Yeah, I actually have that plugin installed, just haven't had the chance to set it up yet.

So I've been having an issue for a while, but I haven't had the time to look into it and it's been a low priority since it only happens every 2 months when I do a parity check. The issue is when I run a parity check my vm will start to lag and will eventually crash, reboot - repeat. Also, my emby users are reporting lag/stop in playback whenever I run a parity check. Think I've run into this issue with local playback too. Thing is, this never used to happen, it only started like maybe 3-4 parity checks ago which will make it about 6-8 months ago. I started a parity check 10:05 today, and soon after the issue would manifest. 12 hours in I paused the parity check (thank you so much for this function btw!), because I was going to use my windows vm. I then looked at the log and I see call traces which I assume has something to do with my issue since it never shows up otherwise. So if someone can take a look at my diags and maybe point out what could be wrong I would really appreciate it. Ps: Please ignore the FCP message about my VM share is cache only but files exist on array. That's from a long time ago and are only old vdisks that are not in use right now. The VM I use now exists only on the cache drive so that's not the problem. Edit: I actually just now looked at my chat logs with one of my emby users and I was right, the issue first started happening in October 2018, which makes it about 8 months ago. tower-diagnostics-20190609-2012.zip

I find that very unlikely, you probably just never noticed before.

Nothing that can be done about that besides doing what you mentioned (restart or change endpoint). Unfortunately, spammers etc also use vpn services and as a result, some IP addresses get banned. The only thing you can do to help out is to contact PIA about it so they can investigate.

I've actually used custom bridge as the network type for a long time and it worked flawlessly. Then last week I upgraded all my network hardware, now I can't get to the webui (everything related to network setup on the unraid box is the same as on the old hardware), but I can connect in the deluge client in my vm just fine. For my use, I don't really need the webui as long as I can log in from another deluge client. So @Biloxi_1 try connecting via a deluge client on another machine/vm, at least that way you'll be able to manage it. Instructions to connect are in the faq I think. Edit: All my automated download apps like radarr etc works as expected, with the static IP I've set in the custom bridge network.

ExpressVPN is not going to work well with torrenting due to the fact that they don't support port forwarding. Even if you were able to download anything it will be painfully slow and it would only work on public trackers. Do yourself a favor and change to a provider that supports port forwarding.

Yes, if your account expires your login credentials will be blocked by PIA causing the container to not be able to authenticate.

br0 is not supported in this container, please change to bridge or host.

You didn't say which provider you're using, but regardless of that, you need to use a server that supports port forwarding. Servers that don't support port forwarding will always be slow. It does. Not sure if you mean your router firewall or the built-in delugevpn firewall. But the simple answer is no. The longer answer is that your router firewall is ignored when connected to a vpn. You're now using your vpn providers firewall so any settings/changes in your router firewall will be ignored. The delugevpn firewall is in place to make sure that the connections drops if your vpn connection ever fails. So 1. once connected to a vpn you are using their firewall. 2. If the vpn connection ever fails you go back to your normal connection and your own firewall UNLESS there is something blocking that connection like the iptable rules in place in this container.

Well, I think I have to agree now that I think about it. I'd like to have a powerful and a secure server but it seems that I can't have both anymore. Since unraid 6 my unraid server does so much in my home that I'd hate to lose any of it on account of performance. My data is valuable to me but not THAT valuable that I risk a 30-50% performance hit. Then I'd rather lose my data and restore from backup. Cause like all seasoned unraid users I do have backups.

Thanks for being on top of this. Off topic: These vulnerabilities are becoming a nightmare for the performance. Last time it affected the performance and I vaguely remember reading something about that this patch also would impact the performance. Soon our powerfull unraid servers will be a slow as hell, barely able to run as a plain NAS..

Is this plugin gonna be updated to work with 6.7? Just updated and etherwake doesn't work anymore. Nevermind.. I just remembered that I had a power outage this week, and for some reason, I need to power on the backup server manually one time before it will accept a magic packet. Did that and it works as normal.

In the syslog. If you enable notifications and have e-mail notification set up you also get a list of all the files by mail. And the files aren't necessarily "bad", the files could have just been updated and thus changed the hash. So it's a good idea to exclude files that gets updated a lot by various apps, like .nfo files.

no, you enter the username and password you set in the auth file. Where "username" is your username and "password" is your password.

I didn't quote you, my reply was for @rbh00723

Edit the auth file located in your delugevpn appdata dir. Add the user/pass on a new line in this format: username:password:10 restart the container and you should be able to connect

Yeah, mine too really. I know how to set it up I think, but I don't know how to analyze the data. But I've not seen any leakage on delugevpn with privoxy enabled when testing on various leakage test sites so I'm choosing to trust it.

I think you'll need to do some "wiresharking" to figure that out.

I think the answer to this is yes, correct me if I'm wrong. If it works it works, if not, then oh well. I think this is the case for all the ..VPN containers. I have the delugevpn container running on macvlan, but I think I'm one of the lucky few because almost nobody else is able to get it to work.

lol, well glad you figured it out!