I'm having a problem where I suddenly can't access the ui if I have a VPN enabled as the connection times out. If I disable the vpn I can connect again.

In the logs I get: "[warn] Failed to bring 'down' WireGuard kernel implementation"

Does this mean my implementation of the VPN is incorrect? I don't understand how a problem with the vpn would affect the ui.

So I have QBittorrent implemented with Gluetun using the container network, on 5.1.4 it works without issue, when upgrading to any of the 5.2 releases it seems the logs just loop and it does not ever connect. Is this a known issue ?

Rollback to 5.1.4 after updating fixes and it connects again without issue.

Config.toml is configured on the gluetun side.

EDIT: This seems to have been resolved on 5.2.1

Edited June 1Jun 1 by DeadChimi

Hey Binhex,

Currently using your deluge container and it's working great. Wanted to replace it with the qBittorrent container because deluge web doesn't allow a most of the plugins.

The qBittorrent with container networking through gleutun works as does accessing the UI through gluetun, but when you enable the GLEUTUN_INCOMING_PORT for auto port forwarding one of the scripts gets a permission error and it starts looping.

Edited June 1Jun 1 by oogasplada

7 minutes ago, oogasplada said:

but when you enable the GLEUTUN_INCOMING_PORT for auto port forwarding one of the scripts gets a permission error and it starts looping.

i assume by permission error you mean the 'forbidden' message right?, i shall investigate that, as for the looping that is totally expected, the script monitors the incoming port to ensure its still open, it will do this every 60 seconds.

5 minutes ago, binhex said:

i assume by permission error you mean the 'forbidden' message right?, i shall investigate that, as for the looping that is totally expected, the script monitors the incoming port to ensure its still open, it will do this every 60 seconds.

Yes, I meant the forbidden message when I said permissions. I thought it was causing a loop when trying it ~ a week ago but I was wrong there, nothing is looping today.

I am on unraid version 7.3.1 if it helps.

23 minutes ago, oogasplada said:

Yes, I meant the forbidden message when I said permissions. I thought it was causing a loop when trying it ~ a week ago but I was wrong there, nothing is looping today.

I am on unraid version 7.3.1 if it helps.

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

9 minutes ago, binhex said:

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

Here they are

supervisord.log run command.txt

18 hours ago, oogasplada said:

Here they are

supervisord.log run command.txt

ok i think i see the issue here, its around authentication with qbittorrent in order to set the incoming port, it looks like the option that previously permitted this now has been deprecated and removed, so you will need to add the following to the qbittorrent container:

key: QBITTORRENT_WEBUI_USER

value: <your qbittorrent web ui username>

and

key: QBITTORRENT_WEBUI_PASSWORD

value <your qbittorrent web ui password>

to add these follow the instuctions here for Q8:- https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md

please also ensure you 'force update' to pull down the latest image.

Thanks for the above @binhex I added the variables above, pulled the latest image and it connects for a moment then drops.

Without restarting my Gluetun container I rolled back to 5.1.4-2-01 and it connected without issue. Attached the section of the logs where this happens. Im back on 5.1.4-2-01 until the 5.2 releases become more stable. I'm happy to test/help however needed.

new 2.txt

2 hours ago, DeadChimi said:

Thanks for the above @binhex I added the variables above, pulled the latest image and it connects for a moment then drops.

Without restarting my Gluetun container I rolled back to 5.1.4-2-01 and it connected without issue. Attached the section of the logs where this happens. Im back on 5.1.4-2-01 until the 5.2 releases become more stable. I'm happy to test/help however needed.

new 2.txt

There is no issues with 5.2, im using it myself via this container and gluetun, no issue, if you fancy helping out then go back to latest and then do the following (i need full log):- 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

2 hours ago, binhex said:

There is no issues with 5.2, im using it myself via this container and gluetun, no issue, if you fancy helping out then go back to latest and then do the following (i need full log):- 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

Command Execution.txtsupervisord.logattached are both of the logs with the latest image.

I also noticed the following: If I have GLUETUN_INCOMING_PORT set to yes it will fail and not launch the webgui, if I have it set to "no" it works just doesn't attach the forwarded port. I am using ProtonVPN in Gluetun, so it does support port forwarding.

