Anyone got an recent hotio qbittorrent with wireguard running?

Apps and Virtualization
1

sometime in december an update broke the docker. ok, not broke - more changes on VPN_forward or so prevented my qbit to run. I have a wg0.conf with a mullvad wireguard config (was running fine until december) and the yaml looks like this

services:
  qbittorrent:
    cap_add:
      - NET_ADMIN
    container_name: qbittorrent
    environment:
      - PUID=568
      - PGID=568
      - UMASK=002
      - TZ=Europe/Paris
      - WEBUI_PORTS=8080/tcp,8080/udp
      - VPN_ENABLED=true
      - VPN_CONF=wg0
      - VPN_PROVIDER=generic
      - VPN_LAN_NETWORK=10.10.0.0/24
      - VPN_NAMESERVERS=9.9.9.9
      - VPN_LAN_LEAK_ENABLED=false
      - VPN_EXPOSE_PORTS_ON_LAN=
      - VPN_AUTO_PORT_FORWARD=
      - VPN_PORT_REDIRECTS=
      - VPN_KEEP_LOCAL_DNS=false
      - VPN_FIREWALL_TYPE=auto
      - PRIVOXY_ENABLED=false
      - UNBOUND_ENABLED=false
    image: ghcr.io/hotio/qbittorrent:latest
    ports:
      - '8080:8080'
    restart: unless-stopped
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.all.disable_ipv6=1
    volumes:
      - /mnt/apps/configs/qbit/:/config
      - /mnt/datapool/media:/media

Container starts, but I can not connect to the gui

2026-01-28 21:27:36.547100+00:00s6-rc: info: service init-wireguard successfully started
2026-01-28 21:27:36.547757+00:00s6-rc: info: service service-unbound: starting
2026-01-28 21:27:36.547966+00:00s6-rc: info: service service-qbittorrent: starting
2026-01-28 21:27:36.548289+00:00s6-rc: info: service service-forwarder: starting
2026-01-28 21:27:36.552537+00:00s6-rc: info: service service-unbound successfully started
2026-01-28 21:27:36.552647+00:00s6-rc: info: service service-forwarder successfully started
2026-01-28 21:27:36.553491+00:00s6-rc: info: service service-qbittorrent successfully started
2026-01-28 21:27:36.553798+00:00s6-rc: info: service legacy-services: starting
2026-01-28 21:27:36.564995+00:00s6-rc: info: service legacy-services successfully started
2026-01-28 21:27:36.565130+00:00[2026-01-28 22:27:36] [INF] [QBITTORRENT] Delaying start until forwarded port is available.
2026-01-28 21:27:36.571042+00:00[2026-01-28 22:27:36] [INF] [UNBOUND] Adding nameserver [VPN][9.9.9.9].
2026-01-28 21:27:36.666900+00:00[1769635656] unbound[323:0] info: start of service (unbound 1.23.1).
2026-01-28 21:27:46.574090+00:00[2026-01-28 22:27:46] [WRN] [FORWARDER] The file [/config/wireguard/forwarded_port] was not found. Set [VPN_AUTO_PORT_FORWARD=false] if you don't plan on providing that file yourself.

any combination of VPN_AUTO_PORT_FORWARD I tried gives different errors - using 51820 (the only port in the wg0.conf), leaving it blank, a different number…

what should be changed in the yaml (i assume it is an variable in the yaml) to make it work again?

2

Same issue. You can see in the log it is saying:
”The file [/config/wireguard/forwarded_port] was not found.”

So I guess we need to create this file. But I am unsure of the syntax

3

Actually - looking at the qbittorrent for linux it was updated to use this new variable:

”TORRENTING_PORT=”

But when I try that with my airvpn port I don’t see that it connects.

4

could you solve this? Or are you still as lost as me?

5

I got a step closer to the solution - at least qbit and wireguard are running. I followed this example:

https://wiki.serversatho.me/qBittorrent (tab “Linuxserver Wireguard” in step 1 “Deploy qBittorrent”)

but I struggle with the tunnel, wireguard logs look like it is running, but qBit is indicating “firewalled” and shows no I/O traffic. I will report back

6

seems like I found the solution: I simply restartet the whole TrueNAS box. I have no idea why this fixed the wireguard when restarting the stack of qbit+wireguard or the single wireguard container did not.

Another lesson learned: I had to change the default download path from “/downloads” to the existing path “/media/Download”. There was a folder expected but not present and so I got a permission denied with resulted in errored status on test torrents even if I could see peers…

I am still learning :slight_smile:

7

Om very interested to know what the final yaml code looked like. I also struggle with this currently.

Im running airVPN.

8

I followed https://wiki.serversatho.me/qBittorrent (in step 1 open the second tab “Linuxserver Wireguard”) and was able to start two containers. On my first try it did work. I am using mullvad. But since then I am struggleing again - wireguard starts, qbit starts and wireguards ditches. After some searching I found that mullvad restricted the use of port forwarding and maybe this can be the cause - but why it did work for at least 1 day is beyond me. In fact I was eyeing airVPN as a possible alternative to mullvad (especially because they mention being ok with port forwarding), but If you struggle as well to get a connection I don’t know anymore…

Could you check the YAML from the wiki.serversatho.me and give it a try and report back here if this was the solution for you?

I might give it another try with airVPN then…

9

I got it working with airvpn and the latest yaml code.

In the #insert forwarded port here, I added the port that I opened in airVPN.

Also, make sure to add the 5.1.20 or whatever release on qbit that the new yaml code from servers@ho.me update with.

All is good in the “Linux iso hoarding” world again :grinning_face_with_smiling_eyes::grinning_face_with_smiling_eyes:.

10

I’ve started with a LXC container and using

  • Bookworm
  • qBittorent-nox
  • NordVPN

So far I’ve got

  • qBittorent-nox installed and WebGUI access
  • NordVPN installed (probably should have done this first)
  • it sorta working - manually
  • running as root - limitation for disks access to host?

Will need to get it automated

11

I’ve got it working again. I switched back to the YAML for qubittorrent Hotio. The dual container solution (qbit+wireguard) did not work reliably for me. Sometimes wireguard would switch to “unhealthy” as soon as qbit started, I could not reach the qbit WebGUI and so on.

fixing the qbit from Hotio to the version 5.1.2 and ditching the extra wg0.conf-line with “postup…” (I commented it out with #) did it for me. The container came immediatly online, webgui could be reached and the old files were already there. Interface wg0 seems not to leak additional information so I am satisfied for the moment.