Bug: qbittorrent docker often stuck on finding metadata when using wireguard

[illuvattarr]

Is this urgent?

No

Host OS

docker synology NAS

CPU arch

None

VPN service provider

Surfshark

What are you using to run the container

Portainer

What is the version of Gluetun

latest image from qmcgaw/gluetun

What's the problem 🤔

I'm running gluetun together with qbittorrent in docker through compose in portainer. I'm trying to use wireguard from VPN provider Surfhshark, and often the torrents/magnet links stay stuck on finding metadata. Using openvpn does work, but I'd prefer using wireguard since speeds are higher with wireguard.

See the configuration for the compose code I use to create the stack in portainer.

Sometimes I can kickstart the torrents by changing the port in the settings of qbittorrent webui, or changing it back again. But after a while, they stay stuck again on finding metadata.

Share your logs

|       ├── 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
├── 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: 1000
├── Public IP settings:
|   ├── Fetching: every 12h0m0s
|   └── IP file path: /tmp/gluetun/ip
└── Version settings:
    └── Enabled: yes
2022-12-03T10:56:44Z INFO IPv6 is not supported
2022-12-03T10:56:44Z INFO [routing] default route found: interface eth0, gateway 172.23.0.1 and assigned IP 172.23.0.2
2022-12-03T10:56:44Z INFO [routing] adding route for 0.0.0.0/0
2022-12-03T10:56:44Z INFO [firewall] setting allowed subnets...
2022-12-03T10:56:44Z INFO [routing] default route found: interface eth0, gateway 172.23.0.1 and assigned IP 172.23.0.2
2022-12-03T10:56:44Z INFO TUN device is not available: open /dev/net/tun: no such file or directory; creating it...
2022-12-03T10:56:44Z INFO [pprof] http server listening on [::]:6060
2022-12-03T10:56:44Z INFO [dns over tls] using plaintext DNS at address 1.1.1.1
2022-12-03T10:56:44Z INFO [http server] http server listening on [::]:8000
2022-12-03T10:56:44Z INFO [healthcheck] listening on 127.0.0.1:9999
2022-12-03T10:56:44Z INFO [firewall] allowing VPN connection...
2022-12-03T10:56:44Z INFO [wireguard] Using available kernelspace implementation
2022-12-03T10:56:44Z INFO [wireguard] Connecting to 89.46.223.229:51820
2022-12-03T10:56:44Z INFO [wireguard] Wireguard is up
2022-12-03T10:56:44Z INFO [dns over tls] downloading DNS over TLS cryptographic files
2022-12-03T10:56:52Z INFO [healthcheck] program has been unhealthy for 6s: restarting VPN
2022-12-03T10:56:52Z INFO [vpn] stopping
2022-12-03T10:56:52Z ERROR [vpn] cannot get version information: Get "https://api.github.com/repos/qdm12/gluetun/commits": context canceled
2022-12-03T10:56:52Z INFO [vpn] starting
2022-12-03T10:56:52Z INFO [firewall] allowing VPN connection...
2022-12-03T10:56:52Z INFO [wireguard] Using available kernelspace implementation
2022-12-03T10:56:52Z INFO [wireguard] Connecting to 81.19.208.56:51820
2022-12-03T10:56:52Z INFO [wireguard] Wireguard is up
2022-12-03T10:56:54Z WARN [dns over tls] cannot update files: Get "https://www.internic.net/domain/named.root": dial tcp: lookup www.internic.net on 1.1.1.1:53: read udp 10.14.0.2:41672->1.1.1.1:53: i/o timeout
2022-12-03T10:56:54Z INFO [dns over tls] attempting restart in 10s
2022-12-03T10:57:03Z INFO [healthcheck] program has been unhealthy for 11s: restarting VPN
2022-12-03T10:57:03Z INFO [vpn] stopping
2022-12-03T10:57:03Z INFO [vpn] starting
2022-12-03T10:57:03Z INFO [firewall] allowing VPN connection...
2022-12-03T10:57:03Z INFO [wireguard] Using available kernelspace implementation
2022-12-03T10:57:03Z INFO [wireguard] Connecting to 178.239.173.43:51820
2022-12-03T10:57:03Z INFO [wireguard] Wireguard is up
2022-12-03T10:57:04Z INFO [healthcheck] healthy!
2022-12-03T10:57:04Z INFO [dns over tls] downloading DNS over TLS cryptographic files
2022-12-03T10:57:06Z INFO [dns over tls] downloading hostnames and IP block lists
2022-12-03T10:57:12Z INFO [healthcheck] unhealthy: cannot dial: dial tcp4: lookup cloudflare.com: i/o timeout(see https://github.com/qdm12/gluetun/wiki/Healthcheck)
2022-12-03T10:57:14Z INFO [dns over tls] init module 0: validator
2022-12-03T10:57:14Z INFO [dns over tls] init module 1: iterator
2022-12-03T10:57:14Z INFO [dns over tls] start of service (unbound 1.15.0).
2022-12-03T10:57:14Z INFO [dns over tls] generate keytag query _ta-4a5c-4f66. NULL IN
2022-12-03T10:57:14Z INFO [dns over tls] generate keytag query _ta-4a5c-4f66. NULL IN
2022-12-03T10:57:14Z INFO [dns over tls] ready
2022-12-03T10:57:14Z INFO [healthcheck] healthy!

Share your configuration

version: "3.5"
services:
  vpn:
    image: qmcgaw/gluetun
    container_name: gluetun-wireguard
    cap_add:
      - net_admin
    environment:
      - VPN_SERVICE_PROVIDER=surfshark
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=[KEY]
      - WIREGUARD_ADDRESSES=10.14.0.2/16
      - SERVER_COUNTRIES=Netherlands
      - SERVER_HOSTNAMES=nl-ams-mp001.prod.surfshark.com,nl-ams-st001.prod.surfshark.com,nl-ams.prod.surfshark.com
    ports:
      - 8080:8080
      - 6881:6881/tcp
      - 6881:6881/udp
  torrent:
    depends_on:
      - vpn
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: container:gluetun-wireguard
    environment:
      - WEBUI_PORT=8080
      - PUID=1027
      - PGID=100
      - TZ=Europe/Amsterdam
    volumes:
      - /volume1/docker/qbittorrent:/config
      - /volume1/video/downloads:/video/downloads
    restart: always

[qdm12]

1. Have you tried with another torrent client like Deluge?
2. Are you sure this never happens with Openvpn?
3. You could try with the new environment variable WIREGUARD_IMPLEMENTATION=userspace (pull the latest image, that was done yesterday) see if it helps?

Honestly I doubt this has to do with the vpn protocol. Maybe Surfshark filters on their wireguard vpn servers, but anyway that's out of our control.

[frepke]

Why using
depends_on: - vpn and network_mode: container:gluetun-wireguard for your torrent
instead of network_mode: "service:vpn"?

[illuvattarr]

Thanks for the suggestions. For the few days I tried with openvpn, it never happened at least. And with wireguard, it happened again immediately.

I added WIREGUARD_IMPLEMENTATION=userspace and also replaced depends_on: - vpn and network_mode: container:gluetun-wireguard with network_mode: "service:vpn" in the compose code. And so far so good at least; wireguard is working without issues at the moment.
What does the wireguard_implementation variable add?

[illuvattarr]

Well it just started happening again after all. All torrents stay stuck on finding metadata.

I tried to switch to Deluge but there torrents stay stuck on downloading 0.00% with different tracker status errors; skipping tracker announce (unreachable) or host not found (authoritative).

Im using the compose code below to set deluge up:

version: "3.5"
services:
  vpn:
    image: qmcgaw/gluetun:latest
    container_name: gluetun-wireguard
    cap_add:
      - net_admin
    environment:
      - VPN_SERVICE_PROVIDER=surfshark
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=key
      - WIREGUARD_ADDRESSES=10.14.0.2/16
      - SERVER_COUNTRIES=Netherlands
    ports:
      - 8080:8112
      - 6881:6881/tcp
      - 6881:6881/udp
  deluge:
    image: lscr.io/linuxserver/deluge:latest
    container_name: deluge
    network_mode: "service:vpn"
    environment:
      - PUID=1027
      - PGID=1000
      - TZ=Europe/Amsterdam
      - DELUGE_LOGLEVEL=error #optional
    volumes:
      - /volume1/docker/deluge:/config
      - /volume1/video/downloads:/video/downloads
    restart: unless-stopped

[dfadev]

I would try to repro using a different VPN provider to rule out the provider being the issue.

[bnhf]

@illuvattarr

There's a mistake in both your stacks. The linuxserver/deluge and linuxserver/qbittorrent containers both need a volume binding to /downloads not /video/downloads

[illuvattarr]

It turns out it the Deluge errors were due to another mistake in the compose code; PGID for me is 100 and not 1000 and I forgot to change it when copying the default compose code from the Deluge docker website...
So far Deluge is working now without issues like torrents staying stuck after changing 1000 to 100.

[qdm12]

What does the wireguard_implementation variable add?

The kernelspace implementation (written in C in your Linux Kernel) is meant to be faster (at least as fast) as the userspace implementation (written in Go, built in Gluetun). So previously and now by default, Gluetun picks the kernel one if available and falls back on the userspace one (for older/custom kernels). Now you can choose, really to debug and bench testing.

So far Deluge is working now
Sometimes I can kickstart the torrents by changing the port in the settings of qbittorrent webui, or changing it back again.

Cool, I'll close this issue for now, feel free to comment if it dies again.
Maybe, maybe... it's due to how Qbittorrent handles IP changes/VPN reconnections ([healthcheck] program has been unhealthy for 11s: restarting VPN which can happen occasionally), and Deluge may handle it better. I personally use Deluge but I have not really a preference on this, so I can't say more 😉