I had been having the same problem others have mentioned recently: With VPN on I could no longer access the web UI.

 

Turning VPN off allowed me to access the web UI, but with the obvious downside of no VPN. As soon as VPN was reenabled and the container restarted, the web UI would be inaccessible again.

 

I found the problem in the log for this container. My VPN provided (Proton) had apparently disabled port forwarding on the server set in my wg0.conf file. That was causing VPN to fail. The VPN failure interfered with the scripts / startup, so it was never getting to the "qBittorrent process listening on port 8585" point.

 

I went to my VPN provider's site and generated a new .conf file using a new server that was specifically enabled for port forwarding, then placed that file in appdata/binhex-qbittorrentvpn/wireguard/ and renamed it to wg0.conf

 

Turns out in my case it had nothing to do with my local system software or configuration at all!

 

Not sure if anyone else is suffering from this seemingly very specific problem, but since others are reporting similar symptoms I thought I'd mention. Always worth reading the log.

 

Relevant bit from my supervisord.log:
 

2025-03-09 01:54:43,125 DEBG 'start-script' stdout output:
[info] Script started to assign incoming port for 'protonvpn'

2025-03-09 01:54:43,125 DEBG 'start-script' stdout output:
[info] WireGuard interface 'up'

2025-03-09 01:54:45,150 DEBG 'start-script' stdout output:
initnatpmp() returned 0 (SUCCESS)
using gateway : 10.2.0.1
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned -7 (FAILED)

2025-03-09 01:54:45,150 DEBG 'start-script' stderr output:
readnatpmpresponseorretry() failed : the gateway does not support nat-pmp
  errno=111 'Connection refused'

2025-03-09 01:54:45,150 DEBG 'start-script' stdout output:
[warn] ProtonVPN endpoint '149.36.48.129' is not enabled for P2P port forwarding, skipping port forward assignment...
[info] Script finished to assign incoming port

2025-03-09 03:24:40,200 DEBG 'watchdog-script' stdout output:
[info] qbittorrent incoming port closed, marking for reconfigure

2025-03-09 03:24:43,295 DEBG 'start-script' stdout output:
[info] Sending 'down' command to WireGuard due to port closed...

Edited March 11, 20251 yr by sofauxboho
added log snippet

16 minutes ago, sofauxboho said:

I went to my VPN provider's site and generated a new .conf file using a new server that was specifically enabled for port forwarding, then placed that file in appdata/binhex-qbittorrentvpn/wireguard/ and renamed it to wg0.conf

Follow this carefully:-

Please see Q31 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

1 hour ago, binhex said:

Follow this carefully:-

Please see Q31 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Yup, I followed your instructions there for my original setup and they worked great! Thank you for those. It only broke when ProtonVPN seemingly disabled port forwarding on the server selected in my wg0.conf. 

 

Generating a new .conf with a new ProtonVPN server (that does allow port forwarding) has fixed this problem for me.

 

While I have your attention I'll mention that this part in the 4th bullet of A31:

scroll down to VPN_USER and append the string +pmp to the end of the username, e.g. zuqWGtyy7SMGQM8C+pmp

Seems to only apply to OpenVPN? But it is directly after the Wireguard instructions (in the third bullet), implying it needs to be done for Wireguard too. I found that a little confusing. 

 

@binhexThank you again for all you do!

4 minutes ago, sofauxboho said:

Seems to only apply to OpenVPN? But it is directly after the Wireguard instructions (in the third bullet), implying it needs to be done for Wireguard too. I found that a little confusing. 

That is good feedback, thanks, i will take a look.

20 hours ago, jwelch said:

You'll need to gather these, as shown in the link binhex provided:

 

Gather Command execution

Left click the container and select 'Edit', make any change to a value, then switch it back to what it was and click on 'Apply', then copy and paste the 'Command execution' shown to a file, ensuring to remove all reference to username and password.

Go to support thread (left click icon and select 'Support') and then attach (do NOT paste) the 'Command execution' output file but do not 'Submit Reply', please move onto the next step below.

Gather Supervisor log

Delete any existing log file located at /config/supervisord.log, where /config is the host path for the container.

Left click container and select 'Edit' then set the 'Container Variable' for DEBUG to a value of true and click 'Apply'.

Wait 5 mins for it to completely finish initialising, then open the log file at /config/supervisord.log and remove all reference to username and password from the file, then save the log somewhere.