supervisord - no GLUETON_INCOMING_PORT.txt

Edited June 2Jun 2 by DeadChimi

Thank you for the fix, seems to be working

30 minutes ago, oogasplada said:

Thank you for the fix, seems to be working

I can get to qBittorent through deluge with the Glueteun incoming port enabled, but now gluetun seems to be starting the vpn and remaining connected for just over 1 minute, then stopping the VPN and repeat. Not sure where to get the logs gluetun

supervisord.log

Edited June 2Jun 2 by oogasplada

12 hours ago, oogasplada said:

I can get to qBittorent through deluge with the Glueteun incoming port enabled, but now gluetun seems to be starting the vpn and remaining connected for just over 1 minute, then stopping the VPN and repeat. Not sure where to get the logs gluetun

supervisord.log

you dont seem to of set the new env vars, from your log:

2026-06-02 19:11:30,060 DEBG 'start-script' stdout output:

[WARN] No qBittorrent WebUI password available for API authentication.

[WARN] Set QBITTORRENT_WEBUI_PASSWORD env var to enable API-based port configuration.

2026-06-02 19:11:30,060 DEBG 'start-script' stdout output:

[WARN] Unable to authenticate with qBittorrent API, port config may fail

[INFO] Sleeping for 60 seconds before re-checking port assignment...

see https://forums.unraid.net/topic/192161-support-binhex-qbittorrent/page/3/#findComment-1625909

15 hours ago, DeadChimi said:

Command Execution.txtsupervisord.logattached are both of the logs with the latest image.

I also noticed the following: If I have GLUETUN_INCOMING_PORT set to yes it will fail and not launch the webgui, if I have it set to "no" it works just doesn't attach the forwarded port. I am using ProtonVPN in Gluetun, so it does support port forwarding.

supervisord - no GLUETON_INCOMING_PORT.txt

from your log you can see the conneciton to qbittorrent is unauthorised:

2026-06-02 15:05:07,803 DEBG 'start-script' stdout output:

Unauthorized

[DEBUG] Successfully connected to gluetun Control Server

double check the username and password are both correct, keep in mind the env var does NOT set a password, it is purely used to authenticate with an EXISTING password to qbit web ui, also ensure the username is correct too.

1 hour ago, binhex said:

from your log you can see the conneciton to qbittorrent is unauthorised:

2026-06-02 15:05:07,803 DEBG 'start-script' stdout output:

Unauthorized

[DEBUG] Successfully connected to gluetun Control Server

double check the username and password are both correct, keep in mind the env var does NOT set a password, it is purely used to authenticate with an EXISTING password to qbit web ui, also ensure the username is correct too.

username and password are both correct, I use it to login to the webGUI everytime. Just to make sure I wasn't insane I changed the username/password and verified that works on the webgui itself, when adding the changed credentials to the env var's it still gives me the same log output I sent to you. Im wondering if there's not something broken in my qbit config at this point.

2 hours ago, DeadChimi said:

username and password are both correct, I use it to login to the webGUI everytime. Just to make sure I wasn't insane I changed the username/password and verified that works on the webgui itself, when adding the changed credentials to the env var's it still gives me the same log output I sent to you. Im wondering if there's not something broken in my qbit config at this point.

can you send me your config file and i will see if i can spot anything wrong with it, also let me know what the username and password values are set to in the container, copy and paste ideally to ensure we get the exact values.

7 hours ago, binhex said:

you dont seem to of set the new env vars, from your log:

2026-06-02 19:11:30,060 DEBG 'start-script' stdout output:

[WARN] No qBittorrent WebUI password available for API authentication.

[WARN] Set QBITTORRENT_WEBUI_PASSWORD env var to enable API-based port configuration.

2026-06-02 19:11:30,060 DEBG 'start-script' stdout output:

[WARN] Unable to authenticate with qBittorrent API, port config may fail

[INFO] Sleeping for 60 seconds before re-checking port assignment...

see https://forums.unraid.net/topic/192161-support-binhex-qbittorrent/page/3/#findComment-1625909

