Dyon

Oh, if username must be lowercase, I can make a check for it

Due to loss of interest in maintaining the Docker container, this project is no longer being worked on, and no updates can be expected. If requested, a new container build for a new version of SABnzbd can be created. However, if the new version of SABnzbd requires additional dependencies or the build fails, I will not fix it, even if it's minor. Just to make sure, I built a new container to ensure it's up to date. I didn't check if there was a new version; I just started a new build for the sake of it. I recommend switching to another SABnzbd container that has VPN capabilities and receives regular updates and better support.

Due to loss of interest in maintaining the Docker container, this project is no longer being worked on, and no updates can be expected. If requested, a new container build for a new version of nzbget can be created. However, if the new version of nzbget requires additional dependencies or the build fails, I will not fix it, even if it's minor. Just to make sure, I built a new container to ensure it's up to date. I didn't check if there was a new version; I just started a new build for the sake of it. I recommend switching to another nzbget container that has VPN capabilities and receives regular updates and better support.

Thank you! Went with method 1 since that is the easiest

What is the process for managing the depreciation status of some of my own applications on CA?

At the bottom there should also be an option to add a new variable, path or port. You can enter a new one for RESTART_CONTAINER. I don't think restart unless-stopped has an impact on this.

Check the advanced settings when editing the container. There should be an environment variable RESTART_CONTAINER, set this to 'no'

Mine has always been orange and I never bothered to look into it hahahaha, never had problems downloading or connection issues

Very odd. Nothing has changed to the container since February. Iy only auto-updates / rebuilds whenever a new Jackett version has been released (which fixes indexing trackers). Nevertheless, I will investigate and look into what could be wrong. Which Unraid version are you running @Skyshroud and @xcsascii?

It is normal that your local DNS is listed in there, so no need to change that. You are running it in Bridge mode, which is correct, which I can see from the log Looking extensively at your log, I don't see anything different compared to mine. Kinda out of ideas, only I could suggest now is to restart your Unraid and check your Docker and Network settings. In Unraid, can you check if Settings -> Docker (show advanced view) -> IPv4/6 custom network info makes sense. For comparison mine: IPv4 custom network on interface br0: Subnet: 192.168.0.0/24 Gateway: 192.168.0.1 IPv6 custom network on interface br0: Subnet: 2001::a300::/64 Gateway: fe80::eaa5 For all DHCP pool: not set And also, check you Settings -> Network Settings Here is my routing table for comparison:

Alright, then it seems to be something related to the DNS. Could you run "cat /etc/resolv.conf" in the terminal and share the output

Could you edit the container and change/add the following: Change the "Repository" field to "dyonr/jackettvpn:dev" Add another Path, Port, Variable, Label or Device > Config Type: Variable > Name: RESTART_CONTAINER > Key: RESTART_CONTAINER > Value: 0 > Default Value: 0 > Description: (empty) > Display: Always > Required: No > Password Mask: no This will add a new variable called RESTART_CONTAINER, if this is set to '1', 'yes' or 'true', it will exit the container when the network is down. When set to something else (like 0) it won't shut down. After changing this, start the container, open the console and please check if you can run the command `ping one.one.one.one`.

If you want another container to access the passthroughvpn container, you must use the internal docker IP. Next to the container, you will see something like "172.17.0.7:25570/TCP <----> 192.168.0.240:25570" in this case 172.17.0.7 is the internal IP of the container, so if you want another container to be able to access the container via the passthroughvpn container, you need to enter, in this case, 172.17.0.7 (with the correct port). Accessing the passthroughvpn container outside of you LAN is possible via port forwards. You could either forward the ports of your LAN (to access it via your own home IP), or, if your provider supports it, forward ports at the VPN Provider's side. Port-forwarding in both cases should be pretty straight forward. I hope it's clear, if not, let me know

I am not in the position to to write an extensive reply, but you might want to read the two scenarios I described in the GitHub page, I'll get back to you later, but this is some info already. https://github.com/DyonR/docker-passthroughvpn

Well, that explains a lot! Glad you found the issue. If you ever run into problems again, let me know!