Bug: QBittorrent loses internet connectivity after running for some time

[jdoe29103]

Is this urgent?

None

Host OS

Latest version of OpenMediaVault

CPU arch

x86_64

VPN service provider

Mullvad

What are you using to run the container

docker-compose

What is the version of Gluetun

I don't see this line in my logs

What's the problem 🤔

I recently switched from using an old deprecated docker container for qBittorrent with OVPN support built in. I am now running the latest qBittorrent docker from linuxserver along with gluetun using Mullvad/Wireguard. My issue is that qBittorrent will connect to torrents and work just fine for awhile but it will eventually become unable to connect to any peers. I do not know if this is a qBittorrent issue or a gluetun issue. Restarting the qBittorrent container solves the issue temporarily.

Share your logs

|   ├── VPN provider settings:
|   |   ├── Name: mullvad
|   |   └── Server selection settings:
|   |       ├── VPN type: wireguard
|   |       ├── Cities: atlanta ga
|   |       └── Wireguard selection settings:
|   └── Wireguard settings:
|       ├── Private key: oO...WA=
|       ├── Interface addresses:
|       |   └── 10.66.214.103/32
|       └── Network interface: tun0
├── DNS settings:
|   ├── DNS server address to use: 127.0.0.1
|   ├── Keep existing nameserver(s): no
|   └── DNS over TLS settings:
|       ├── Enabled: yes
|       ├── Update period: every 24h0m0s
|       ├── Unbound settings:
|       |   ├── Authoritative servers:
|       |   |   └── cloudflare
|       |   ├── Caching: yes
|       |   ├── IPv6: no
|       |   ├── Verbosity level: 1
|       |   ├── Verbosity details level: 0
|       |   ├── Validation log level: 0
|       |   ├── System user: root
|       |   └── Allowed networks:
|       |       ├── 0.0.0.0/0
|       |       └── ::/0
|       └── DNS filtering settings:
|           ├── Block malicious: yes
|           ├── Block ads: no
|           ├── Block surveillance: no
|           └── Blocked IP networks:
|               ├── 127.0.0.1/8
|               ├── 10.0.0.0/8
|               ├── 172.16.0.0/12
|               ├── 192.168.0.0/16
|               ├── 169.254.0.0/16
|               ├── ::1/128
|               ├── fc00::/7
|               ├── fe80::/10
|               ├── ::ffff:7f00:1/104
|               ├── ::ffff:a00:0/104
|               ├── ::ffff:a9fe:0/112
|               ├── ::ffff:ac10:0/108
|               └── ::ffff:c0a8:0/112
├── Firewall settings:
|   ├── Enabled: yes
|   └── VPN input ports:
|       └── 56595
├── Log settings:
|   └── Log level: INFO
├── Health settings:
|   ├── Server listening address: 127.0.0.1:9999
|   ├── Target address: cloudflare.com:443
|   ├── Read header timeout: 100ms
|   ├── Read timeout: 500ms
|   └── VPN wait durations:
|       ├── Initial duration: 6s
|       └── Additional duration: 5s
├── Shadowsocks server settings:
|   └── Enabled: no
├── HTTP proxy settings:
|   └── Enabled: no
├── Control server settings:
|   ├── Listening address: :8000
|   └── Logging: yes
├── OS Alpine settings:
|   ├── Process UID: 1000
|   ├── Process GID: 100
|   └── Timezone: US/Eastern
├── Public IP settings:
|   ├── Fetching: every 12h0m0s
|   └── IP file path: /tmp/gluetun/ip
└── Version settings:
    └── Enabled: yes