I misunderstood your original comment and thought those variables were for the gluetun container and added them there. Just added to qBittorrent and it's working great now. Thank you for all you do!

On 6/3/2026 at 11:06 AM, binhex said:

can you send me your config file and i will see if i can spot anything wrong with it, also let me know what the username and password values are set to in the container, copy and paste ideally to ensure we get the exact values.

So I have this working again, without the variable port flag env var enabled. I have it set in the gluetun container I'm running to adjust the port when a new port is brought up via the  VPN_PORT_FORWARDING_UP_COMMAND env var. When Gluetun detects a change it write the port, no idea why it works from the Gluetun side but not within the container but either way I have it working again and thanks for working with me!

Hi, I want to use qbittorrent, but I don't want to use the default 8080 port since it's in use by SABnzbd. The only problem is, no matter what I do, no qbittorrent image will allow the changing of port numbers (this one, linuxserver.io, hotio's etc. Attempting to do so results in either 1 of 2 errors when attempting to access the webui. Either white page with single world "unauthorized", or "unable to connect" error.

Changing the port back to the default 8080 makes the image work no problem and you can successfully access the webui. Is there some sort of hard-coded thing preventing anyone from changing the port or what?

Help please!

Hi, I don't want to use the default port of 8080 to access the webui. Can I not use port e.g. 4000?

This one, hotio's, binhex etc. All suffer from the same issue. None allow me to change the webui port. When I do, I either get a blank page with the world "unauthorized" in the top left corner, or the page fails to load alltogether. I've tried changing the "WebUI" port. I've tried changing the "WEBUI_PORT" port. I tried changing the port in advanced view to http://[IP]:[PORT:4000]. I tried deleting the variable and the port fields, applying them, then recreating them again and applying them again. Nothing.

Changing the port back to the default 8080 brings up the webui no problem.

Help please.

Edited August 14Aug 14 by DCCXVIII

3 minutes ago, DCCXVIII said:

Hi, I want to use qbittorrent, but I don't want to use the default 8080 port since it's in use by SABnzbd. The only problem is, no matter what I do, no qbittorrent image will allow the changing of port numbers (this one, linuxserver.io, hotio's etc. Attempting to do so results in either 1 of 2 errors when attempting to access the webui. Either white page with single world "unauthorized", or "unable to connect" error.

Changing the port back to the default 8080 makes the image work no problem and you can successfully access the webui. Is there some sort of hard-coded thing preventing anyone from changing the port or what?

Help please!

See Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/qbittorrentvpn.md

10 minutes ago, binhex said:

See Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/qbittorrentvpn.md

Hi, thanks for the quick response.

Unfortunately those instructions didn't work for me. I followed them, but the webui still refuses to be accessed. I suspected its still hard-coded to only allow port 8080 despite me changing the port to 4000. So I tested it by starting my SABnzbd container which is sitting on 8080. Sure enough, attempting to access your qbittorrent container, resulted in it being redirected to SABnzbd's webui instead.

2 minutes ago, DCCXVIII said:

Hi, thanks for the quick response.

Unfortunately those instructions didn't work for me. I followed them, but the webui still refuses to be accessed. I suspected its still hard-coded to only allow port 8080 despite me changing the port to 4000. So I tested it by starting my SABnzbd container which is sitting on 8080. Sure enough, attempting to access your qbittorrent container, resulted in it being redirected to SABnzbd's webui instead.

the web ui link for the container will not be altered by the procedure mentioned above, so try instead manually typing the url with the port you want.

17 minutes ago, binhex said:

the web ui link for the container will not be altered by the procedure mentioned above, so try instead manually typing the url with the port you want.

Holy shatzba! That was it! THANK YOU!

Damn that threw me for a loop. Never even noticed that the GUI refuses to change the port it sends you to and that you instead have to manually change the URL and edit the port number in the address bar. What the hell makes qbittorrent so damn unique that it doesn't behave like literally every other image on the app store??? So basically nobody can ever use Unraid's GUI to access qbits webui since it seems to be hard-coded to port 8080.

Thanks again! <3

Edited August 14Aug 14 by DCCXVIII