this post was submitted on 16 Mar 2026
15 points (100.0% liked)

Piracy: ꜱᴀɪʟ ᴛʜᴇ ʜɪɢʜ ꜱᴇᴀꜱ

68250 readers
445 users here now

⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.

Rules • Full Version

1. Posts must be related to the discussion of digital piracy

2. Don't request invites, trade, sell, or self-promote

3. Don't request or link to specific pirated titles, including DMs

4. Don't submit low-quality posts, be entitled, or harass others



Loot, Pillage, & Plunder

📜 c/Piracy Wiki (Community Edition):

🏴‍☠️ Other communities

FUCK ADOBE!

Torrenting/P2P:

Gaming:


💰 Please help cover server costs.

Ko-Fi Liberapay
Ko-fi Liberapay

founded 2 years ago
MODERATORS
 

Hello everyone, I recently tried switching my docker torrent client setup from haugene/transmission-openvpn to linuxserver/qbittorrent with gluetun for my VPN.

I have gluetun set up to use port forwarding with ProtonVPN which assigns a random port on every connection. Gluetun provides a VPN_PORT_FORWARDING_UP_COMMAND which can be used in this scenario to update the port used by qbittorrent. While I had issues with the example command in the gluetun wiki to do this, I eventually managed using a bash script I found in another forum.

My issue now is that my server shuts down for the night to reduce noise and after restarting, even though I have the container startup order set up, qbittorrent is no longer reachable on its webinterface. The logs do not indicate any issue though.

As far as I can tell, the stack as I have set it up is extremely finnicky in terms of startup order and time. If I start gluetun first and then wait too long before starting qbit, the port update script will fail because there is obviously no target for it. If qbit is up and running before gluetun is done, I typically can't access its webinterface for some reason and the network interface used by gluetun will set itself to loopback.

The result of this is that basically every morning I have to start and restart the containers in the stack a couple of times until I can access the interface and ensure that the port and network interface of qbit are configured correctly.

If anyone has a similar setup working that they could share or maybe another solution to my current issue that would be great. Thanks.

This is my docker-compose stack for the new setup

version: '3'
services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    ports:
      - 8080:8080 # qbittorrent webinterface
      # - 6881:6881 # qbittorrent, only needed without port-forwarding
    environment:
      - VPN_SERVICE_PROVIDER=protonvpn
      - OPENVPN_USER=${OPENVPN_USERNAME}
      - OPENVPN_PASSWORD=${OPENVPN_PW}
      - SERVER_COUNTRIES=Switzerland
      - VPN_PORT_FORWARDING=on
      - PORT_FORWARD_ONLY=on
      - TZ=Europe/Berlin
      # From gluetun wiki: https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/vpn-port-forwarding.md
      - VPN_PORT_FORWARDING_UP_COMMAND=/bin/sh -c 'sh /gluetun/update-port.sh "{{PORTS}}"'
      - VPN_PORT_FORWARDING_DOWN_COMMAND=/bin/sh -c 'echo "Execution port forwarding down command" && wget -O- -nv --retry-connrefused --post-data "json={\"listen_port\":0,\"current_network_interface\":\"lo\"}" http://127.0.0.1:8080/api/v2/app/setPreferences'
      - QBIT_ADDRESS=http://localhost:8080/
      - QBIT_USERNAME=${QBIT_USER}
      - QBIT_PASSWORD=${QBIT_PW}
    volumes:
      - /mnt/truenas/qbittorrent/update_port.sh:/gluetun/update-port.sh
    labels:
      - "com.centurylinklabs.watchtower.enable=true" # Auto update using watchtower

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - WEBUI_PORT=8080
      - TORRENTING_PORT=6881
    network_mode: "service:gluetun"
    depends_on:
      - gluetun
        # condition: service_healthy
        # restart: true
    volumes:
      - /home/poseidon/qbittorrent:/config
      - /mnt/truenas/qbittorrent:/downloads
    # ports:
    #   - 8080:8080
    #   - 6881:6881
    #   - 6881:6881/udp
    restart: unless-stopped

And this is the script I use for updating the qbittorrent ports

#!/bin/sh
# update-port.sh
port="$1"
retries="${UPDATE_PORT_RETRIES:-5}"
interval="${UPDATE_PORT_RETRY_INTERVAL:-10}"

echo "Attempting to update qBittorrent port to $port..."

