26 minutes ago, Andiroo2 said:

Been working on this one all day. Still no progress. I have gone through all 30 FAQs and added/removed/updated things to no avail. I can’t explain why one container works and another does not. The minute i disable VPN_ENABLED, it works immediately.

Could there be an issue with PIA? Keep in mind this is affecting my binhex and non-binhex qbit containers (except one that inexplicably started working??)…

Yes. Possibly. Have you tried connecting to a different endpoint?

31 minutes ago, wgstarks said:

Yes. Possibly. Have you tried connecting to a different endpoint?

I have tried multiple different endpoints in different countries. I have also used the same OVPN file from the working container in the non-working containers, but that doesn’t help. I have copied the whole openvpn folder from the working container to the non-working one, but still the same result.

Tried changing the IP of the container. Changing the WebUI port, changing my PIA password, port forwarding…

I noticed that on my iOS app, I can connect but I don’t gat a VPN IP displayed on screen:

Does supervisord.log show an error with vpn set to on?

34 minutes ago, wgstarks said:

Does supervisord.log show an error with vpn set to on?

No errors...see attached for a fresh restart and log file. supervisord.log

I’m far from a VPN expert but looks like the problem is here-

2025-12-03 19:45:03,340 DEBG 'start-script' stdout output:

2025-12-03 19:45:03 [UNDEF] Inactivity timeout (--ping-restart), restarting

2025-12-03 19:45:03 SIGHUP[soft,ping-restart] received, process restarting

Google shows that one possible cause is too many clients connected to the same account.

Link

Has anyone seen any speed issues with the latest version of qBit VPN using ProtonVPN? I'm getting slow speeds - maxing out around 30-40MB/s where I used to get ~150-200MB/s consistently, and that's with 4 different servers across different parts of the world, none of them overloaded. If I connect to the same server / protocol / transport with my PC, I get expected speeds, and outside of the WG instance in the container (bypassing the VPN) testing with curl I can download at faster rates as well, so it seems somehow related to the VPN tunnel itself, but just with the qBit VPN tunnel. Ports are working fine, and I have connection, it's just only running at about 20% of the total capacity on downloads, and uploads are even worse (max 2MB/s when I could also hit 100+MB/s up previously - this is more dependent on the far-end user of course, but even while uploading multiples at the same time, my peak upload is around 2MB/s, meaning bandwidth seems to be the limit and not the users).

I've spent a couple of days now troubleshooting to make sure it's not something on my end, but I'm open to ideas if anyone has any...

I found this, something to do with adding the VPN subnet to LAN_NETWORK. Couldn't make it work, so I don't know if it's worth it but it saved headaches of a couple of people apparently, so here goes

I'm still stuck with the WebUI unreachable. (using proton, if that's any help)

10 hours ago, Lacouenne said:

I found this, something to do with adding the VPN subnet to LAN_NETWORK. Couldn't make it work, so I don't know if it's worth it but it saved headaches of a couple of people apparently, so here goes

I'm still stuck with the WebUI unreachable. (using proton, if that's any help)

I haven't read your whole issue so far, but I'm assuming you have the "Optional IP address to bind to" section in qBit settings -> Advanced set to "All Addresses"? If not, when you connect to the VPN tunnel it's likely only bound on the tunnel address, which you can't access remotely. Turn off the VPN, open the UI, open settings, and check what's bound there.

37 minutes ago, JaredC01 said:

I haven't read your whole issue so far, but I'm assuming you have the "Optional IP address to bind to" section in qBit settings -> Advanced set to "All Addresses"? If not, when you connect to the VPN tunnel it's likely only bound on the tunnel address, which you can't access remotely. Turn off the VPN, open the UI, open settings, and check what's bound there.

Yes I have it set to "All addresses"

On 12/3/2025 at 8:51 PM, wgstarks said:

Google shows that one possible cause is too many clients connected to the same account.

Confirmed with PIA support that there is no limit to the number of connections or devices. Surely there IS a limit, but I am not hitting it.

I did another test today though that (I think) eliminates the VPN as the issue. I set VPN_Enabled=No, loaded the WebUI and loaded a torrent. I then made sure it started transferring. I stopped the container, set VPN_Enabled=Yes and restarted the container. The torrent resumed and completed, because i was able to see it move from the in-progress folder to the completed folder. So, the VPN is connecting just fine, the app is loading, and it’s just the WebUI that isn’t loading.

