somehow i have messed up DNS for this after setting up local DNS in my pihole and nginx. all my other container apps went fine (just added local DNS entry on pihole and proxy hosts in nginx), then i repeated the same thing for this one and after restarting the image initially the wg0 interface would not come up at all.  I tried un-doing all of the DNS changes I made for this container - deleted entries on pihole and nginx, and deleted/reinstalled the image via template. Also have gotten a completely fresh wg0.conf from VPN provider (mullvad). Now the interface comes up and web gui is accessible, but it is not able to resolve www.google.com and there is no external traffic obviously.  If I disable the VPN everything works just fine.

 

Do I need to just undo ALL of the local DNS stuff I did in pihole and nginx?

 

Any help would be greatly appreciated!

 

edit:

 

whelp... after all that i finally realized my mullvad subscription just happened to run out exactly at the wrong time.  so apparently it's NOT always DNS lol.

Edited May 7, 20251 yr by acosmichippo
attached log

Hi all,

Been away for a bit (wife is in the hospital recovering from cancer surgery), and when I came back, I noticed that qBT is inaccessible.  I seem to recall something happening once before where the PIA cert got borked or similar.  I'm sorry I don't have time to do extensive searching, as I have to be back at the hospital shortly.  Can anyone point me to what may be the cause?
I'm using PIA VPN, and when I try to access the qBT web GUI, either with my normal saved bookmark (previously working) or via the "webUI" option from within unraid dashboard, I get the same error: 

This site can’t be reached

192.168.11.XXX refused to connect. 

 

Any help appreciated.  Normally I'd try to track this down myself, but I'm a bit scrambled right now.  I'd like to have things up and running before she gets home, since she will have lots of 'TV time' while she recovers.

 

EDIT:  So I'm back home now, and had time to scan back a few pages.  It seems that several others are having a similar sudden issue of not being able to connect to the UI, but I don't see any solutions.
I pulled my logs, and see what's posted below.  I'm not good at deciphering these, but I definitely see some issues with connecting to WG.  Absolutely nothing has changed with by network or unraid/docker config, since I've been away for 8 days, and it was working before I left. 

I know it's not just a UI issue, since Sonarr is reporting that it's not able to reach qBT either.

 Logs:

text  error  warn  system  array  login  

-A OUTPUT -o eth0 -p tcp -m tcp --sport 45206 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 45206 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o wg0 -j ACCEPT

2025-05-07 16:27:32,566 DEBG 'start-script' stdout output:
--------------------

2025-05-07 16:27:32,572 DEBG 'start-script' stdout output:
[info] Configuring WireGuard...

2025-05-07 16:27:32,845 DEBG 'start-script' stdout output:
[info] Token generated for PIA wireguard authentication

2025-05-07 16:27:32,854 DEBG 'start-script' stdout output:
[info] Trying to connect to the PIA WireGuard API on 'greenland.privacy.network'...

2025-05-07 16:32:33,286 DEBG 'start-script' stdout output:
[info] Attempting to bring WireGuard interface 'up'...

2025-05-07 16:32:33,315 DEBG 'start-script' stderr output:
Warning: `/config/wireguard/wg0.conf' is world accessible

2025-05-07 16:32:33,338 DEBG 'start-script' stderr output:
[#] ip link add wg0 type wireguard

2025-05-07 16:32:33,344 DEBG 'start-script' stderr output:
[#] wg setconf wg0 /dev/fd/63

2025-05-07 16:32:33,346 DEBG 'start-script' stderr output:
Line unrecognized: `PublicKey='
Configuration parsing error