2022-12-08T17:50:48-05:00 INFO IPv6 is not supported
2022-12-08T17:50:48-05:00 INFO [routing] default route found: interface eth0, gateway 172.27.0.1 and assigned IP 172.27.0.2
2022-12-08T17:50:48-05:00 INFO [routing] adding route for 0.0.0.0/0
2022-12-08T17:50:48-05:00 INFO [firewall] setting allowed subnets...
2022-12-08T17:50:48-05:00 INFO [routing] default route found: interface eth0, gateway 172.27.0.1 and assigned IP 172.27.0.2
2022-12-08T17:50:48-05:00 INFO [dns over tls] using plaintext DNS at address 1.1.1.1
2022-12-08T17:50:48-05:00 INFO [http server] http server listening on [::]:8000
2022-12-08T17:50:48-05:00 INFO [healthcheck] listening on 127.0.0.1:9999
2022-12-08T17:50:48-05:00 INFO [firewall] allowing VPN connection...
2022-12-08T17:50:48-05:00 INFO [wireguard] Using available kernelspace implementation
2022-12-08T17:50:48-05:00 INFO [wireguard] Connecting to 45.134.140.130:51820
2022-12-08T17:50:48-05:00 INFO [wireguard] Wireguard is up
2022-12-08T17:50:48-05:00 INFO [firewall] setting allowed input port 56595 through interface tun0...
2022-12-08T17:50:48-05:00 INFO [dns over tls] downloading DNS over TLS cryptographic files
2022-12-08T17:50:48-05:00 INFO [dns over tls] downloading hostnames and IP block lists
2022-12-08T17:50:49-05:00 INFO [healthcheck] healthy!
2022-12-08T17:50:52-05:00 INFO [dns over tls] init module 0: validator
2022-12-08T17:50:52-05:00 INFO [dns over tls] init module 1: iterator
2022-12-08T17:50:52-05:00 INFO [dns over tls] start of service (unbound 1.15.0).
2022-12-08T17:50:52-05:00 INFO [dns over tls] generate keytag query _ta-4a5c-4f66. NULL IN
2022-12-08T17:50:52-05:00 INFO [dns over tls] ready
2022-12-08T17:50:53-05:00 INFO [vpn] You are running 1 commit behind the most recent latest
2022-12-08T17:50:53-05:00 INFO [ip getter] Public IP address is 45.134.140.139 (United States, Georgia, Atlanta)

Share your configuration

version: "3"
services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    # line above must be uncommented to allow external containers to connect. See https://github.com/qdm12/gluetun/wiki/Connect-a-container-to-gluetun#external-container-to-gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - 8888:8888/tcp # HTTP proxy
      - 8388:8388/tcp # Shadowsocks
      - 8388:8388/udp # Shadowsocks
      - 8080:8080     # webgui
      - 56595:56595   # mullvad
      - 56595:56595/udp #mullvad
    volumes:
      - /srv/dev-disk-by-uuid-137ab035-ce9c-4366-b522-fd21bd139153/appdata/gluetun:/gluetun
    environment:
      # See https://github.com/qdm12/gluetun/wiki
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - FIREWALL_VPN_INPUT_PORTS=redacted
      - WIREGUARD_PRIVATE_KEY=redacted
      - WIREGUARD_ADDRESSES=redacted
      - SERVER_CITIES=Atlanta GA
      - PUID=1000
      - PGID=100
      - TZ=US/Eastern
    restart: unless-stopped
    
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=100
      - TZ=US/Eastern
      - WEBUI_PORT=8080
    volumes:
      - /srv/dev-disk-by-uuid-137ab035-ce9c-4366-b522-fd21bd139153/appdata/qbittorrent:/config
      - /srv/mergerfs/pool/data/torrents/:/data/torrents
    #ports:
      #- 8005:8005
      #- 56595:56595
      #- 56595:56595/udp
    depends_on:
      - gluetun      
    restart: unless-stopped

[bnhf]

@jdoe29103

You're supposed to have a volume mapping to /downloads not /data/torrents in the linuxserver/qbittorrent container. Details of the options available can be found here: https://docs.linuxserver.io/images/docker-qbittorrent

[jdoe29103]

@bnhf the volumes are irrelevant to my issue. The default mappings from linuxserver are not good for my use case and they can be changed without issue. The volumes I have mapped are very intentional. Your response is irrelevant to my issue.

[bnhf]

@jdoe29103

My apologies then, I always thought those volume mappings mattered. :-)

[jdoe29103]

@bnhf no worries I can see why one would assume that. The /downloads part of the mapping is just a made up path that will be seen by whatever you are running in your container so you can change it to anything you want as long as whatever app you are using is configured with that same path.

[bnhf]

@jdoe29103

You're probably ahead of me on this one, but I see in the linuxserver/qbittorrent Github page that they have the "temp" directory set to /downloads in the qbittorrent configuration file. I don't see where that path is exposed in the WebUI, so is it possible you're using up whatever free space is available in the container and a restart clears it out?

[SinTan1729]

I'm also facing this issue. Looks like it might be a qBittorrent issue since gluetun seems to maintain the connection.

[SinTan1729]

A (not nice) solution that I ended up using it adding this in the docker-compose for qbittorrent:

healthcheck:
    test: ping 1.1.1.1 -nqc 1 -W 4 > /dev/null 2>&1 || exit 1
    interval: 60s
    retries: 5
    start_period: 20s
    timeout: 10s
depends_on:
    gluetun:
        condition: service_healthy

[qdm12]

@SinTan1729 @bnhf thanks for your input 👍

@SinTan1729

A (not nice) solution that I ended up using it adding this in the docker-compose for qbittorrent:

So qbittorrent loses connectivity completely? Are you sure the whole gluetun container doesn't get restarted? If it does, then it makes sense qbittorrent loses connectivity, subscribe to #641

@jdoe29103 welcome to gluetun first 😉 Your problem might be related to #1273 and also maybe a new bug in qbittorrent? Have you tried a previous tagged image for qbittorrent? Maybe also have a try with another client like Deluge? 🤔

[SinTan1729]

So qbittorrent loses connectivity completely? Are you sure the whole gluetun container doesn't get restarted? If it does, then it makes sense qbittorrent loses connectivity, subscribe to #641

From the logs, doesn't look like gluetun is restarting. Instead, it's updating the VPN details (i.e. IP etc.). In some cases, I'm not even able to find such an event, so qBittorrent is losing internet seemingly randomly.

[jdoe29103]

@SinTan1729 I have been poking around with it the past week and I may have found a somewhat "better" fix. The other day I installed some updates on my OPNsense router which required a reboot. While the router rebooted I watched qBittorrent to see if it would recover once the router came back online and sure enough it did not and all torrents were stalled. However, after some trial and error it seems that binding the local IP address in qBittorrent's advanced settings resolved this issue. It can survive a router reboot and come back online after I changed this. It has been going strong for a few days now so we shall see.

@qdm12 It could be. I have had this issue in the past with much older versions of qbittorrent in combination with OpenVPN. I have not tested an older version of qbittorrent with gluetun yet so that could also be a potential fix. I am going to poke around with it a bit more sometime this week and see what I can find.

A (not nice) solution that I ended up using it adding this in the docker-compose for qbittorrent:

healthcheck:
    test: ping 1.1.1.1 -nqc 1 > /dev/null 2>&1 || exit 1
    interval: 60s
    retries: 5
    start_period: 20s
    timeout: 10s
depends_on:
    gluetun:
        condition: service_healthy

@SinTan1729 does this cause qbittorrent to reboot if the gluetun container is restarted?

[SinTan1729]

@SinTan1729 does this cause qbittorrent to reboot if the gluetun container is restarted?

Yes, it does.