Where do I go from here? I don’t know, but now I will look at the network and IPTables.

When my docker with this image starts, no problems.

But after 1 minute and 30 seconds (exactly) I get this message in my log and the container isn't running anymore.

Never had this error before, dunno what to do to resolve this error.

Hereby a part of the log with the error:

2025-12-09 16:26:48,737 DEBG 'watchdog-script' stdout output:
[debug] Checking we can resolve name 'www.google.com' to address...

2025-12-09 16:26:48,750 DEBG 'watchdog-script' stdout output:
[debug] DNS operational, we can resolve name 'www.google.com' to address '142.250.179.196'

2025-12-09 16:26:48,750 DEBG 'watchdog-script' stdout output:
[debug] Waiting for iptables chain policies to be in place...

2025-12-09 16:26:48,757 DEBG 'watchdog-script' stdout output:
[debug] iptables chain policies are in place

2025-12-09 16:26:48,761 DEBG 'watchdog-script' stdout output:
[debug] VPN incoming port is 47948
[debug] qBittorrent incoming port is 47948
[debug] VPN IP is 10.2.0.2
[debug] qBittorrent IP is 10.2.0.2

2025-12-09 16:27:16,986 DEBG 'start-script' stdout output:
[debug] ProtonVPN assigned incoming port is '47948'

2025-12-09 16:27:18,310 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 23058020539792 for <Subprocess at 23058020538352 with name watchdog-script in state RUNNING> (stdout)>
2025-12-09 16:27:18,310 DEBG fd 15 closed, stopped monitoring <POutputDispatcher at 23058020538592 for <Subprocess at 23058020538352 with name watchdog-script in state RUNNING> (stderr)>
2025-12-09 16:27:18,310 WARN exited: watchdog-script (terminated by SIGKILL; not expected)
2025-12-09 16:27:18,310 DEBG received SIGCHLD indicating a child quit
2025-12-09 16:28:02,061 DEBG 'start-script' stdout output:
[debug] ProtonVPN assigned incoming port is '47948'

2025-12-09 16:28:47,143 DEBG 'start-script' stdout output:
[debug] ProtonVPN assigned incoming port is '47948'

I hope someone can help me out with this error.

I'm running unRAID 7.1.4 with ghcr.io/binhex/arch-qbittorrentvpn:5.0.3-1-01 as container.

Kind Regards,

LoudRex

Edited December 9, 2025Dec 9 by LoudRex

It is mostly this error, sometimes after 1 minute sometimes 4 minutes or 5 minutes.

The error is unsolvable, different versions pulled, no change at all.

It ran perfectly for multiple months, just today this weird error, not going away.

2025-12-09 21:25:19,284 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 23011121730320 for <Subprocess at 23011121333456 with name watchdog-script in state RUNNING> (stdout)>
2025-12-09 21:25:19,284 DEBG fd 15 closed, stopped monitoring <POutputDispatcher at 23011121337296 for <Subprocess at 23011121333456 with name watchdog-script in state RUNNING> (stderr)>
2025-12-09 21:25:19,284 WARN exited: watchdog-script (terminated by SIGKILL; not expected)
2025-12-09 21:25:19,285 DEBG received SIGCHLD indicating a child quit

Never had this in the 5+ years I'm running unRAID with binhex-qbittorrentvpn.

EDIT: Nuked the whole container. Installed the docker again, and copied back the BT_backup folder.

Now it's all working again. Phew! 😂

Edited December 17, 2025Dec 17 by LoudRex
See EDIT

I have been getting this error since yesterday, probably caused by updates on the host.

The host's Arch version is 6.18.2-arch2-1 as compared to 6.18.1-arch-1-2 the container is looking for.

Is there something I can do given that everything worked until yesterday, or does the Arch version bump need to be addressed by @binhex ?

2025-12-20 08:43:20.410394 [info] System information: Linux 9e842d501fbf 6.18.1-arch1-2 #1 SMP PREEMPT_DYNAMIC Sat, 13 Dec 2025 18:23:21 +0000 x86_64 GNU/Linux

2025-12-20 08:43:20.448972 [info] Image tags: BASE_RELEASE_TAG=2025042801,INT_RELEASE_TAG=2025042801,IMAGE_RELEASE_TAG=5.1.0-1-01

