Sweet, I was able to fix it by changing the .opvn file to another location.

Been loving this, using it for years. I restarted all my dockers and now I am getting the following error:

2026-05-17 18:37:02,587 DEBG 'start-script' stdout output:
[warn] Failed to download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
2026-05-17 18:37:02,587 DEBG 'start-script' stdout output:
[info] Trying to connect to the PIA WireGuard API on 'ca-ontario.privacy.network'...
2026-05-17 18:37:02,620 DEBG 'start-script' stdout output:
[info] Attempting to bring WireGuard interface 'up'...
2026-05-17 18:37:02,650 DEBG 'start-script' stderr output:
[#] ip link add dev wg0 type wireguard
2026-05-17 18:37:02,654 DEBG 'start-script' stderr output:
[#] wg setconf wg0 /dev/fd/63
2026-05-17 18:37:02,656 DEBG 'start-script' stderr output:
Line unrecognized: `PublicKey='
Configuration parsing error
2026-05-17 18:37:02,660 DEBG 'start-script' stderr output:
[#] ip link delete dev wg0
2026-05-17 18:37:02,741 DEBG 'start-script' stdout output:
[warn] Failed to bring 'up' WireGuard kernel implementation

anybody have any ideas?

7 minutes ago, DocLove said:

Been loving this, using it for years. I restarted all my dockers and now I am getting the following error:

2026-05-17 18:37:02,587 DEBG 'start-script' stdout output:
[warn] Failed to download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
2026-05-17 18:37:02,587 DEBG 'start-script' stdout output:
[info] Trying to connect to the PIA WireGuard API on 'ca-ontario.privacy.network'...
2026-05-17 18:37:02,620 DEBG 'start-script' stdout output:
[info] Attempting to bring WireGuard interface 'up'...
2026-05-17 18:37:02,650 DEBG 'start-script' stderr output:
[#] ip link add dev wg0 type wireguard
2026-05-17 18:37:02,654 DEBG 'start-script' stderr output:
[#] wg setconf wg0 /dev/fd/63
2026-05-17 18:37:02,656 DEBG 'start-script' stderr output:
Line unrecognized: `PublicKey='
Configuration parsing error
2026-05-17 18:37:02,660 DEBG 'start-script' stderr output:
[#] ip link delete dev wg0
2026-05-17 18:37:02,741 DEBG 'start-script' stdout output:
[warn] Failed to bring 'up' WireGuard kernel implementation

anybody have any ideas?

See Q29: documentation/docker/faq/vpn.md at master · binhex/documentation · GitHub

Thanks, that pointed me in the right direction, for some reason Unraid was not accessing my vlans correctly. while everything else was working, one Vlan wasn't. rebooting unraid fixed the issue.

appreciate the quick reply.

The Doc.

Hello, I am experiencing a problem with my DelugeVPN app where it will run if VPN is off, but will not run if VPN is on. Additionally, when it runs with VPN off, it does not load any of the torrents I have seeding. These torrent files can be found in the state folder for DelugeVPN, along with fastresume and state files, but they do not load automatically. I am unsure if these issues are related, but they did start at the exact same time.

As far as I'm aware, nothing on my end changed before this happened, although obviously something must have. But the docker app was running just fine one day, then suddenly without my actively changing anything with either software or hardware (no system reset or anything) it just stopped working. I've expereicned this before, but the only other time this happened there was a power outage causing an unexpected reset. Last time, I needed to change the ovpn files, but that doesn't seem to be the issue this time (and last time, the issue of not loading the seeding torrents was not present, only the inability to access with VPN turned on).

I am attaching what I believe is the required information per Binhex documentation on GitHub. If any other information is needed, I will provide it. My tech knowledge level is not bad, but not advanced either; I can follow instructions, but rarely know where to look for things.

Thank you in advance for any help with this!

Command Execution.txt supervisord.log

5 hours ago, Krickis said:

As far as I'm aware, nothing on my end changed before this happened, although obviously something must have.

Looks like the PIA endpoint you are using have dropped support for port forwarding. Pick another endpoint from the list below and redo the OVPN setup.

[info] PIA endpoint 'ca-ontario.privacy.network' is NOT in the list of endpoints that support port forwarding shown below:-

From your supervisord.log:

[info] PIA endpoint 'ca-ontario.privacy.network' is NOT in the list of endpoints that support port forwarding shown below:-
2026-06-17 11:30:12,069 DEBG 'start-script' stdout output:
[info] List of PIA endpoints that support port forwarding:-
2026-06-17 11:30:12,069 DEBG 'start-script' stdout output:
[info] cambodia.privacy.network
[info] np-nepal-pf.privacy.network
[info] panama.privacy.network
[info] cyprus.privacy.network
[info] srilanka.privacy.network
[info] macau.privacy.network
[info] bangladesh.privacy.network
[info] uk-2.privacy.network
[info] ua.privacy.network
[info] in.privacy.network
[info] sanjose.privacy.network
[info] ca-vancouver.privacy.network
[info] monaco.privacy.network
[info] ec-ecuador-pf.privacy.network
[info] pe-peru-pf.privacy.network
[info] bo-bolivia-pf.privacy.network
[info] malta.privacy.network
[info] nl-netherlands-so.privacy.network
[info] ca-toronto.privacy.network
[info] yerevan.privacy.network
[info] montenegro.privacy.network
[info] morocco.privacy.network
[info] venezuela.privacy.network
[info] ba.privacy.network
[info] nl-amsterdam.privacy.network
[info] bahamas.privacy.network
[info] uy-uruguay-pf.privacy.network
[info] vietnam.privacy.network
[info] liechtenstein.privacy.network
[info] de-germany-so.privacy.network
[info] hk.privacy.network
[info] kazakhstan.privacy.network
[info] gt-guatemala-pf.privacy.network
[info] ca-montreal.privacy.network
[info] man.privacy.network
[info] mongolia.privacy.network
[info] albania.pvt.site
[info] algeria.pvt.site
[info] andorra.pvt.site
[info] argentina.pvt.site
[info] austria.pvt.site
[info] au-adelaide.pvt.site
[info] au-brisbane.pvt.site
[info] au-melbourne.pvt.site
[info] au-perth.pvt.site
[info] au-sydney.pvt.site
[info] belgium.pvt.site
[info] brazil.pvt.site
[info] bulgaria.pvt.site
[info] ca-ontario.pvt.site
[info] chile.pvt.site
[info] china.pvt.site
[info] colombia.pvt.site
[info] croatia.pvt.site
[info] czech-republic.pvt.site
[info] de-berlin.pvt.site
[info] de-frankfurt.pvt.site
[info] denmark.pvt.site
[info] egypt.pvt.site
[info] es-madrid.pvt.site
[info] es-valencia.pvt.site
[info] estonia.pvt.site
[info] fi-helsinki.pvt.site
[info] france.pvt.site
[info] georgia.pvt.site
[info] greece.pvt.site
[info] greenland.pvt.site
[info] hungary.pvt.site
[info] iceland.pvt.site
[info] indonesia.pvt.site
[info] ireland.pvt.site
[info] israel.pvt.site
[info] it-milano.pvt.site
[info] jp-tokyo.pvt.site
[info] latvia.pvt.site
[info] lithuania.pvt.site
[info] luxembourg.pvt.site
[info] malaysia.pvt.site
[info] mexico.pvt.site
[info] moldova.pvt.site
[info] new-zealand.pvt.site
[info] nigeria.pvt.site
[info] north-macedonia.pvt.site
[info] norway.pvt.site
[info] philippines.pvt.site
[info] poland.pvt.site
[info] portugal.pvt.site
[info] qatar.pvt.site
[info] romania.pvt.site
[info] saudi-arabia.pvt.site
[info] se-stockholm.pvt.site
[info] serbia.pvt.site
[info] singapore.pvt.site
[info] slovakia.pvt.site
[info] slovenia.pvt.site
[info] south-africa.pvt.site
[info] south-korea.pvt.site
[info] switzerland.pvt.site
[info] taiwan.pvt.site
[info] turkey.pvt.site
[info] uk-london.pvt.site
[info] uk-manchester.pvt.site
[info] uk-southampton.pvt.site
[info] united-arab-emirates.pvt.site

Edited June 17Jun 17 by Jorgen

19 hours ago, Jorgen said:

Looks like the PIA endpoint you are using have dropped support for port forwarding. Pick another endpoint from the list below and redo the OVPN setup.

Oh, awesome! Yeah, did the trick. Still doesn't have the torrents auto-populating. I suppose I can add them back manually, even if it is a hassle, unless someone knows a way to use that fastresume file to just get them all added at once?

Edit: Also while I can now access Deluge on the WebUI, I can no longer seem to access via thin client. Both the WebUI and thin client say they are running version 2.2.0 so I don't think it's a version mismatch issue. I have verified the information in the auth file matches the username and password I'm trying to use for the thin client.

Edit 2: After updating Unraid, the web UI broke again, but I was able to find the issue at that point was Variable: LAN_NETWORK in the settings, where I needed to change it from 1.0/24 to 0.0/24. This fixed not only the web UI but also the thin client connecting. So I'm all set, and I appreciate the help I got here, just wanted to post the experience for anyone finding this with the same issue!

Edited June 21Jun 21 by Krickis

I'm using the delugevpn container and an issue i've been having for quite some time now is that anywhere from 12-36 hours after the container is created, while still accessible, it cannot write to its tmp directory and my private trackers no longer see my seeds. Removing and spinning it back up resolves it until it happens again. I cannot for the life of me figure this out. It's occurred more and more frequently, but it started on the 6.x unraid branch and has continued on 7.x

I'm using a docker folder setup, vs docker img.

Not sure if there has been some changes recently but suddenly all of my systems cant connect to the VPN container when its enabled with the VPN.

When the VPN is enabled and working my containers on the same vlan fail to verify the settings (Unable to connect). Yes the conatiners can ping but it wont verify the settings or connect to any other container running on that VPN.

When I set VPN_ENABLED to No, everything starts working again.

Did something change in a recent update or is there a new setting I haven't setup as my instance has been running for some time,

3 hours ago, brent3000 said:

Not sure if there has been some changes recently but suddenly all of my systems cant connect to the VPN container when its enabled with the VPN.

When the VPN is enabled and working my containers on the same vlan fail to verify the settings (Unable to connect). Yes the conatiners can ping but it wont verify the settings or connect to any other container running on that VPN.

When I set VPN_ENABLED to No, everything starts working again.

Did something change in a recent update or is there a new setting I haven't setup as my instance has been running for some time,

Please do this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md

19 hours ago, strike said:

Please do this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Done see attached

supervisord.log

Command execution.txt

Edited July 26Jul 26 by brent3000

6 hours ago, brent3000 said:

Done see attached

The vpn tunnel seems to be working, so the issue is most likely what you have defined as your LAN_NETWORK. I see you have only one subnet in there, but you mentioned that the container is running on a VLAN. You have to define both your normal LAN subnet and your VLAN subnet (and any other VLAN subnet your might be accessing the webui from), separated by a comma. If that doesn't work, you have to check your network/firewall settings.

Edited July 26Jul 26 by strike

17 hours ago, strike said:

The vpn tunnel seems to be working, so the issue is most likely what you have defined as your LAN_NETWORK. I see you have only one subnet in there, but you mentioned that the container is running on a VLAN. You have to define both your normal LAN subnet and your VLAN subnet (and any other VLAN subnet your might be accessing the webui from), separated by a comma. If that doesn't work, you have to check your network/firewall settings.

All of the containers are on the same vlan, when the VPN portion is turned off it works fine the system can Ping the container but none of the request (From Sonarr etc) are processed. Turn the VPN off and everything works.

Where would I define it if the containers are all running on x.x.11.0/27 where or what else do I need to define?

As mentioned the strange thing is, VPN is on, none of the containers can talk (either the VPN container or the containers behind it) but from the other containers I can ping it.

When the VPN is disabled, no other changes everything works (Which to me rules out the network itself being an issue right?)

Edited July 27Jul 27 by brent3000

30 minutes ago, brent3000 said:

All of the containers are on the same vlan, when the VPN portion is turned off it works fine the system can Ping the container but none of the request (From Sonarr etc) are processed. Turn the VPN off and everything works.

Where would I define it if the containers are all running on x.x.11.0/27 where or what else do I need to define?

As mentioned the strange thing is, VPN is on, none of the containers can talk (either the VPN container or the containers behind it) but from the other containers I can ping it.

When the VPN is disabled, no other changes everything works (Which to me rules out the network itself being an issue right?)

When VPN is enabled strict ip tables rules are in place and every subnet you are accessing the webui from needs to be defined in LAN_NETWORK in the container template. If it's not defined you'll be blocked. So if you're accessing the webui on a machine on the normal Lan or a different vlan it needs to be defined in the template. What is the Ip of the machine you're accessing the webui from?

7 minutes ago, strike said:

When VPN is enabled strict ip tables rules are in place and every subnet you are accessing the webui from needs to be defined in LAN_NETWORK in the container template.

So I have x.x.11.0/27 called out in LAN_NETWORK

When I go to Sonarr (Orr any of them) and I try and validate the torrent client it will spin and timeout. Or do I need to even add my LAN from the PC which I'm using the webui from? THat woudnt make any sense as the container will self validate and its still failing

For example,

DelugeVPN is .5

Sonarr is .6

Both are x.x.11.0/27

My lan (where my Computer is) is x.x.12.0/27, are you saying even this IP needs to be whitelisted? If I'm using a RevProxy? As that is also in the same /27 as the other containers

Strict IP is enabled then the container's own regular sync should self validate but they have been in the same error for over 24 hours (When it self checks every 6)

EDIT: Added my local IP range and same error, but I think thats not the issue or maybe its not applying the values correctly as mentioned, the containers can ping from outside to the VPN container but the container dosnt seem to receive it when sending the validation from Sonarr

Edited July 27Jul 27 by brent3000

3 hours ago, brent3000 said:

My lan (where my Computer is) is x.x.12.0/27, are you saying even this IP needs to be whitelisted?

That's exactly what I'm saying.. In your log from before, it says your LAN_NETWORK is defined as: 10.33.101.0/27

This is not correct if the computer your trying to access the webui from is x.x.12.0/27

Forget about sonarr,privoxy etc for now. First, fix deluge so you can get to the deluge webui. As I've said multiple times, ALL subnets you're accessing the web ui from need to be defined in LAN_NETWORK. So if the computer you're trying to get to the webui from is on x.x.12.0/27 you need to add that. Subnets are separated by commas. After doing this you still can't get to the deluge webui?

3 hours ago, brent3000 said:

Strict IP is enabled then the container's own regular sync should self validate but they have been in the same error for over 24 hours (When it self checks every 6)

What do you mean by this?

On 7/25/2026 at 7:22 AM, brent3000 said:

Not sure if there has been some changes recently but suddenly all of my systems cant connect to the VPN container when its enabled with the VPN.

When the VPN is enabled and working my containers on the same vlan fail to verify the settings (Unable to connect). Yes the conatiners can ping but it wont verify the settings or connect to any other container running on that VPN.

When I set VPN_ENABLED to No, everything starts working again.

Did something change in a recent update or is there a new setting I haven't setup as my instance has been running for some time,

I'm experiencing the exact same behavior and have made no changes to my docker config. I can also get the app to launch if I set VPN_Enabled to No.

CommandExecution.rtf

Edited July 28Jul 28 by trurl
Remove log with password exposed

19 hours ago, strike said:

First, fix deluge so you can get to the deluge webui

I'm not having any issues accessing it via the web UI, my only issue is none of my containers can verify the deluge settings (My local lan is not being impacted when trying to connect to the WebUI and using the container stand alone works fine)

As mentioned Everything is working

Webui for all Containers behind the VPN + the Container itself,

The issue I'm having is that my other containers cant connect to it (They can ping them from the other containers to the VPN container but none of the setups work to verify Deluge to the container when the VPN is enabled)

As mentioned

when the VPN is on,

• Deluge Works fine

• The VPN connects and shows the new external IP fine

• Containers behind the container work fine (WebUI etc)

• BUT no other containers on the same vlan can verify the Deluge settings or access any of the conatiners behind the VPN (Ping of the .4 works so the container can 'see' it but thats the only response I get, everything else times out)

When the VPN is OFF

• As above, all WebUI's work

• All other containers can NOW communicate with the Deluge and verify + all other containers using its network

Edited July 28Jul 28 by brent3000

8 hours ago, brent3000 said:

I'm not having any issues accessing it via the web UI, my only issue is none of my containers can verify the deluge settings (My local lan is not being impacted when trying to connect to the WebUI and using the container stand alone works fine)

As mentioned Everything is working

Webui for all Containers behind the VPN + the Container itself,

The issue I'm having is that my other containers cant connect to it (They can ping them from the other containers to the VPN container but none of the setups work to verify Deluge to the container when the VPN is enabled)

As mentioned

when the VPN is on,

• Deluge Works fine

• The VPN connects and shows the new external IP fine

• Containers behind the container work fine (WebUI etc)

• BUT no other containers on the same vlan can verify the Deluge settings or access any of the conatiners behind the VPN (Ping of the .4 works so the container can 'see' it but thats the only response I get, everything else times out)

When the VPN is OFF

• As above, all WebUI's work

• All other containers can NOW communicate with the Deluge and verify + all other containers using its network

Aha, sorry then I misunderstood your first post. You still need to fix your Lan network tho. As mentioned all subnets that are going to access the webui must be defined in Lan networks, including the vlan subnet. And in the log from before it was not defined. Also make sure you don't use a proxy in the other containers. If it still doesn't work after doing that you should look at the faq. Theres a few things in there regarding using the VPN on other containers. I'm on my phone at work right now so I don't have the link.

17 hours ago, jackfalveyiv said:

I'm experiencing the exact same behavior and have made no changes to my docker config. I can also get the app to launch if I set VPN_Enabled to No.

I'll check your log after work to see if there's anything obvious. In the meantime check out the FAQ.

Edited July 28Jul 28 by strike

1 hour ago, strike said:

Theres a few things in there regarding using the VPN on other containers

As mentioned it's been working for mo ths before hand and it must have been a recent update or something it's all stopped (it's not a new deployment)

The VPN input and VPN Output ports are setup as mentioned the webui works for all the containers behind it and all the containers are on the same Vlan, which was all working fine up untill a week or so ago untill I noticed only my RSS feeds were connecting and nothing else behind the VPN was.

And the strange thing is, when the VPN is turned off everything works as expected, something about the VPN being enabled stops all containers being able to communicate with the VPN app container and everything behind it (as per the logs as well the VPN out and in ports are setup and we're working before a recent update.

Unless the VPN ports are setup back to front but as mentioned, it was working, other containers can't even communicate with deluge let alone anything else behind it so it's something within the whole container stopping even that working.

I don't think it shows in the logs but I did also try adding the deluge ports to the VPN input and outputs to see if that is needed (even tho it's declared further up) but same results

1 hour ago, strike said:

Edited July 28Jul 28 by brent3000

4 minutes ago, brent3000 said:

As mentioned it's been working for mo ths before hand and it must have been a recent update or something it's all stopped (it's not a new deployment)

The VPN input and VPN Output ports are setup as mentioned the webui works for all the containers behind it and all the containers are on the same Vlan, which was all working fine up untill a week or so ago untill I noticed only my RSS feeds were connecting and nothing else behind the VPN was.

And the strange thing is, when the VPN is turned off everything works as expected, something about the VPN being enabled stops all containers being able to communicate with the VPN app container and everything behind it (as per the logs as well the VPN out and in ports are setup and we're working before a recent update

Last update to this image was 11 months ago, so no recent updates..

The reason why it doesn't work when VPN is enabled and works when it is disabled is because of the strict ip tables rules in place. If the VPN is enabled all settings like Lan network, input/output ports needs to be correct. If it's not it will not work. And like mentioned, in your log, it's was not correct. I'm telling you what needs to be set for it to work and you keep ignoring it. Or at least you haven't said you have set the correct Lan network, yet.

One thing I remember now tho, you have this container on a fixed IP I think? That can sometimes work and sometimes it does not.

Post your setting for deluge in sonarr/radarr.

20 hours ago, jackfalveyiv said:

I'm experiencing the exact same behavior and have made no changes to my docker config. I can also get the app to launch if I set VPN_Enabled to No.

First, change your vpn password (and user if you can), as you forgot to redact them from the log. Second, set STRICT_PORT_FORWARD to no. And thrid, see Q17: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

14 hours ago, strike said:

Or at least you haven't said you have set the correct Lan network, yet.

One thing I remember now tho, you have this container on a fixed IP I think? That can sometimes work and sometimes it does not.

Post your setting for deluge in sonarr/radarr.

I did set the LAN in it but tthe same errors and as mentioned, its working fine via the WebUI.

Yes this is using a fixed IP on the same VLAN as the other containers trying to connect. As mentioned they can ping the container, they just cant kick off the Deluge sync (which works when the VPN is off)

Sometimes work and timetimes it does not does that mean its going to be abit of a lucky dip >_< As mentioned the fact it works when the VPN is offline and it cant ping makes me think something about the VPN ports arnt sticking.

As I mentioned, I did make the container some time ago and had to manually add the extra functions, is it possible they arnt applying correctly? Is there a way to validate in and out ports are being set correctly which I can test? As it can ping but it cant access it via port 8112 makes me think its the ports not opening?

Both are using the same setting

(Reminder both Sonarr and Radarr are NOT behind the container and are on dedicated IP's on the same VLAN

Edited July 29Jul 29 by brent3000

Reminder both Sonarr and Radarr are NOT behind the container and are on dedicated IP's on the same VLAN

But why are you messing with input/output ports then? That should only be used if the containers are behind the delugevpn container.

Have you enabled host access to custom networks in settings-Docker?

Do you have proxy enabled in sonarr/radarr?

Please post a new log as well.