for i in $(seq 1 "$retries"); do
  response=$(wget --quiet --save-cookies=/tmp/cookies.txt --keep-session-cookies \
                  --post-data="username=$QBIT_USERNAME&password=$QBIT_PASSWORD" \
                  --header="Referer: $QBIT_ADDRESS" \
                  "$QBIT_ADDRESS/api/v2/auth/login" -O -)

  if [ "$response" = "Ok." ]; then
    break
  fi

  echo "Login attempt $i/$retries failed. Retrying in $interval seconds..."

  sleep "$interval"
done

set -e

if [ "$response" != "Ok." ]; then
    echo "Unable to log in to qBittorrent."
    rm -f /tmp/cookies.txt

    exit 1
fi

wget --quiet --load-cookies=/tmp/cookies.txt \
     --post-data="json={\"listen_port\": $port, \"current_network_interface\":\"$VPN_INTERFACE\", ,\"random_port\":false,\"upnp\":false}" \
     "$QBIT_ADDRESS/api/v2/app/setPreferences" -O /dev/null

rm -f /tmp/cookies.txt

echo "qBittorrent port updated successfully to $port."
top 9 comments
sorted by: hot top controversial new old
[–] polakkenak@feddit.dk 3 points 4 hours ago* (last edited 4 hours ago)

Gluetun has an example for qbt port forwarding integration on the wiki. I've been using this for about a year and some without problem (to my knowledge at least). I've seen that gluetun will retry setting the port in qbt for a while to work around the timing issues.

They also mention a bug in qbt when changing the port, which is also covered in the example.

Edit: I see you're already using the port down script. Not sure what else could be the root cause if you're running on an up to date container version :/

[–] hyphen612@sh.itjust.works 2 points 4 hours ago (1 children)

Ive been successfully using that exact stack for a few months. I'd recommend using wireguard instead of openvpn.

Also, add a the gluetun health check and add condition: service_healthy to your qbittorrent dependency.

You can also simplify your port forwarding quite a bit. Here's a link to how I have it setup. Qbittorrent won't start until gluetun has a healthy connection. Then it repeatedly runs your port forwarding command until it gets an OK exit.

Port forwarding for torrenting shouldn't affect your webui accessibility so it's also possible your qbittorrent is failing before gluetun comes in.

[–] Scrath@lemmy.dbzer0.com 4 points 4 hours ago (1 children)

I know that the port forwarding command can be simplified. In my case its this complex because the way it is listed in the gluetun wiki did not work even though I disabled authentication for my local network. The largest part of the script is authenticating with the username and password before actually sending the port forwarding command.

I'll definitely try adjusting my stack to your variant though. I've also tried the healthcheck option before but I must have configured it wrong because that caused my gluetun container to get stuck.

One question regarding your stack though, is there a specific reason for binding /dev/net/tun to gluetun?

[–] hyphen612@sh.itjust.works 2 points 4 hours ago* (last edited 4 hours ago) (1 children)

That's recommended by glutun.

https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/protonvpn.md#protonvpn

You'll need to whitelist localhost authentication in qbittorrent settings as well.

[–] Scrath@lemmy.dbzer0.com 4 points 2 hours ago

I guess I missed that.

Anyway, I updated my stack to be similar to what you pasted and so far it seems to be working. I'll have to check tomorrow if the reboot issue persists.

[–] uthredii@programming.dev 3 points 5 hours ago (1 children)

Not the best solution but I will leave it in case no one else comments; maybe consider a different vpn provider that does not assign a port on every connection such as mullvad. You should be able to follow this example: https://github.com/JamesTurland/JimsGarage/blob/main/Torrent-VPN/docker-compose.yml

[–] Scrath@lemmy.dbzer0.com 4 points 5 hours ago (2 children)

As far as I am aware, Mullvad has removed port forwarding support a while ago. While I am not sure which VPN providers except proton still support it, I kind of remember seeing a small list of them some time ago which listed Proton among one of the few trustworthy ones left.

[–] DebatableRaccoon@lemmy.ca 2 points 4 hours ago

PIA has port forwarding and retains the port between connections.

[–] Ferrous@lemmy.ml 2 points 5 hours ago

This doesn't help your specific problem, but for what it's worth: airvpn allows you to set a port # which is retained when the VPN hops to a new server, or is reset. In other words, I set the port # in airvpn a year ago, and i have kept the same port since. I haven't kept super up to date on VPN trustworthiness, so maybe airvpn is no longer recommended.