Attach (do NOT paste) the log output file from Step 3 to the post and click on 'Submit Reply'.

 

See my prior reply for reference if you like.

 

This is what i've already done. Files attached....

docker.txt supervisord.log

21 minutes ago, Threshermaw said:

 

This is what i've already done. Files attached....

docker.txt 1.42 kB · 1 download supervisord.log 26.38 kB · 0 downloads

from your log:-

2025-03-10 18:19:28 AUTH: Received control message: AUTH_FAILED

Please see Q16 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

I've been having the recent issue of the WebUI being inaccessible with VPN turned on. I have wireguard configured.
The log stalls on "[info] NAME_SERVERS defined as....."

From this forum I've followed all the advice:
- Adding :5.0.3-1-01 to Repository: gets it working again, but then I'm stuck at this version.
- My LAN_NETWORK is set correctly, and has always worked.
- My VPN_INPUT_PORTS is set correctly, and has always worked.
- I changed my PIA account password with no luck.
- I use a custom network, not bridge, it's always worked correctly, and I like my setup. However, setting it back to bridge did nothing to correct my issue.
 

What I found to correct my issue:
- Shutdown binhex-qbittorrentvpn.
- Deleted perms.txt from /appdata/binhex-qbittorrentvpn (this will reset permissions upon restart).
- While I was there, I deleted my supervisord.log as it had grown rather large, and also deleted its rotation logs .1, .2. etc...
- Renamed (deleted would have also worked) wg0.conf from /appdata/binhex-qbittorrentvpn/wireguard (this recreates it upon restart and pulled new keys when it did).
 

Note: I have had permission issues in the past and have gone through all my dockers and added PUID:99, PGID:100, UNMASK:000. My binhex-qbittorrentvpn runs as Privileged (If I remember right there was a reason for that). I've had some Dockers for a long time and these permission settings may have been introduced/updated along the way.

I've set up this docker via AirVPN & connected it to *arrs which works well.

 

The issue I'm having is whenever I add a file through *arrs or manually via magnet link it spits out an error (see below).

 

It does seem to be a permission error but I cannot seem to fix it. When I changed the PUID to my user read/write permission I'm still getting that error. I've also created a new user specifically for the app, changed the download location's ownership to that user and still get that error. Any suggestions?

 

File error alert. Torrent: "*Torrent Name*". File: "/plexmedia/torrents/*Torrent Name*/*File Name*". Reason: "*Torrent Name* file_open (/plexmedia/torrents/*Torrent Name*/*File Name*) error: Permission denied"

 

 

20 hours ago, essentialgeek said:

I've been having the recent issue of the WebUI being inaccessible with VPN turned on. I have wireguard configured.
The log stalls on "[info] NAME_SERVERS defined as....."

From this forum I've followed all the advice:
- Adding :5.0.3-1-01 to Repository: gets it working again, but then I'm stuck at this version.
- My LAN_NETWORK is set correctly, and has always worked.
- My VPN_INPUT_PORTS is set correctly, and has always worked.
- I changed my PIA account password with no luck.
- I use a custom network, not bridge, it's always worked correctly, and I like my setup. However, setting it back to bridge did nothing to correct my issue.
 

What I found to correct my issue:
- Shutdown binhex-qbittorrentvpn.
- Deleted perms.txt from /appdata/binhex-qbittorrentvpn (this will reset permissions upon restart).
- While I was there, I deleted my supervisord.log as it had grown rather large, and also deleted its rotation logs .1, .2. etc...
- Renamed (deleted would have also worked) wg0.conf from /appdata/binhex-qbittorrentvpn/wireguard (this recreates it upon restart and pulled new keys when it did).
 

Note: I have had permission issues in the past and have gone through all my dockers and added PUID:99, PGID:100, UNMASK:000. My binhex-qbittorrentvpn runs as Privileged (If I remember right there was a reason for that). I've had some Dockers for a long time and these permission settings may have been introduced/updated along the way.

 

This helped with me, specifically I deleted perms.txt and reinstalled the container thanks brother

I'm trying to get a 2nd qbittorrentvpn client up and running.  Actually, it may be running, but I can't access the gui to tell for sure.  The log doesn't show any errors, and the container is started.  I suppose there's a way to tell for sure from the console.

Anyway, I tried to copy the config from the first (working) container, and just change the conflicting host ports and DL folder.  The configs are a little different when I go to edit, though.  The original has host port 1, 2, 3, 4, key 1, etc.  The new one has names for all those.

