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!