qBittorrent Crashing on latest trigus42/qbittorrentvpn:qbt4.6.0 Image

[Blavkentropy1]

Hi Team,

A big thanks for your time in continuing this project.

I have hit a issue with the latest trigus42/qbittorrentvpn:qbt4.6.0 image that was rolled out yesterday. Which I am at a loss of what the root cause is. Hopefully this is just user error.

What is happning The qBittorrent container starts, then crashed after about 30 seconds. The Logs are not giving me any information

WorkAround This has resulted in me reverting to the previous image on my PRD continers.

Attached are the Container logs, and qBittorrent logs. The only thing that stands out to me is (W) 2023-11-10T09:45:44 - Couldn't download IP geolocation database file. Reason: The remote host name was not found (invalid hostname) That to me indicates that there is a network issue, but this is not present in the previous build.

I have built a new container, and removed alot of the custom config. This also has a new Wireguard config. Below is this new test config that I have spun up for this. The PRD containers are on the previous images.

docker run -d \ --name=qbittorrentvpn_TEST \ --cap-add=NET_ADMIN \ --cap-add=SYS_MODULE \ --sysctl net.ipv4.conf.all.src_valid_mark=1 \ -p 192.168.0.200:8121:8080 \ -e PUID=1000 \ -e PGID=1000 \ -e TZ="Australia/Melbourne" \ -e "VPN_ENABLED=yes" \ -e "VPN_TYPE=wireguard" \ -e "LAN_NETWORK=192.168.0.0/24" \ -e HEALTH_CHECK_HOST=1.1.1.1 \ -e HEALTH_CHECK_INTERVAL=300 \ -v qbittorrentvpn_config_test:/config/ \ -v qbittorrent_down_test:/downloads/ \ -v /home/ryan/Dropbox/Program/VPN/Test/:/config/wireguard \ --restart unless-stopped \ trigus42/qbittorrentvpn:qbt4.6.0

qbittorrent.log

qbittorrentvpn_TEST_logs.txt

[Blavkentropy1]

I have also tested this with a near default config, with new Volumes, and I am getting the same issue. Only alteration I made are Name Wireguard Config directory.

docker run --privileged -d \ --name=qbittorrentvpn_TEST \ -v qbittorrentvpn_config_test:/config \ -v /home/ryan/Dropbox/Program/VPN/Test/:/config/wireguard \ -v qbittorrent_down_test:/downloads \ -e "VPN_ENABLED=yes" \ -e "VPN_TYPE=wireguard" \ -e "LAN_NETWORK=192.168.0.0/24" \ -p 8080:8080 \ --restart unless-stopped \ trigus42/qbittorrentvpn

[Trigus42]

Unfortunately I could not replicate your issue.

You have got the error RTNETLINK answers: Permission denied for most of the container restarts:

2023-11-10 09:42:54 [INFO] Starting WireGuard...
--------------------
Warning: `/config/wireguard/wg0.conf' is world accessible
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.152.140.49/32 dev wg0
[#] ip -6 address add fd7d:76ee:e68f:a993:865d:d5ea:1d49:d4f/128 dev wg0
RTNETLINK answers: Permission denied
[#] ip link delete dev wg0
[cont-init.d] 02-vpn.sh: exited 2.

qBt started once but then the internet connection was detected as down, which was here:

2023-11-10 09:45:36 [INFO] Trying to ping 1.1.1.1 and 8.8.8.8 over the docker interface for 500ms each...
Terminated
Terminated
2023-11-10 09:45:38 [INFO] Success: Could not connect. This means the firewall is most likely working properly.
2023-11-10 09:45:39 [INFO] qBittorrent started with PID 547
2023-11-10 09:45:39 [INFO] HEALTH_CHECK_HOST is not set. Using default host one.one.one.one
2023-11-10 09:45:39 [INFO] HEALTH_CHECK_TIMEOUT is not set. Using default interval of 5s
2023-11-10 09:45:59 [NOTICE] Network seems to be down. Retrying..
2023-11-10 09:45:59 [ERROR] Network is down. Exiting..

Lastly it managed to establish a VPN connection but was then killed. This was probably just cause you stopped the container (?):

2023-11-10 09:46:10 [INFO] Trying to ping 1.1.1.1 and 8.8.8.8 over the docker interface for 500ms each...
[services.d] done.
Terminated
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.

It's very strange that you got RTNETLINK answers: Permission denied most of the time, but got a network timeout once. It seems like there was some problem with your Wireguard setup that was fixed (?).
The only error that I think could be caused by the changes of the latest commit is the second one. To see if your connection is falsely detected as down you could just try to set HEALTH_CHECK_TIMEOUT to a very high value and check the internet connection of qBt.
You could also try to use OpenVPN instead to see if that changes anything. Not sure if that's gonna reveal any useful information but maybe try setting the DEBUG env var to yes.

[Blavkentropy1]

Hi Trigus42,

Thanks for your time. After some more testing, I believe I have found the root cause.
The network I was putting qBittorrent on has both IPV4 and IPV6 Support. When I moved qBitorrent over to a network with just IPV4, it worked with the latest release.

Is this intended or is this a Bug?

I was able replicated this same scenario on my Raspberry PI.

[Trigus42]

IPv6 is not supported well by Docker and this image doesn't support it either. The easiest fix (which I would also recommend to most users) is to remove the IPv6 config from your Wireguard config file (change AllowedIPs = 0.0.0.0/0, ::/0 to AllowedIPs = 0.0.0.0/0 in your Wireguard config).

However I created a branch called "nftables" which (also) adds experimental support for IPv6. The error RTNETLINK answers: Permission denied is not an error with this image, but occurs because you probably have net.ipv6.conf.all.disable_ipv6 set to 1.

If you want to try out IPv6 support I would suggest this (base) compose file:

version: "3.3"

services:
  app:
    image: trigus42/qbittorrentvpn:nftables
    container_name: qbittorrent-test
    environment:
      - VPN_ENABLED=yes
      - VPN_TYPE=wireguard
      - DEBUG=yes
    volumes:
      - './config:/config'
      - '/lib/modules:/lib/modules'
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.all.disable_ipv6=0
    networks:
      ip6net:
    privileged: true

networks:
  ip6net:
     enable_ipv6: true
     ipam:
       config:
         - subnet: fd5d:467f:97cd:b805::/112

You also need to enable IPv6 support for Docker: https://docs.docker.com/config/daemon/ipv6/

[Blavkentropy1]

Thanks Trigus,

I have removed IPV6 from my docker setup completely. As I don't use if for anything., this is a holdover from when I had IPV6 Support from my last ISP. As you said, it is not very well implemented in Docker, so it seems to cause more issues than it is worth. With just IPV4, everything is working perfectly.

Thanks for you assistance.