When I try to open the container, I get a message that the site can't be reached.  I suspect it's something simple with the ports.  Can anyone help me out?

 

original container
  Host Port 1: 6881
Container Port: 6881

  Host Port 2: 6881
Container Port: 6881

  Host Port 3: 8080
Container Port: 8080

  Host Port 4: 8118
Container Port: 8118

  Key 9: 8080
Container Variable: WEBUI_PORT

New Container
  Port: Web Interface: 8082
Container Port: 8080

  Port: Privoxy: 8120
Container Port: 8118

Variable: WEBUI_PORT: 8082
Container Variable: WEBUI_PORT

Edited March 15, 20251 yr by Cybernaut

5 hours ago, Cybernaut said:

I'm trying to get a 2nd qbittorrentvpn client up and running.  Actually, it may be running, but I can't access the gui to tell for sure.

ive seen this a couple of times where the issue is actually cookie related, try accessing the second instance from a completely different browser to the first instance.

That doesn't appear to be it.  As well as trying another browser, I couldn't telent to it.  I could to the original on 8080.

 

Hi, all,

 

I too am having a similar issue to others, no longer being able to access the WebUI with the VPN running. Everything was working fine until a few days ago when I logged in one morning and it had just stopped working and no changes had been made. I've gone through a lot of the posts here and elsewhere looking for similar errors that others had been able to fix, but I'm not seeing anything in my logs that are similar. As far as I can tell, everything is starting up properly, the VPN connects fine, the container says qbittorrent is up and listening on port 8080, but I can't access the WebUI anymore unless I disable the VPN.

 

I hope I'm a dummy and missing something simple.

 

EDIT: I did just now see the other user who you said needed to change to use Bridge networking, which I confirmed does get me access to the UI, but until a few days ago and for the last 3 weeks I've had it up, it was running perfectly on Br0 with a static IP. I can certainly keep it running on Bridge (after changing conflicting UI port and reconfiguring my *Arr apps), but having a static IP was very nice as I don't have Proxy Manager or custom DNS running just yet.

 

Thanks!

docker run.txt supervisord.log

Edited March 20, 20251 yr by sqrlmasta

10 hours ago, sqrlmasta said:

EDIT: I did just now see the other user who you said needed to change to use Bridge networking, which I confirmed does get me access to the UI, but until a few days ago and for the last 3 weeks I've had it up, it was running perfectly on Br0 with a static IP. I can certainly keep it running on Bridge (after changing conflicting UI port and reconfiguring my *Arr apps), but having a static IP was very nice as I don't have Proxy Manager or custom DNS running just yet.

This image was designed around the concept of bridge, as MACVLAN and IPVLAN were simply not available at the time, and thus bridge is your best bet for getting everything working.

 

I did look into custom bridge some time ago and openvpn with a custom bridge did not permit access to the web ui for me, so i'm not sure how it did work for you. In any case, the image has not been rebuilt so i don't believe it's any change to the image that has caused the lack of access to the web ui, so i can only assume something on your system.

So the TLDR is switch to bridge network and be happy, or try and work out what's changed on your system and revert it and see if you can use custom bridge again.

 

Thanks, binhex. 

 

I reconfigured it along with connected app and have it working again using Bridge networking, so I'll be happy with that. Definitely no deal-breaker here, just super odd.

 

Appreciate all you do for the community. Thanks!

Apologies if this is a stupid question or has been asked before but I couldn't find any info searching the forum. I am setting up qbittorrent using AirVPN. Downloads work fine and everything seems to be correctly routing through the AirVPN IP, but upload speeds are basically nonexistent. I figured this was a port fowarding issue and when I checked the qbittorrent startup logs I get the message:

 

"[info] VPN provider 'airvpn' not supported for automatic port forwarding, skipping incoming port assignment".

 

I thought AirVPN did support automatic port forwarding, but maybe I am missing something here. Has anyone else run into this issue? Any guidance would be appreciated.

On 3/19/2025 at 6:15 PM, sqrlmasta said:

EDIT: I did just now see the other user who you said needed to change to use Bridge networking,

Thanks!  That worked for my issue of running a second instance.

I am having a strange issue using PIA via Wireshark ( Port forwarding enabled connection ), the container boots up, in the log i see this:

 

Successfully retrieved external IP

