Bungy

The logs don't show anything related to the post processing. What's likely happening is the new image removes python2 because it's deprecated and no longer a support runtime. Likely you'll need to update your post process scripts to python3 and update the python path in your scripts' shebang.

Hmm i don't know if a reason why your speeds would be halved. You can downgrade by specifying a tag for the image. You can try tag :v21.0-2 Another alternative is to use wireguard instead of openvpn. You should see full speeds with wireguard.

I see - So your sonarr/lidarr/etc are using the http_proxy and no_proxy environmental variables to get VPN access into them. Have you tried setting your no_proxy env variable to 192.168.1.71 and then in sonarr set your nzbget server to be 192.168.1.71:6789? Alternatively, if you have local DNS, you can set your no_proxy to something like: no_proxy: *.local,192.168.1.71 I'm using internal DNS to get a ".kube" domain address and then telling it not to use the proxy for all *.kube lookups.

Can you confirm your LAN network is in fact 192.168.1.0/24? What's the IP address on the machine you're currently using? You can try to set the LAN_NETWORK to 0.0.0.0/0 and confirm that the traffic isn't being blocked. That'll verify that the issue is with your setting of that environmental variable. Then you'll need to figure out your docker network address + subnet and include that in the LAN_NETWORK variable. Here is what mine looks like but I have multiple networks and run my containers on a kubernetes cluster, so yours will likely need to differ as well: 192.168.1.0/24,192.168.0.0/24,10.253.0.0/24,10.32.0.0/12 The issue is not related to the ADDITIONAL_PORTS variable. Those were actually removed from binhex's containers and are no longer documented in his github Readmes.

Make sure your LAN_NETWORK environmental variable is set properly to allow access from your sonarr/radarr/lidarr ip address. I have mine set to handle local network traffic as well as docker network traffic. You can set it to 0.0.0.0/0 to allow all inwards traffic, but that's not recommended.

Shoot me a DM with your config info and I'll see if I can find the issue.

Check your config and environmental variables that should be set compared to whats in the PIA section on the github page here: https://github.com/jshridha/docker-nzbgetvpn The unraid template is probably outdated. I haven't updated that thing in years especially since I'm not running linux containers on unraid anymore.

Glad it's working well for you! I too am getting 3x the openvpn speed, so thanks for pushing me to get that done. I'm also glad you were able to resurrect your server and are recovering down in TX.

It's live now. You can either use the latest tag or the v21.0-3 tag

Done! The builds will be hitting docker hub in the next 15 minutes. Enjoy!

Change the image to mysql:5.7

Not that I know of. Containers generally run under the host's network stack. They don't work like virtual machines where each machine can have its own ip address.

Set the network type back to the default. Then you should be able to connect to it using the host unraid system's ip address and port 3306

Yep that's right. Glad you figured it out.

Yeah, it works the same way. Just set VPN_ENABLED=<yes|no>

I'm planning on adding it to the container, but I have not yet. You're better off adding it to the container directly Sent from my SM-N950U using Tapatalk

Try setting the environmental variable STRICT_PORT_FORWARD=no . That gets rid of the port forwarding, which was only really in place for binhex's arch-delugevpn docker container. I did that and doubled my speed. I'm currently using US-east. I haven't tweaked which one will give me the best results and just picked the one closest to me.

I'm getting right at 10 MB/sec also. This *shouldn't* be using the port forwarding capabilities, but I'll double check to make sure it's not doing that setup.

Set the environmental variables such as this: - [email protected] - SMTP_HOST=smtp.gmail.com - SMTP_PORT=587 - [email protected] - SMTP_PASS=yourpassword - SMTP_STARTTLS=true - SMTP_AUTHENTICATION=login

Yes, stop mysql docker. just rename your appdata folder for mysql and then restore the old data to the appdata folder If you don't have the root password, there's no way I know of to recover it. That would be a huge security flaw. When setting up the docker for the first time without any previous data, you set the environmental variable for MYSQL_ROOT_PASSWORD. If you still have that environmental variable set, it likely tells you the password you set up when you first started the docker. You can also set MYSQL_USER, MYSQL_PASSWORD, and MYSQL_DATABASE to set up those parameters as well.

Yes, you can restore the appdata from 3 weeks ago and it'll revert your data back to that point. You'll just need to restore the mysql appdata. Without a user or root password, that's probably your only bet. If you have a user password, you should be able to backup the databases that user has access to. Yeah v8 has caused issues with some other apps I've used. In those cases, there was small fixes that I needed to do to get it to work, but restoring appdata will be the easiest way to get you back up and running.

Also, can I ask what issue you're having with v8? It may be easiest to address those issues directly.

Do you have backups of your appdata by any chance? Otherwise you may be forced to backup using mysql workbench under v8 and then restoring that data into v5

Can you grab the logs from the docker container? something along the lines of this should work, you just may have to change "mysql" to your container name docker logs mysql

Yes, change the image to mysql:5 instead of mysql