@jdoe29103 Although, it doesn't really solve the issue as I just noticed that qBittorrent isn't working (i.e. it can't connect to trackers, fails the ipleak torrent test etc.) but I manually checked that I can ping from inside the container. I'll try out the address binding method that you suggested.

Update: I bound it to the network tun0 instead of a specific IP, and that seems to be working well (it has the advantage that qBittorrent binds to both IPV4 and IPV6, and some of my private trackers seem to perform better with one or the other). My guess it that whenever the network from gluetun went down, qBittorrent bound itself to another network (which isn't really connected to the internet) and for some reason refused to bind to tun0 when it came back on. So, restricting it to the proper network works.

[jdoe29103]

Update: I bound it to the network tun0 instead of a specific IP, and that seems to be working well (it has the advantage that qBittorrent binds to both IPV4 and IPV6, and some of my private trackers seem to perform better with one or the other). My guess it that whenever the network from gluetun went down, qBittorrent bound itself to another network (which isn't really connected to the internet) and for some reason refused to bind to tun0 when it came back on. So, restricting it to the proper network works.

Glad it's working for you too. Your explanation makes perfect sense to me as well.
@qdm12 Do you think you could add this into the documentation somewhere to help future users?

[jaroslawjanas]

@SinTan1729 does this cause qbittorrent to reboot if the gluetun container is restarted?

Yes, it does.

@jdoe29103 Although, it doesn't really solve the issue as I just noticed that qBittorrent isn't working (i.e. it can't connect to trackers, fails the ipleak torrent test etc.) but I manually checked that I can ping from inside the container. I'll try out the address binding method that you suggested.

Update: I bound it to the network tun0 instead of a specific IP, and that seems to be working well (it has the advantage that qBittorrent binds to both IPV4 and IPV6, and some of my private trackers seem to perform better with one or the other). My guess it that whenever the network from gluetun went down, qBittorrent bound itself to another network (which isn't really connected to the internet) and for some reason refused to bind to tun0 when it came back on. So, restricting it to the proper network works.

Yeah I had a similar issue a year ago and went through the exact same process.
I tried doing a health check hack and it worked just fine but was annoying.
The solution turned out to be setting a specific interface in the qbittorrent settings and binding to all ipv4 addresses on it.

[jdoe29103]

So it seems the issue is not completely resolved. I noticed this morning that many torrents were unable to connect to trackers and adding new torrents just stalled. It seems the issue still persists sadly.

[EZ64cool]

I've also been running into this issue and I've been bound to the tun0 adapter from the beginning.
I have found a 100% repro rate with AirVpn, if you manually disconnect the session gluten is using through their website this issue will occur upon reconnection.
Hopefully this will help someone more experienced find what's happening as I haven't been able to find out why yet 😁

[angauber]

I encounter this problem as well, qbittorrent "stalls" when gluetun restart

I guess this should be fixed/configurable on qbittorrent side since it can happen for the network to go down

[nomisunrider]

Similar issue here; moved from a deprecated combo container to this plus linuxserver qbittorrent and qbittorrent works for a while, then loses connectivity until I restart the container.
I suspect the issue is with qbittorent, as my sonarr and jackett containers use gluetun fine...

[EZ64cool]

I've done some digging and it looks like the problem is with libtorrent
arvidn/libtorrent#4412
Not sure what we can do on this end except reconnect less often, obviously not really a solution 😔
Unless we can somehow restart qbittorrent container when gluetun goes from unhealthy to healthy?

[EZ64cool]

Update:
I might have found a solution to this but it's a little to early to tell. I've been using the linuxserver version of qBittorrent and after a little investigation they seems to default to the libtorrent 2.0 version.
I've now updated my container to use the lscr.io/linuxserver/qbittorrent:libtorrentv1 image and, for the moment, VPN disconnections no longer cause qBittorrent to lose connection and the ports stay/re open.
I'll keep this updated but hopefully this will hold 😁

[jdoe29103]

After a power outage last night Qbittorrent rebooted and was connected to trackers but my client was not connectable. It seems Qbittorrent is just generally unreliable and I might just look for another client as I have been suffering with issues with this software for the better part of a decade.

[angauber]

Update: I might have found a solution to this but it's a little to early to tell. I've been using the linuxserver version of qBittorrent and after a little investigation they seems to default to the libtorrent 2.0 version. I've now updated my container to use the lscr.io/linuxserver/qbittorrent:libtorrentv1 image and, for the moment, VPN disconnections no longer cause qBittorrent to lose connection and the ports stay/re open. I'll keep this updated but hopefully this will hold grin

This does not work for me, I can see the used libtorrent version is 1.x but the torrents still get stucks from time to time

[nomisunrider]

Update: I might have found a solution to this but it's a little to early to tell. I've been using the linuxserver version of qBittorrent and after a little investigation they seems to default to the libtorrent 2.0 version. I've now updated my container to use the lscr.io/linuxserver/qbittorrent:libtorrentv1 image and, for the moment, VPN disconnections no longer cause qBittorrent to lose connection and the ports stay/re open. I'll keep this updated but hopefully this will hold grin

This does not work for me, I can see the used libtorrent version is 1.x but the torrents still get stucks from time to time

I never updated here, but I had also tried the 1.x libtorrent version of qbittorent with no positive changes. I've resorted to just restarting my container occasionally =(

I may try the healthcheck item referenced above if I get a chance.

[jdoe29103]

Update: I might have found a solution to this but it's a little to early to tell. I've been using the linuxserver version of qBittorrent and after a little investigation they seems to default to the libtorrent 2.0 version. I've now updated my container to use the lscr.io/linuxserver/qbittorrent:libtorrentv1 image and, for the moment, VPN disconnections no longer cause qBittorrent to lose connection and the ports stay/re open. I'll keep this updated but hopefully this will hold grin

This does not work for me, I can see the used libtorrent version is 1.x but the torrents still get stucks from time to time

I never updated here, but I had also tried the 1.x libtorrent version of qbittorent with no positive changes. I've resorted to just restarting my container occasionally =(

I may try the healthcheck item referenced above if I get a chance.

I was able to resolve the issue by reverting back to libtorrent 1.x AND binding network interface to "tun0" and IP address to "All IPv4"
Container has been up for 15 days without issues.

[capsel22]

I was able to resolve the issue by reverting back to libtorrent 1.x AND binding network interface to "tun0" and IP address to "All IPv4"
Container has been up for 15 days without issues.

Could you share your compose config? Just not sure how to bind it to tun0

[SinTan1729]

@capsel22 No need for the config. It can be done in the settings. I believe it's right on top of the advanced/connections settings tab.

[nomisunrider]

I was able to resolve the issue by reverting back to libtorrent 1.x AND binding network interface to "tun0" and IP address to "All IPv4" Container has been up for 15 days without issues.

This is working for me for several days so far. Thanks!

[capsel22]

Just wanted to say qBittorrent works absolutely fine when I bind it to "tun0" and IP address to "All IPv4".
Didn't even have to use libtorrent 1.x container.
Thanks for everyone's advise

[SinTan1729]

For me, just binding it to tun0 is enough. Been working for around 3 months.

[ksurl]

binding tun0 and ipv4 does not resolve for me on the latest gluetun (v3.33.0) and qb (lscr.io/linuxserver/qbittorrent) release

[tonytamps]

I'm similar to ksurl

Latest gluetun and linuxserver/qbittorrent, networked through gluetun using --network=container:gluetun, loses connection periodically, and seems to related to gluetun losing the VPN connection briefly (maybe?)

[EZ64cool]

You've both said you're using linuxserver/qbittorrent, have you tried linuxserver/qbittorrent:libtorrentv1 with these settings?
Curious to see if it helps you too

[capsel22]

Thats what I need to do. Bind tun0 in qbit settings and use libtorrentv1 image. Works like a dream

[tonytamps]

I haven't tried but next time it happens I will try that.

[ksurl]

problem is that is a really old image and doesn't get updated. i'm going to test the longer timeout first.

[EZ64cool]

problem is that is a really old image and doesn't get updated. i'm going to test the longer timeout first.

That branch gets updated as regularly as the normal release.
https://hub.docker.com/layers/linuxserver/qbittorrent/libtorrentv1/images/sha256-8b1f7e6361c007fcb560b9e7307e8540760d5f8b660f323a96124b4dc9387d4b?context=explore
It's just built using libtorrentv1 instead of the newer, less stable version of libtorrent.

[nomisunrider]

No issues for me since I went to qbittorrent with v1 libtorrent

[ksurl]

problem is that is a really old image and doesn't get updated. i'm going to test the longer timeout first.

That branch gets updated as regularly as the normal release.

https://hub.docker.com/layers/linuxserver/qbittorrent/libtorrentv1/images/sha256-8b1f7e6361c007fcb560b9e7307e8540760d5f8b660f323a96124b4dc9387d4b?context=explore

It's just built using libtorrentv1 instead of the newer, less stable version of libtorrent.

Oh, I'll give it a try if the timeout is insufficient

[tonytamps]

I haven't tried but next time it happens I will try that.

Coming back to say that using a version of libtorrentv1 wasn't enough, it died again after a week, but using a version of libtorrentv1 AND binding qBittorrent to the wg0 interface was rock solid for a month.

Thanks all.

[genericapplesauce]

Is the ultimate solution to use the libtorrentv1 version? Has anyone opened an issue for this either in qBittorrent and/or LibTorrent?

Seems pretty widespread from Googling.

[ksurl]

Is the ultimate solution to use the libtorrentv1 version? Has anyone opened an issue for this either in qBittorrent and/or LibTorrent?

Seems pretty widespread from Googling.

the workaround is using portcheck alongside qb if you don't want to switch to a different client like transmission.

[genericapplesauce]

Is the ultimate solution to use the libtorrentv1 version? Has anyone opened an issue for this either in qBittorrent and/or LibTorrent?
Seems pretty widespread from Googling.

the workaround is using portcheck alongside qb if you don't want to switch to a different client like transmission.

Sorry for needing some hand-holding, but could you link some docs to the portcheck you're referring to? Or are you referring to generally checking the port with a healthcheck in docker compose or something?

[cjom]

I just want to share a solution I managed to get working, with qBitTorrent 4.6.4 on linux.
I run a script that detects if the "dht_nodes" drop to zero and if it stays at zero for a bit then it fully stops qBitTorrent and starts it again.

#!/bin/sh
while true
do
  sleep 60
  # Get the cookies if did not before
  [ -f /tmp/.cookies.txt ] || curl -s -b /tmp/.cookies.txt -c /tmp/.cookies.txt --header 'Referer: http://127.0.0.1:YOURPORT' --data 'username=YOURUSERNAME&password=YOURPASSWORD' http://127.0.0.1:YOURPORT/api/v2/auth/login
  # Check if dht_nodes is zero every minute
  if [ "$(curl -s -b /tmp/.cookies.txt -c /tmp/.cookies.txt --header 'Referer: http://127.0.0.1:YOURPORT' http://127.0.0.1:YOURPORT/api/v2/transfer/info | jq '.dht_nodes')" -eq "0" ]
  then
    failcount=$((failcount+1))
  else
    failcount=0
  fi
  # If dht_nodes is zero for 5 minutes, restart qBitTorrent
  if [ $failcount -gt 5 ]
  then
    /etc/init.d/qBittorrent.sh stop
    sleep 20
    /etc/init.d/qBittorrent.sh start
  fi
done &

You need curl and jq, also edit YOURUSERNAME, YOURPASSWORD and YOURPORT to your case.