2025-12-20 08:43:20.482929 [info] PUID defined as '0'

2025-12-20 08:43:20.542451 [info] PGID defined as '0'

2025-12-20 08:43:20.606589 [info] UMASK defined as '000'

2025-12-20 08:43:20.650407 [info] Permissions already set for '/config'

2025-12-20 08:43:20.721219 [info] Deleting files in /tmp (non recursive)...

2025-12-20 08:43:20.783708 [info] VPN_ENABLED defined as 'yes'

2025-12-20 08:43:20.826028 [info] VPN_CLIENT defined as 'wireguard'

2025-12-20 08:43:20.858168 [info] VPN_PROV defined as 'custom'

2025-12-20 08:43:20.911117 [info] WireGuard config file (conf extension) is located at /config/wireguard/wg0.conf

2025-12-20 08:43:20.960629 [info] VPN_REMOTE_SERVER defined as '95.174.67.242'

2025-12-20 08:43:20.987875 [info] VPN_REMOTE_PORT defined as '1443'

2025-12-20 08:43:21.013141 [info] VPN_DEVICE_TYPE defined as 'wg0'

2025-12-20 08:43:21.043131 [info] VPN_REMOTE_PROTOCOL defined as 'udp'

2025-12-20 08:43:21.088460 [info] USERSPACE_WIREGUARD not defined (via -e USERSPACE_WIREGUARD), defaulting to 'no'