Successfully assigned and bound incoming port '21407'

qBittorrent incoming port 6881 and VPN incoming port 21407 different, marking for reconfigure

qBittorrent config file already exists, skipping copy

 

then qBittorrent comes online, however the Port in the GUI isn't updated and the status is "firewalled"

if i manually change the port to the port listed in this case '21407' the firewalled status goes away and it seems to function fine until the next reboot where the port is a new random port from PIA but qBittorrent is still set to the previous value.

 

so every reboot i need to manually update the port in qBittorrent to match whats in the logs.

Edited March 22, 20251 yr by Duwayne

Pulling my hair out over here.  Port 8080 was in use for SABNZBD. Changed the Port: Web Interface: 8082

I then scrolled down and changed Variable: WEBUI_PORT: 8082

 

I can't connect to the WebUI in either Firefox nor, Edge. 

 

I am running the container in bridge mode.  I've tried it with VPN ON and VPN OFF makes no difference.  Connection times out.

 

I can go to my client area in AirVPN and see that the Unraid server has connected to the service so it has to be up and running?   I just can not access the WebUI no matter what.

27 minutes ago, CoZ said:

I then scrolled down and changed Variable: WEBUI_PORT: 8082

Set that one back.

1 hour ago, Kilrah said:

Set that one back.

Changed it back to 8080.  Left Variable: WEBUI_PORT:8082. 

 

Restarted container

 

Typed into browser IP:8082 - this time it doesn't time out or, refuse to connect, I just get Unauthorized

 

Found the solution: https://github.com/linuxserver/docker-qbittorrent/issues/243

 

added that line to the .conf file and now I am in the login screen. 

Edited March 26, 20251 yr by CoZ

I updated unraid from 7.0 to 7.0.1 and maybe this caused a problem with privoxy working (unreachable from my windows machine that i browse on) .  I didn't change anything in the container etc but since then i can't reach it from chrome/foxyproxy on another machine. - if i recall i should also be able to type in my unraid server local address 192.168.1.154:8118 and reach it that way as well?  Here is my docker config command - and i am setting my foxyproxy to connect to 192.168.1.154 http 8118

 docker run
  -d
  --name='binhex-qbittorrentvpn'
  --net='bridge'
  --pids-limit 2048
  --privileged=true
  -e TZ="America/Anchorage"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Tower"
  -e HOST_CONTAINERNAME="binhex-qbittorrentvpn"
  -e 'VPN_ENABLED'='yes'
  -e 'VPN_USER'='xxxxxxx'
  -e 'VPN_PASS'='xxxxxxxxx'
  -e 'VPN_PROV'='pia'
  -e 'VPN_CLIENT'='openvpn'
  -e 'VPN_OPTIONS'=''
  -e 'STRICT_PORT_FORWARD'='yes'
  -e 'ENABLE_PRIVOXY'='yes'
  -e 'WEBUI_PORT'='8080'
  -e 'LAN_NETWORK'='192.168.1.0/24'
  -e 'NAME_SERVERS'='209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,37.235.1.177,84.200.70.40,1.0.0.1'
  -e 'ADDITIONAL_PORTS'=''
  -e 'DEBUG'='false'
  -e 'UMASK'='000'
  -e 'PUID'='99'
  -e 'PGID'='100'
  -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 '6881:6881/tcp'
  -p '6881:6881/udp'
  -p '8080:8080/tcp'
  -p '8118:8118/tcp'
  -v '/mnt/user/Torrents':'/data':'rw'
  -v '/mnt/user/appdata/binhex-qbittorrentvpn':'/config':'rw'
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-qbittorrentvpn'

 

 

in addition it appears that privoxy is up and running on the logs for qbittorrent vpn and that i am connecting to torrents with my PIA address properly (as far as i can tell) - Here is the log

2025-03-27 08:33:14,812 DEBG 'start-script' stdout output:
[info] vietnam.privacy.network
[info] taiwan.privacy.network
[info] sg.privacy.network
[info] sweden.privacy.network
[info] gt-guatemala-pf.privacy.network
[info] panama.privacy.network
[info] de-germany-so.privacy.network
[info] swiss.privacy.network
[info] egypt.privacy.network
[info] aus-melbourne.privacy.network
[info] ec-ecuador-pf.privacy.network
[info] santiago.privacy.network
[info] aus-perth.privacy.network
[info] tr.privacy.network