2025-05-07 16:32:33,352 DEBG 'start-script' stderr output:
[#] ip link delete dev wg0

2025-05-07 16:32:33,410 DEBG 'start-script' stdout output:
[warn] WireGuard interface failed to come 'up', exit code is '1'

2025-05-07 16:33:03,418 DEBG 'start-script' stdout output:
[info] Configuring WireGuard...

2025-05-07 16:33:03,646 DEBG 'start-script' stdout output:
[info] Token generated for PIA wireguard authentication

2025-05-07 16:33:03,655 DEBG 'start-script' stdout output:
[info] Trying to connect to the PIA WireGuard API on 'greenland.privacy.network'...

2025-05-07 16:37:40,993 INFO reaped unknown pid 54 (terminated by SIGTERM)
2025-05-07 16:37:40,993 WARN received SIGTERM indicating exit request
2025-05-07 16:37:40,994 DEBG killing watchdog-script (pid 362) with signal SIGTERM
2025-05-07 16:37:40,994 INFO waiting for start-script, watchdog-script to die
2025-05-07 16:37:40,996 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 22626366230672 for <Subprocess at 22626381006160 with name watchdog-script in state STOPPING> (stdout)>
2025-05-07 16:37:40,996 DEBG fd 15 closed, stopped monitoring <POutputDispatcher at 22626365868192 for <Subprocess at 22626381006160 with name watchdog-script in state STOPPING> (stderr)>
2025-05-07 16:37:40,996 WARN stopped: watchdog-script (exit status 143)
2025-05-07 16:37:40,997 DEBG received SIGCHLD indicating a child quit
2025-05-07 16:37:40,997 DEBG killing start-script (pid 361) with signal SIGTERM
2025-05-07 16:37:40,998 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22626367780048 for <Subprocess at 22626367776016 with name start-script in state STOPPING> (stdout)>
2025-05-07 16:37:40,999 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22626366229712 for <Subprocess at 22626367776016 with name start-script in state STOPPING> (stderr)>
2025-05-07 16:37:40,999 WARN stopped: start-script (terminated by SIGTERM)
2025-05-07 16:37:41,000 DEBG received SIGCHLD indicating a child quit
Created by...
___.   .__       .__
\_ |__ |__| ____ |  |__   ____ ___  ___
 | __ \|  |/    \|  |  \_/ __ \\  \/  /
 | \_\ \  |   |  \   Y  \  ___/ >    <
 |___  /__|___|  /___|  /\___  >__/\_ \
     \/        \/     \/     \/      \/
   https://hub.docker.com/u/binhex/

2025-05-07 16:37:46.494736 [info] Host is running unRAID
2025-05-07 16:37:46.564660 [info] System information: Linux a7bf00c800fa 6.1.74-Unraid #1 SMP PREEMPT_DYNAMIC Fri Feb  2 11:06:32 PST 2024 x86_64 GNU/Linux
2025-05-07 16:37:46.645853 [info] Image tags: BASE_RELEASE_TAG=2025042801,INT_RELEASE_TAG=2025042801,IMAGE_RELEASE_TAG=5.1.0-1-01
2025-05-07 16:37:46.727980 [info] PUID defined as '1001'
2025-05-07 16:37:46.811201 [info] PGID defined as '100'
2025-05-07 16:37:46.938133 [info] UMASK defined as '000'
2025-05-07 16:37:47.013407 [info] Permissions already set for '/config'
2025-05-07 16:37:47.095606 [info] Deleting files in /tmp (non recursive)...
2025-05-07 16:37:47.187587 [info] VPN_ENABLED defined as 'yes'
2025-05-07 16:37:47.271169 [info] VPN_CLIENT defined as 'wireguard'
2025-05-07 16:37:47.351913 [info] VPN_PROV defined as 'pia'
2025-05-07 16:37:47.448677 [info] WireGuard config file (conf extension) is located at /config/wireguard/wg0.conf
2025-05-07 16:37:47.550783 [info] VPN_REMOTE_SERVER defined as 'greenland.privacy.network'
2025-05-07 16:37:47.627768 [info] VPN_REMOTE_PORT defined as '1337'
2025-05-07 16:37:47.702727 [info] VPN_DEVICE_TYPE defined as 'wg0'
2025-05-07 16:37:47.771075 [info] VPN_REMOTE_PROTOCOL defined as 'udp'
2025-05-07 16:37:47.849975 [info] USERSPACE_WIREGUARD not defined (via -e USERSPACE_WIREGUARD), defaulting to 'no'
2025-05-07 16:37:47.925217 [info] NAME_SERVERS defined as '84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1'
2025-05-07 16:37:49.093089 [info] LAN_NETWORK defined as '192.168.11.0/24'
2025-05-07 16:37:49.184215 [info] LAN_NETWORK exported as '192.168.11.0/24'
2025-05-07 16:37:49.261568 [info] VPN_USER defined as 'xxx'
2025-05-07 16:37:49.340011 [info] VPN_PASS defined as 'xxx'
2025-05-07 16:37:49.422404 [info] STRICT_PORT_FORWARD defined as 'yes'
2025-05-07 16:37:49.504381 [info] VPN_INPUT_PORTS defined as 'xxxxxx'
2025-05-07 16:37:49.584865 [info] VPN_OUTPUT_PORTS not defined (via -e VPN_OUTPUT_PORTS), skipping allow for custom outgoing ports
2025-05-07 16:37:49.659966 [info] ENABLE_STARTUP_SCRIPTS not defined (via -e ENABLE_STARTUP_SCRIPTS), defaulting to 'no'
2025-05-07 16:37:49.739527 [warn] ENABLE_SOCKS not defined (via -e ENABLE_SOCKS), defaulting to 'no'
2025-05-07 16:37:49.816178 [info] ENABLE_PRIVOXY defined as 'no'
2025-05-07 16:37:49.901452 [info] WEBUI_PORT defined as '8080'
2025-05-07 16:37:49.996279 [info] SHARED_NETWORK not defined (via -e SHARED_NETWORK), defaulting to 'no'
2025-05-07 16:37:50.071687 [info] Starting Supervisor...
2025-05-07 16:37:50,584 INFO Included extra file "/etc/supervisor/conf.d/qbittorrent.conf" during parsing
2025-05-07 16:37:50,585 INFO Set uid to user 0 succeeded
2025-05-07 16:37:50,593 INFO supervisord started with pid 7
2025-05-07 16:37:51,598 INFO spawned: 'start-script' with pid 361
2025-05-07 16:37:51,602 INFO spawned: 'watchdog-script' with pid 362
2025-05-07 16:37:51,604 INFO reaped unknown pid 8 (exit status 0)
2025-05-07 16:37:51,608 DEBG 'start-script' stdout output:
[info] VPN is enabled, beginning configuration of VPN

2025-05-07 16:37:51,609 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2025-05-07 16:37:51,609 INFO success: watchdog-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2025-05-07 16:37:52,145 DEBG 'start-script' stdout output:
[info] Adding 192.168.11.0/24 as route via adapter eth0

2025-05-07 16:37:52,149 DEBG 'start-script' stdout output:
[info] ip route defined as follows...
--------------------

2025-05-07 16:37:52,153 DEBG 'start-script' stdout output:
default via 172.17.0.1 dev eth0 
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.7 
192.168.11.0/24 via 172.17.0.1 dev eth0 

2025-05-07 16:37:52,153 DEBG 'start-script' stdout output:
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 172.17.0.7 dev eth0 table local proto kernel scope host src 172.17.0.7 
broadcast 172.17.255.255 dev eth0 table local proto kernel scope link src 172.17.0.7 

2025-05-07 16:37:52,154 DEBG 'start-script' stdout output:
--------------------

2025-05-07 16:37:52,166 DEBG 'start-script' stdout output:
iptable_mangle         16384  2
ip_tables              28672  6 iptable_filter,iptable_raw,iptable_nat,iptable_mangle
x_tables               45056  19 ip6table_filter,xt_conntrack,iptable_filter,ip6table_nat,xt_tcpudp,xt_addrtype,xt_CHECKSUM,xt_nat,xt_comment,ip6_tables,ipt_REJECT,xt_connmark,iptable_raw,ip_tables,iptable_nat,ip6table_mangle,xt_MASQUERADE,iptable_mangle,xt_mark

2025-05-07 16:37:52,167 DEBG 'start-script' stdout output:
[info] iptable_mangle support detected, adding fwmark for tables

2025-05-07 16:37:52,450 DEBG 'start-script' stdout output:
[info] iptables defined as follows...
--------------------

2025-05-07 16:37:52,454 DEBG 'start-script' stdout output:
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -s 91.90.120.144/32 -i eth0 -j ACCEPT
-A INPUT -s 91.90.120.138/32 -i eth0 -j ACCEPT
-A INPUT -s 91.90.120.136/32 -i eth0 -j ACCEPT
-A INPUT -s 104.18.40.93/32 -i eth0 -j ACCEPT
-A INPUT -s 172.64.147.163/32 -i eth0 -j ACCEPT
-A INPUT -s 104.18.159.201/32 -i eth0 -j ACCEPT
-A INPUT -s 104.19.240.167/32 -i eth0 -j ACCEPT
-A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A INPUT -s 91.90.120.144/32 -i eth0 -j ACCEPT
-A INPUT -s 91.90.120.138/32 -i eth0 -j ACCEPT
-A INPUT -s 91.90.120.136/32 -i eth0 -j ACCEPT
-A INPUT -s 104.18.40.93/32 -i eth0 -j ACCEPT
-A INPUT -s 172.64.147.163/32 -i eth0 -j ACCEPT
-A INPUT -s 104.18.159.201/32 -i eth0 -j ACCEPT
-A INPUT -s 104.19.240.167/32 -i eth0 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 8080 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 45206 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 45206 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i wg0 -j ACCEPT
-A OUTPUT -d 91.90.120.144/32 -o eth0 -j ACCEPT
-A OUTPUT -d 91.90.120.138/32 -o eth0 -j ACCEPT
-A OUTPUT -d 91.90.120.136/32 -o eth0 -j ACCEPT
-A OUTPUT -d 104.18.40.93/32 -o eth0 -j ACCEPT
-A OUTPUT -d 172.64.147.163/32 -o eth0 -j ACCEPT
-A OUTPUT -d 104.18.159.201/32 -o eth0 -j ACCEPT
-A OUTPUT -d 104.19.240.167/32 -o eth0 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A OUTPUT -d 91.90.120.144/32 -o eth0 -j ACCEPT
-A OUTPUT -d 91.90.120.138/32 -o eth0 -j ACCEPT
-A OUTPUT -d 91.90.120.136/32 -o eth0 -j ACCEPT
-A OUTPUT -d 104.18.40.93/32 -o eth0 -j ACCEPT
-A OUTPUT -d 172.64.147.163/32 -o eth0 -j ACCEPT
-A OUTPUT -d 104.18.159.201/32 -o eth0 -j ACCEPT
-A OUTPUT -d 104.19.240.167/32 -o eth0 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8080 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 8080 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 45206 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 45206 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o wg0 -j ACCEPT

2025-05-07 16:37:52,457 DEBG 'start-script' stdout output:
--------------------

2025-05-07 16:37:52,461 DEBG 'start-script' stdout output:
[info] Configuring WireGuard...

2025-05-07 16:37:52,692 DEBG 'start-script' stdout output:
[info] Token generated for PIA wireguard authentication

2025-05-07 16:37:52,702 DEBG 'start-script' stdout output:
[info] Trying to connect to the PIA WireGuard API on 'greenland.privacy.network'...

 

In the logs, I see multiple entries of "Line unrecognized:  `PublicKey=' Configuration parsing error".
When I check wg.conf, the "Publickey" entry is indeed blank.  In the example on the github FAQ page, it's populated.  Could this be the issue?
The FAQ page also mentions in A28 that "/config/supervisord.log" should contain a full list of enpoints.  This is incorrect in my case.  My supervisord.log is only a repeating set of logs that look very much like what you see posted above, including that error about the Publickey being missing.
Any of this help?

Edited May 7, 20251 yr by Elmojo
Updates and logs

Ok, so I've done more hunting and digging, and I can maybe narrow this down a little.

After deleting the supervisord.log file and letting it regen, I was able to watch it during a container startup, to see what's happening.  It appears that all goes okay, until it gets to the line

"[info] Trying to connect to the PIA WireGuard API on 'ca-ontario.privacy.network'...", where it just hangs for several minutes. 

 

During this time, checking the docker log shows a recurring loop of:

2025-05-08 11:09:58,617 DEBG 'start-script' stdout output:
[info] Configuring WireGuard...

2025-05-08 11:09:58,865 DEBG 'start-script' stdout output:
[info] Token generated for PIA wireguard authentication

2025-05-08 11:09:58,874 DEBG 'start-script' stdout output:
[info] Trying to connect to the PIA WireGuard API on 'ca-ontario.privacy.network'...

2025-05-08 11:14:59,318 DEBG 'start-script' stdout output:
[info] Attempting to bring WireGuard interface 'up'...

2025-05-08 11:14:59,343 DEBG 'start-script' stderr output:
Warning: `/config/wireguard/wg0.conf' is world accessible

2025-05-08 11:14:59,365 DEBG 'start-script' stderr output:
[#] ip link add wg0 type wireguard

2025-05-08 11:14:59,371 DEBG 'start-script' stderr output:
[#] wg setconf wg0 /dev/fd/63

2025-05-08 11:14:59,374 DEBG 'start-script' stderr output:
Line unrecognized: `PublicKey='
Configuration parsing error

2025-05-08 11:14:59,380 DEBG 'start-script' stderr output:
[#] ip link delete dev wg0

2025-05-08 11:14:59,431 DEBG 'start-script' stdout output:
[warn] WireGuard interface failed to come 'up', exit code is '1'

 

This appears to be the issue, but I don't see any obvious way to address it.

Flipping the VPN_ENABLED flag to 'no' causes the container to start immediately and work perfectly (and downloads FAST, like it never was with the VPN on!), but of course that defeats the whole purpose. lol

I also notice that there's a port number listed in the VPN_INPUT_PORTS field of the template.  Is that correct?  Doesn't PIA auto-assign ports?  I'm wondering if that's something I did way back when I was setting this up about a year ago that's now causing an issue or something.  

Any help greatly appreciated. 

Sorry for the hot mess that is the previous post.  I was trying to piece it all together while hopping back and forth to the hospital.

 

can't access WebUi. WebUI went down.

 

Should I try replacing the wg0 file?

 

Updated my post deleted logs. , I replaced wg0 file. it fixed the webui access issue. in case anyone else has this issue give it a whirl. 

 

Edited May 11, 20251 yr by danheinz

2 hours ago, danheinz said:

I replaced wg0 file. it fixed the webui access issue

Glad that worked for you.  I'm still dead in the water, and no one appears to be available to help, even the gurus like @binhex or @wgstarks, who are normally so quick to respond.
When you say you replaced the wg0 file, where did you get the file or info for the replacement?

This may be my issue as well. I can't access the GUI at all, unless I disable the VPN.

5 minutes ago, Kilrah said:

That gets answered pretty much on each page of this thread...

Get a new configuration file from your VPN provider, possibly with a different endpoint.

I've been back through the past 6-7 pages, and I don't see anything that addresses my issue.  I apologize if I missed it.

PIA isn't supposed to require that sort of manual config. That's the whole point of using them vs others with this container, unless I'm missing something.  Also, I've tried changing the endpoint in the config file (as noted above) with no change.
I did do as much troubleshooting as I could on my own, but I'll need some assistance at this point.

On 5/7/2025 at 12:34 AM, Elmojo said:

 NAME_SERVERS defined as '84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1'

try setting NAME_SERVERS to 1.1.1.1,1.0.0.1, some of the name servers you have defined can be a bit flaky, resulting in name lookup failure.

 

On 5/8/2025 at 4:31 PM, Elmojo said:

I also notice that there's a port number listed in the VPN_INPUT_PORTS field of the template.  Is that correct?  Doesn't PIA auto-assign ports

fyi the template does not contain any ports for VPN_INPUT_PORTS or for OUTPUT ports either, both of which having nothing to do with incoming port assignment (port forwarding), so if that does have a port you must of assigned it.

That's odd, since I don't recall ever having modified the nameservers field, nor the input ports.  I was under the impression that using PIA caused all that stuff to be handled automatically.
Since it appears that my install may be generally borked, I removed the container (and directory) and reinstalled it.
Oddly, the new template looks quite different than the old one.  Even though I was fully updated, the fields were in different orders, and some options were added or moved on the new template.

After installing fresh (using the default options, and my PIA creds), I'm getting the exact same errors...

The log and supervisord both stall at:

2025-05-11 16:51:25,954 DEBG 'start-script' stdout output:
[info] Trying to connect to the PIA WireGuard API on 'nl-amsterdam.privacy.network'...

 

No idea what to try next...

 

  

7 minutes ago, Elmojo said:

I was under the impression that using PIA caused all that stuff to be handled automatically.

incoming ports are assigned automatically for you for pia, that is correct, as mentioned VPN_INPUT_PORTS has nothing to do with incoming port assignment.
 

8 minutes ago, Elmojo said:

Oddly, the new template looks quite different than the old one.  Even though I was fully updated, the fields were in different orders, and some options were added or moved on the new template.

This is totally expected, template changes do not get pushed out, and as the template has been updated to the newer format it will look different.
 

14 minutes ago, Elmojo said:

[info] Trying to connect to the PIA WireGuard API on 'nl-amsterdam.privacy.network'...

 

No idea what to try next...

I will need to see a log to help further, please see the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md#unraid-users

On 5/13/2025 at 4:26 AM, binhex said:

I will need to see a log to help further

No problem, see attached, thanks!

 

EDIT: Docker Run:

docker run
  -d
  --name='binhex-qbittorrentvpn'
  --net='bridge'
  --privileged=true
  -e TZ="America/New_York"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Tower"
  -e HOST_CONTAINERNAME="binhex-qbittorrentvpn"
  -e 'VPN_ENABLED'='yes'
  -e 'VPN_USER'='p0494908'
  -e 'VPN_PASS'='e74MuKAiVY'
  -e 'VPN_PROV'='pia'
  -e 'VPN_CLIENT'='wireguard'
  -e 'STRICT_PORT_FORWARD'='yes'
  -e 'ENABLE_PRIVOXY'='no'
  -e 'ENABLE_SOCKS'='no'
  -e 'SOCKS_USER'='admin'
  -e 'SOCKS_PASS'='socks'
  -e 'LAN_NETWORK'='192.168.1.0/24'
  -e 'WEBUI_PORT'='8080'
  -e 'VPN_INPUT_PORTS'=''
  -e 'VPN_OUTPUT_PORTS'=''
  -e 'DEBUG'='true'
  -e 'VPN_OPTIONS'=''
  -e 'ENABLE_STARTUP_SCRIPTS'='no'
  -e 'USERSPACE_WIREGUARD'='no'
  -e 'NAME_SERVERS'='1.1.1.1,1.0.0.1'
  -e 'PUID'='99'
  -e 'PGID'='100'
  -e 'UMASK'='000'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:8080]'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/qbittorrent-icon.png'
  -p '8080:8080/tcp'
  -p '8118:8118/tcp'
  -p '9118:9118/tcp'
  -p '58946:58946/tcp'
  -p '58946:58946/udp'
  -v '/mnt/user/appdata/binhex-qbittorrentvpn':'/config':'rw'
  -v '/mnt/user/downloads/':'/data':'rw'
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'ghcr.io/binhex/arch-qbittorrentvpn'
8e9aaa9fc1bff3fbd4adc8be98b58ee16f050d8d537f82fbe8a9cae0685aceb7

 

 

supervisord.log

Edited May 16, 20251 yr by Elmojo
Added Docker Run, updated log file with DEBUG version, Uploaded log without creds.

Hello!
I've been scouring this forum and others, and it appears that I've found a new and exciting way to screw up.

My binhex-QbittorrentVPN docker container was working fine and dandy for the last little while, but due to a screwup on my side, i had to reinstall the container. I can't get it working for the life of me now.  I created a new Wireguard config, I've made sure none of my ports are goofy, I ABSOLUTELY have confirmed that the LAN_Network var is correct.  But i Cannot access the WebUI to save my life. If i disable the VPN, it still fails to load the webUI... just faster.

For the sake of potentially saving time, the thing i messed up before having to reinstall the docker image was the config files on my flash drive, I accidentally deleted them, so everything was still running... but the Unraid webui couldn't actually access them.  Every other container I've reinstalled (a mittful of the binhex Starr apps) are working fine.

I'd appreciate any help, cause this is driving me nuts.


 

Command Execution supervisordlog

9 minutes ago, CoCoMcBeats said:

i Cannot access the WebUI to save my life

Welcome to the club.

31 minutes ago, CoCoMcBeats said:

Hello!
I've been scouring this forum and others, and it appears that I've found a new and exciting way to screw up.

My binhex-QbittorrentVPN docker container was working fine and dandy for the last little while, but due to a screwup on my side, i had to reinstall the container. I can't get it working for the life of me now.  I created a new Wireguard config, I've made sure none of my ports are goofy, I ABSOLUTELY have confirmed that the LAN_Network var is correct.  But i Cannot access the WebUI to save my life. If i disable the VPN, it still fails to load the webUI... just faster.

For the sake of potentially saving time, the thing i messed up before having to reinstall the docker image was the config files on my flash drive, I accidentally deleted them, so everything was still running... but the Unraid webui couldn't actually access them.  Every other container I've reinstalled (a mittful of the binhex Starr apps) are working fine.

I'd appreciate any help, cause this is driving me nuts.


 

Command Execution 1.4 kB · 0 downloads supervisordlog 38.11 kB · 0 downloads

no problem there in the logs, what is the ip address of the machine running the web browser you are using to connect to the web ui?

23 minutes ago, Elmojo said:

Welcome to the club.

Just to clarify here, the symptom of no access to the web ui does not mean you have the same issue (there are literally dozeens of reasons for this), or that there is an underlying issue with the image (i use this image with zero issue). 

 

So going back to your previous post with the log, it looks like something on your lan is blocking access to the PIA API, are you running pfsense/opnsense or similar?, also have you configured tailscale?, if so Please see Q36 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

1 hour ago, binhex said:

no problem there in the logs, what is the ip address of the machine running the web browser you are using to connect to the web ui?

So, my router reports the IP of this machine as 192.168.1.105, as do system settings (i'm on a mac atm). when i run ifconfig i get a 127 number in the first block of text, but i'm only telling you this because i'm not sure if it's important and i think, while i wait for you to respond, that i'm going to try a windows machine too for giggles.

**Edit** 

Ok, So i hopped on my laptop running fedora (192.168.1.189) and tried and i still can't access the webui from there.  I saw your post to the other individual about tailscale, so i tried disabling that (I wasn't really using it) but disabling tailscale doesn't resolve my problems (I was never connecting via tailscale, just for the record.)

I don't know if there's some kind of strange config that i'm not seeing anywhere that could be causing this container to hate me right now, It's been working like a dream for the last 6 months or so. So thank you so much for the work you've done on this, and the help so far.

Edited May 15, 20251 yr by CoCoMcBeats
adding information

4 hours ago, binhex said:

it looks like something on your lan is blocking access to the PIA API, are you running pfsense/opnsense or similar?, also have you configured tailscale?

Yes, I have a pfsense firewall/router, but its config hasn't changed in many months. 

I do also use Tailscale, but it also has not had a configuration change in months, and works fine for all my other connections.
Checking the FAQ Q36, I see that it's referencing 'MagicDNS', which I don't use.  I have it disabled in Tailscale, and always have.
It conflicts with the settings I use to connect to my server at work.
I notice that part of the workaround is "TAILSCALE_USERSPACE_NETWORKING is set to false - Fix is to set this to true"
I don't have that flag in my template for qBitVPN, even in advanced view.  Where would I find it?  Does it need to be added manually?

 

EDIT: I'm also still seeing this in the log, which seems significant:
Line unrecognized: `PublicKey='
Configuration parsing error

Edited May 16, 20251 yr by Elmojo
added log note

@Elmojo

I popped back in to see if there was a response to my thing and saw your post.  I think i know what part of your problem is.  Earlier in the thread, you were talking to somebody about replacing the wg0 file, and i think you need to do that. I'm using protonvpn, so i don't know what the exact steps are for you, but i bet that's part of your problem (I had the same config parsing error.)

So what you need to do is go to PIA and REDO the wireguard setup.  I think what's happened is that you have redownloaded the cert, but after a set amount of time, PIA hides the public/secret keys.  I had to delete my old wireguard setup, create a new one, download THAT config file, rename it to wg0.conf and then slap it into the appdata/binhex-qbittorrentvpn/wireguard folder.

Also, ftr, you haven't removed some sensitive information from your logs, so your un/pw from your provider are hanging out for the whole world to see. you might want to erase those from your posts and then generate new creds from PIA.

sorry i can't give you super clear step by steps, as i said, i use a different provider. 

21 hours ago, binhex said:

no problem there in the logs, what is the ip address of the machine running the web browser you are using to connect to the web ui?

@binhex I think i fixed it AND i think i know what caused it. 

I was trying to teach myself to fish, and was looking at my logs to see if anything stood out, and there it was. 

Even though i'd changed the port from 8080 to 8081, (by clicking Edit, and changing the port number in the modal) When i saved, the command execution kept spitting out

-p '8081:8080/tcp'

When i looked at other docker containers, both sides matched. 

So I figured i'd just delete the one docker that was also using 8080 (Scrutiny) and try putting your container back to 8080 and it immediately worked. and now the command execution reads

-p '8080:8080/tcp'

I am not a programmer by any stretch of the imagination, but if this is helpful to you in any way, Yay! if not... uh, thank you for your patience while i fixed it myself and wasted your time.

39 minutes ago, CoCoMcBeats said:

Earlier in the thread, you were talking to somebody about replacing the wg0 file, and i think you need to do that

I was just asking why replacing the wg0 file was needed, or where that would even come from, since when using PIA with this container, there's not supposed to be any manual configuration involved.  That's the main reason why I switched over to PIA.  @binhex confirmed that a few posts back, I believe.
Thanks for the heads up on the exposed creds.  I had obscured them in the previous version, but probably forgot to do it when I uploaded the revised version with the debug info.  It kinda baffles me that that info is shown in the logs in cleartext anyway.

Edited May 16, 20251 yr by Elmojo
wording clarification

14 minutes ago, Elmojo said:

That wasn't me.  When using PIA with this container, there's not supposed to be any manual configuration involved, which is the main reason why I switched over to PIA.  @binhex confirmed that a few posts back, I believe.
Thanks for the heads up on the exposed creds.  I had obscured them in the previous version, but probably forgot to do it when I uploaded the revised version with the debug info.  It kinda baffles me that that info is shown in the logs in cleartext anyway.

It was you, from this post

 

 

On 5/11/2025 at 12:20 PM, Elmojo said:

I've been back through the past 6-7 pages, and I don't see anything that addresses my issue.  I apologize if I missed it.

PIA isn't supposed to require that sort of manual config. That's the whole point of using them vs others with this container, unless I'm missing something.  Also, I've tried changing the endpoint in the config file (as noted above) with no change.
I did do as much troubleshooting as I could on my own, but I'll need some assistance at this point.

This part of the config IS required for any wireguard setup.  you would have had to do it when you originally had your stuff working, and like me, you probably just thought that you could just use the old wg0 config, even though the information in it is obfuscated..

I'm not sure it's the only issue you're having, but if the public key isn't getting parsed correctly, you'll never connect to the VPN, and qbittorrentvpn won't open the web ui.

 

1 hour ago, CoCoMcBeats said:

Even though i'd changed the port from 8080 to 8081, (by clicking Edit, and changing the port number in the modal) When i saved, the command execution kept spitting out

-p '8081:8080/tcp'

sounds like this might of been relevant, see q4:- https://github.com/binhex/documentation/blob/master/docker/faq/qbittorrentvpn.md

5 hours ago, CoCoMcBeats said:

It was you, from this post
 

This part of the config IS required for any wireguard setup.  you would have had to do it when you originally had your stuff working, and like me, you probably just thought that you could just use the old wg0 config, even though the information in it is obfuscated..

I'm not sure it's the only issue you're having, but if the public key isn't getting parsed correctly, you'll never connect to the VPN, and qbittorrentvpn won't open the web ui.

I edited my post above earlier to clarify what I meant, that I wasn't asking about editing the wg0 file.

Regardless, if there is manual setup involved, I have no recollection of it.  I may need to just wipe this whole thing and start over again.
I've just been dealing with this for so long now that I've honestly about forgotten what I have and haven't tried. lol

So I'm starting over, but what's is really getting me is that when I try to follow the initial setup guide, as linked in Post #1 of this thread, it says nothing about WG, only OpenVPN.  That's why I was thinking there was no need for the manual config, since I thought I recalled that Binhex said that switching to WG negated the need for all the manual setup.  I'm probably remembering that wrong, it's been a while.

Anyway, I'm still stuck, since I don't see any way to manually download any sort of WG config for PIA, and the container doesn't appears to be setting it up automatically for me, so now what do I do....?
Again, I'm very sorry to be so needy.  I normally can suss things out better on my own, but my brain is a little bit fried from caring for a sick wife, so I'll beg for some extra patience, and thank everyone for their help!

 

I'm struggling a bit with the guidance on port forwarding for a customs vpn. I have been provisioned a port through my VPN dashboard and have entered that port as the listening port within qBittorent but it is still indicating that is behind a firewall in the qBittorrent status bar.  Do I also need to manually add that same port to my docker settings and forward it through my firewall? I've read the FAQ but I'm still finding it a bit unclear.

 

 

so we still have no fix for the qbit torrents all just disappearing? it only happens for me in firefox and not in edge, which makes me think it's a browser specific issue.

I see all of these errors in the networking tab in firefox after the page initially loads and i see all torrents then they disappear after a few seconds and i see a stream of these errors shown in the image below. I'm happy to provide any other information that would help solve this. I do not have any other issues with any other containers in unraid nor have i added any new extensions to firefox.

2 minutes ago, hmoney007 said:

so we still have no fix for the qbit torrents all just disappearing? it only happens for me in firefox and not in edge, which makes me think it's a browser specific issue.

I see all of these errors in the networking tab in firefox after the page initially loads and i see all torrents then they disappear after a few seconds and i see a stream of these errors shown in the image below. I'm happy to provide any other information that would help solve this. I do not have any other issues with any other containers in unraid nor have i added any new extensions to firefox.

i'd said this would be an qBittorrent issue. But i just tried with my Firefox and they bleep for a sec but came back. I wouldn't think this would be a Binhex issue