2025-12-20 08:43:21.119677 [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'

modprobe: FATAL: Module ip_tables not found in directory /lib/modules/6.18.1-arch1-2

iptables v1.8.11 (legacy): can't initialize iptables table `filter': Table does not exist (do you need to insmod?)

Perhaps iptables or your kernel needs to be upgraded.

2025-12-20 08:43:21.201333 [crit] iptables default policies not available, exiting script...

Edit: It was indeed due to the Arch update. You need to modprobe iptables. I'll leave this here in case some else finds it helpful.

Edited December 21, 2025Dec 21 by torrent_umbrella

I'm using qBittorrentVPN as VPN for my JDownloader container. VPN client is wireguard via PIA.

Somehow I see this in the logs now so my JDownloader has no internet connection:

2025-12-21 23:09:59,815 DEBG 'start-script' stdout output:

[warn] Failed to bring 'down' WireGuard kernel implementation

2025-12-21 23:09:59,815 DEBG 'start-script' stdout output:

[info] Configuring WireGuard...

2025-12-21 23:09:59,986 DEBG 'start-script' stdout output:

[info] Successfully downloaded PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'

2025-12-21 23:09:59,989 DEBG 'start-script' stdout output:

[info] Successfully generated PIA token for wireguard

2025-12-21 23:09:59,989 DEBG 'start-script' stdout output:

[info] Trying to connect to the PIA WireGuard API on 'france.privacy.network'...

Does anyone else experience this?

20 hours ago, Marv said:

I'm using qBittorrentVPN as VPN for my JDownloader container. VPN client is wireguard via PIA.

Somehow I see this in the logs now so my JDownloader has no internet connection:

2025-12-21 23:09:59,815 DEBG 'start-script' stdout output:

[warn] Failed to bring 'down' WireGuard kernel implementation

2025-12-21 23:09:59,815 DEBG 'start-script' stdout output:

[info] Configuring WireGuard...

2025-12-21 23:09:59,986 DEBG 'start-script' stdout output:

[info] Successfully downloaded PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'

2025-12-21 23:09:59,989 DEBG 'start-script' stdout output:

[info] Successfully generated PIA token for wireguard

2025-12-21 23:09:59,989 DEBG 'start-script' stdout output:

[info] Trying to connect to the PIA WireGuard API on 'france.privacy.network'...

Does anyone else experience this?

Hello,

I'm exactly in the same boat since a few hours...I'm running version 5.1.3-1-01.

I'm using wiregard via PIA as well and got exactly the same logs after I restart the container.
A far as I can tell the issue arise after my apps data backup killed the app this morning:

][binhex-qbittorrentvpn] Stopping binhex-qbittorrentvpn... done! (took 1 seconds)
[22.12.2025 06:11:42][][binhex-qbittorrentvpn] Should NOT backup external volumes, sanitizing them...
[22.12.2025 06:11:42][][binhex-qbittorrentvpn] Calculated volumes to back up: /mnt/user/appdata/binhex-qbittorrentvpn
[22.12.2025 06:11:42][][binhex-qbittorrentvpn] Backing up binhex-qbittorrentvpn...
[22.12.2025 06:11:49][][binhex-qbittorrentvpn] Backup created without issues (took 00:00:07 (hours:mins:secs))
[22.12.2025 06:11:49][][binhex-qbittorrentvpn] Verifying backup...
[22.12.2025 06:11:50][][binhex-qbittorrentvpn] Verification ended without issues (took 00:00:01 (hours:mins:secs))
[22.12.2025 06:11:50][][binhex-qbittorrentvpn] Starting binhex-qbittorrentvpn... (try #1) done!

Then the container restarted :2025-12-22 06:02:55,642 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port
2025-12-22 06:11:41,169 INFO reaped unknown pid 54 (terminated by SIGTERM)
2025-12-22 06:11:41,169 WARN received SIGTERM indicating exit request
2025-12-22 06:11:41,169 DEBG killing watchdog-script (pid 385) with signal SIGTERM
2025-12-22 06:11:41,169 INFO waiting for start-script, watchdog-script to die
2025-12-22 06:11:41,170 DEBG fd 12 closed, stopped monitoring <POutputDispatcher at 22556943999824 for <Subprocess at 22556943995664 with name watchdog-script in state STOPPING> (stdout)>
2025-12-22 06:11:41,170 DEBG fd 16 closed, stopped monitoring <POutputDispatcher at 22556943772736 for <Subprocess at 22556943995664 with name watchdog-script in state STOPPING> (stderr)>
2025-12-22 06:11:41,170 WARN stopped: watchdog-script (exit status 143)
2025-12-22 06:11:41,170 DEBG received SIGCHLD indicating a child quit
2025-12-22 06:11:41,170 DEBG killing start-script (pid 384) with signal SIGTERM
Catching signal: Catching signal: SIGTERM
Exiting cleanly
SIGTERM
Exiting cleanly
2025-12-22 06:11:42,171 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 22556944358032 for <Subprocess at 22556943557232 with name start-script in state STOPPING> (stdout)>
2025-12-22 06:11:42,171 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 22556943998864 for <Subprocess at 22556943557232 with name start-script in state STOPPING> (stderr)>
2025-12-22 06:11:42,171 WARN stopped: start-script (terminated by SIGTERM)
2025-12-22 06:11:42,172 DEBG received SIGCHLD indicating a child quit
.............................
2025-12-22 06:11:54,007 DEBG 'start-script' stdout output:
[info] Successfully downloaded PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'

2025-12-22 06:11:54,009 DEBG 'start-script' stdout output:
[info] Successfully generated PIA token for wireguard

2025-12-22 06:11:54,009 DEBG 'start-script' stdout output:
[info] Trying to connect to the PIA WireGuard API on 'france.privacy.network'...

Looks like a pia problem. I read on reddit that someone had a connexion lost after a vpn deconnection:

PIA daemon blocks network after vpn disconnect on macOS [workaround fix]

GUIDES

PIA blocks all traffic and connection after disconnecting or quitting the app, even with kill switch OFF. Spoke with support and they claim that this issue '- has just surfaced recently' although I can find similar issues dating back to MacOS Montery.

https://www.reddit.com/r/PrivateInternetAccess/comments/1pslkh7/pia_daemon_blocks_network_after_vpn_disconnect_on/

Hope it can help to find a workaround...

Here the post from reddit in extenso:

PIA blocks all traffic and connection after disconnecting or quitting the app, even with kill switch OFF. Spoke with support and they claim that this issue '- has just surfaced recently' although I can find similar issues dating back to MacOS Montery.

Anyhooo, my homegrown solution is fixing the root cause. DNS doesn't revert to your original settings when you disconnect. So you can add this alias via your terminal:

alias fixdns="sudo killall pia-daemon; sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1; sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder"

Then in your terminal just run fixdns after disconnected, should flush the DNS and solves the blocked connectivity

Contacted support, they confirmed it's a "known issue under investigation." The support agent was very helpfull in explaining where the issue comes from and how to do the workaround.

Asked for a timeline: days, weeks, months? Agent dodged and ended the chat. For a company that prides itself on transparency, thats pretty weird.

Posting for those running into the same issue without having the proper understanding to explain it to support. Anyone else experiencing this issue?

I don't wanna mess around with my dns but it can be a lead....

I fixed it changing my endpoint to nl-amsterdam

It's so weird.

Sonarr, Radarr, etc can access my binhex-qbittorrentvpn.

My whole machine is at my friends house, I access it through Tailscale, I have a route to 192.168.1.0/24 (his lan IP). I have access to ALL my dockers from my PC. Also, I just rebooted my server, but it was working before with qbit.

Now, I cant access my qbit webui, but it works from the VM I use as a jumpbox on my friends PC. Is there some place that I need to bind some Tailscale IP?

Solved: For peeps who might find this through Google ad your Tailscale subnet to LAN_NETWORK: x.x.x.x/24, x.x.x.x/24

Edited December 29, 2025Dec 29 by Olick

Has anyone figured out why the options save button stopped working in version 5.1.1?

Probably since it was fixed a while ago, we're on 5.1.4 now

On 10/27/2025 at 9:31 AM, thatsthefrickenlightning said:

Anyone else having connectibility problems with ProtonVPN? Everything was fine for the longest time but now:

• Some time after the container starts, connectibility goes away ('firewalled')

• WebUI remains accessible

• Proxy remains functional (tested, e.g. Sonarr can fetch data via the proxy)

CanYouSeeMe.org and Test-NetConnection (Powershell) give me a negative response on the IP and TCP port from the logs.

Logs themselves seem to be in order, so I'm not sure what's up.

QB log

2025-10-27 08:51:45,850 DEBG 'watchdog-script' stdout output:

[info] qbittorrent incoming port closed, marking for reconfigure

2025-10-27 08:52:12,954 DEBG 'start-script' stdout output:

[info] Sending 'down' command to WireGuard due to port closed...

2025-10-27 08:52:12,973 DEBG 'start-script' stdout output:

[info] Attempting to bring WireGuard interface 'down'...

2025-10-27 08:52:12,991 DEBG 'start-script' stderr output:

Warning: `/config/wireguard/wg0.conf' is world accessible

2025-10-27 08:52:13,002 DEBG 'start-script' stderr output:

[#] ip -4 rule delete table 51820

2025-10-27 08:52:13,009 DEBG 'start-script' stderr output:

[#] ip -4 rule delete table main suppress_prefixlength 0

2025-10-27 08:52:13,017 DEBG 'start-script' stderr output:

[#] ip link delete dev wg0

2025-10-27 08:52:13,111 DEBG 'start-script' stderr output:

[#] iptables-restore -n

2025-10-27 08:52:13,128 DEBG 'start-script' stderr output:

[#] '/root/wireguarddown.sh'

2025-10-27 08:52:13,147 DEBG 'start-script' stdout output:

[info] Successfully brought Wireguard interface 'down'

2025-10-27 08:52:13,147 DEBG 'start-script' stdout output:

[info] Configuring WireGuard...

2025-10-27 08:52:13,169 DEBG 'start-script' stdout output:

[info] Attempting to bring WireGuard interface 'up'...

2025-10-27 08:52:13,178 DEBG 'start-script' stderr output:

Warning: `/config/wireguard/wg0.conf' is world accessible

2025-10-27 08:52:13,186 DEBG 'start-script' stderr output:

[#] ip link add dev wg0 type wireguard

2025-10-27 08:52:13,188 DEBG 'start-script' stderr output:

[#] wg setconf wg0 /dev/fd/63

2025-10-27 08:52:13,190 DEBG 'start-script' stderr output:

[#] ip -4 address add 10.2.0.2/32 dev wg0

2025-10-27 08:52:13,196 DEBG 'start-script' stderr output:

[#] ip link set mtu 1420 up dev wg0

2025-10-27 08:52:13,206 DEBG 'start-script' stderr output:

[#] wg set wg0 fwmark 51820

2025-10-27 08:52:13,207 DEBG 'start-script' stderr output:

[#] ip -4 rule add not fwmark 51820 table 51820

2025-10-27 08:52:13,209 DEBG 'start-script' stderr output:

[#] ip -4 rule add table main suppress_prefixlength 0

2025-10-27 08:52:13,210 DEBG 'start-script' stderr output:

[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820

2025-10-27 08:52:13,214 DEBG 'start-script' stderr output:

[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1

2025-10-27 08:52:13,216 DEBG 'start-script' stderr output:

[#] iptables-restore -n

2025-10-27 08:52:13,218 DEBG 'start-script' stderr output:

[#] '/root/wireguardup.sh'

2025-10-27 08:52:53,552 DEBG 'start-script' stdout output:

[info] Successfully retrieved external IP address VPNIP from URL 'http://checkip.amazonaws.com'

2025-10-27 08:52:53,555 DEBG 'start-script' stdout output:

[info] Script started to assign incoming port for 'protonvpn'

2025-10-27 08:52:53,562 DEBG 'start-script' stdout output:

[info] Successfully brought Wireguard interface 'up'

2025-10-27 08:52:55,653 DEBG 'start-script' stdout output:

initnatpmp() returned 0 (SUCCESS)

using gateway : 10.2.0.1

sendpublicaddressrequest returned 2 (SUCCESS)

readnatpmpresponseorretry returned 0 (OK)

Public IP address : VPNIP

epoch = 4200457

closenatpmp() returned 0 (SUCCESS)

I've already created a new .conf file for QB with no luck.

Curious to read anyone's thoughts. Thanks.

Edit: hol' up, this is the library used right? And it says 'To free all used resources, closenatpmp() can be called', which is what is at the end of my log. Why is this container closing up that PMP port at the end? You need it indefinitely. Very curious.

Edit2: restarted and had the logs open on monitor 2. This came by.

QB log 2

2025-10-27 09:48:07,317 DEBG 'start-script' stderr output:

readnatpmpresponseorretry() failed : the gateway does not support nat-pmp

errno=11 'Resource temporarily unavailable'

2025-10-27 09:48:07,318 DEBG 'start-script' stdout output:

[warn] Unable to assign an incoming port for protocol UDP, creating file '/tmp/portfailure' to indicate failure...

2025-10-27 09:48:07,321 DEBG 'start-script' stdout output:

[info] Script finished to assign incoming port

2025-10-27 09:48:11,986 DEBG 'start-script' stdout output:

[info] Sending 'down' command to WireGuard due to incoming port allocation failure...

2025-10-27 09:48:11,993 DEBG 'start-script' stdout output:

[info] Attempting to bring WireGuard interface 'down'...

I'm highly puzzled. The gateway does support NAT-PMP, but still says it doesn't, sometimes?

After 2+ months of my QB client only really working briefly after a restart, I fixed this issue. How, I don't truly know. I ended up reinstalling the whole container and migrating over my BT_Backup data and the categories.json file. If I copied over the qbittorrent.conf data from old to new, the problem would reappear. Not sure what it was and not gonna dig further to find out. Seems to have been a weird 1% fluke type bug that only I was having, but maybe this helps someone. Relieved that my 'pipes are unclogged' now.

Happy new year, all.

I restarted my server today and suddenly out of nowhere my qbittorrentvpn container won't start up. Below are the logs that show up every time I have tried to restart and troubleshoot this. I haven't made any changes to this container in months. Running ghcr.io/binhex/arch-qbittorrentvpn.

2026-01-03 21:53:45.745179 [info] Host is running unRAID

2026-01-03 21:53:45.779132 [info] System information: Linux 554f7efe4e78 6.12.54-Unraid #1 SMP PREEMPT_DYNAMIC Tue Oct 21 15:58:46 PDT 2025 x86_64 GNU/Linux

2026-01-03 21:53:45.806197 [info] Image architecture: 'amd64'

2026-01-03 21:53:45.835631 [info] Application name: 'qbittorrentvpn'

2026-01-03 21:53:45.861759 [info] Base image release tag: '2025111101'

2026-01-03 21:53:45.886819 [info] Application image release tag: '5.1.4-1-01'

2026-01-03 21:53:45.914067 [info] PUID defined as '99'

2026-01-03 21:53:45.957026 [info] PGID defined as '100'

2026-01-03 21:53:45.993921 [info] UMASK defined as '000'

2026-01-03 21:53:46.023495 [info] Permissions file '/config/perms.txt' exists, skipping setting ownership and permissions on '/config' and '/data'

2026-01-03 21:53:46.051516 [info] Deleting files in /tmp (non recursive)...

2026-01-03 21:53:46.083110 [info] VPN_ENABLED defined as 'yes'

2026-01-03 21:53:46.111794 [info] VPN_CLIENT defined as 'wireguard'

2026-01-03 21:53:46.138695 [info] VPN_PROV defined as 'pia'

2026-01-03 21:53:46.171420 [info] WireGuard config file (conf extension) is located at /config/wireguard/wg0.conf

2026-01-03 21:53:46.208027 [info] VPN_REMOTE_SERVER defined as 'swiss.privacy.network'

2026-01-03 21:53:46.235115 [info] VPN_REMOTE_PORT defined as '1337'

2026-01-03 21:53:46.259812 [info] VPN_DEVICE_TYPE defined as 'wg0'

2026-01-03 21:53:46.289687 [info] VPN_REMOTE_PROTOCOL defined as 'udp'

2026-01-03 21:53:46.318905 [info] USERSPACE_WIREGUARD defined as 'no'

2026-01-03 21:53:46.346339 [info] NAME_SERVERS defined as '1.1.1.1,1.0.0.1'

28 minutes ago, benj. said:

I restarted my server today and suddenly out of nowhere my qbittorrentvpn container won't start up. Below are the logs that show up every time I have tried to restart and troubleshoot this. I haven't made any changes to this container in months. Running ghcr.io/binhex/arch-qbittorrentvpn.

2026-01-03 21:53:45.745179 [info] Host is running unRAID

2026-01-03 21:53:45.779132 [info] System information: Linux 554f7efe4e78 6.12.54-Unraid #1 SMP PREEMPT_DYNAMIC Tue Oct 21 15:58:46 PDT 2025 x86_64 GNU/Linux

2026-01-03 21:53:45.806197 [info] Image architecture: 'amd64'

2026-01-03 21:53:45.835631 [info] Application name: 'qbittorrentvpn'

2026-01-03 21:53:45.861759 [info] Base image release tag: '2025111101'

2026-01-03 21:53:45.886819 [info] Application image release tag: '5.1.4-1-01'

2026-01-03 21:53:45.914067 [info] PUID defined as '99'

2026-01-03 21:53:45.957026 [info] PGID defined as '100'

2026-01-03 21:53:45.993921 [info] UMASK defined as '000'

2026-01-03 21:53:46.023495 [info] Permissions file '/config/perms.txt' exists, skipping setting ownership and permissions on '/config' and '/data'

2026-01-03 21:53:46.051516 [info] Deleting files in /tmp (non recursive)...

2026-01-03 21:53:46.083110 [info] VPN_ENABLED defined as 'yes'

2026-01-03 21:53:46.111794 [info] VPN_CLIENT defined as 'wireguard'

2026-01-03 21:53:46.138695 [info] VPN_PROV defined as 'pia'

2026-01-03 21:53:46.171420 [info] WireGuard config file (conf extension) is located at /config/wireguard/wg0.conf

2026-01-03 21:53:46.208027 [info] VPN_REMOTE_SERVER defined as 'swiss.privacy.network'

2026-01-03 21:53:46.235115 [info] VPN_REMOTE_PORT defined as '1337'

2026-01-03 21:53:46.259812 [info] VPN_DEVICE_TYPE defined as 'wg0'

2026-01-03 21:53:46.289687 [info] VPN_REMOTE_PROTOCOL defined as 'udp'

2026-01-03 21:53:46.318905 [info] USERSPACE_WIREGUARD defined as 'no'

2026-01-03 21:53:46.346339 [info] NAME_SERVERS defined as '1.1.1.1,1.0.0.1'

I resolved my own issue. I turned on debugging in the Unraid container setup so the logs would show more info, which showed that my container was having difficulty resolving the VPN location I had selected. I reset my Unraid DNS connection and everything was resolved. Not sure why it had trouble connecting in the first place.

I accidentally changed my session timeout to 1 second, and after 1 second it will lock me from making any setting changes, which prevents me from changing it back. Is there a way I can up the session timeout from console?

5 minutes ago, AGluck said:

I accidentally changed my session timeout to 1 second, and after 1 second it will lock me from making any setting changes, which prevents me from changing it back. Is there a way I can up the session timeout from console?

Edit the configuration file.

appdata/binhex-qbittorrentvpn/qbittorrent/config/qBittorrent.conf.

It’s line 103 in mine.