2025-03-27 08:33:17,487 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '34218'

2025-03-27 08:33:32,586 DEBG 'watchdog-script' stdout output:
[info] qBittorrent listening interface IP 0.0.0.0 and VPN provider IP 10.2.110.98 different, marking for reconfigure

2025-03-27 08:33:32,591 DEBG 'watchdog-script' stdout output:
[info] qBittorrent not running

2025-03-27 08:33:32,596 DEBG 'watchdog-script' stdout output:
[info] Privoxy not running

2025-03-27 08:33:32,596 DEBG 'watchdog-script' stdout output:
[info] qBittorrent incoming port 6881 and VPN incoming port 34218 different, marking for reconfigure

2025-03-27 08:33:32,597 DEBG 'watchdog-script' stdout output:
[info] qBittorrent config file already exists, skipping copy
[info] Removing session lock file (if it exists)...

2025-03-27 08:33:32,637 DEBG 'watchdog-script' stdout output:
[info] Attempting to start qBittorrent...

2025-03-27 08:33:32,642 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process started

2025-03-27 08:33:32,642 DEBG 'watchdog-script' stdout output:
[info] Waiting for qBittorrent process to start listening on port 8080...

2025-03-27 08:33:33,555 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process listening on port 8080

2025-03-27 08:33:33,992 DEBG 'watchdog-script' stdout output:
[info] Attempting to start Privoxy...

2025-03-27 08:33:34,998 DEBG 'watchdog-script' stdout output:
[info] Privoxy process started
[info] Waiting for Privoxy process to start listening on port 8118...

2025-03-27 08:33:35,009 DEBG 'watchdog-script' stdout output:
[info] Privoxy process listening on port 8118

I suspect I am doing something monumentally stupid but have come to ask for help here...

 

Have previously been using the ARR stack successfully with SONARR/RADARR/PROWLARR/Overseerr and Binhex qbittorrentVPN for over a year with all the automations just working fine. Then it stopped working so I took the time to change my processes away from Space Invader One's guides to rebuild everything using Trash Guides and it worked fine for another several months or so...

 

For the last few weeks, I'm getting sporadic and now constant issues where automated (and manually added) torrents refuse to download and end up in an errored state.

 

Have managed to identify that the reason for this is invariably that the permissions on the created folders in my data/torrents and data/media folders have been created with the wrong PUID and PGID (shows as "???" in Krusader) and often with MODE 000 for Owner, Owning Group and Others. Files without folders can sometimes succeed in being added and download successfully but they won't upload.

 

Manually changing ownership and cascading settings to files folders sometimes works, other times I need to do the change at each folder level and at file level.

 

I have confirmed that the PUID (99) and PGID (100) and UMASK (000) are correctly set for all ARRs and qbittorrent in the settings in Unraid docker container settings. I have at various points, individually and sequentially done the following:

1. Reinstalled all the Arrs
2. made sure that the Set permissions is not checked in Media Management section of all the arrs...
3. These were left as default value of CHMOD 755 and chown group is blank and the set permissions box unchecked (so should do nothing)
4. Also tried with these set to CHMOD 777 apply Group 100 - with the set permissions box checked to see what happened, no change in behaviour
5. Deleted the QBIT supervisordX.logs
6. Deleted the QBIT perms.txt and restarted qbittorrent container.
7. Manually updated ownership in Krusader (using root permissions) to change to "nobody:users" and applied effectively CHMOD 777 to all files.
8. Have also run CHOWN nobody:users and CHMOD 777 to mnt/user/data recursively which did not fix the issue as newly created files/folders in /torrents or /media do not have the correct ownership.
9. Also tried to run docker safe new perms and it seems to generate weird additional PUID/PGID which I cannot recall ever having used... PGID 3007, for example...

 

 

**UPDATE 3-Apr**

Not sure if this is related but in a last ditch attempt to fix things on the data/torrents and now data/media side, I used Krusader to CHMOD 777 for Owner, Owning Group, Others and Mask including the same Owner groups with (default) in the name.

 

Seems fixed for now.

 

 

Edited April 5, 20251 yr by DrBazUK

Is there any way to setup the WG VPN in a fail over configuration? It would be nice to have it automatically try another server if the first one fails. Proton VPN likes to take their servers down for maintenance, other times they're just full.

Any solution to the Host not found (non-authorative) error? If I reboot it tends to go away, but it's a persistent error.