Docker-transmission-openvpn: cannot connect to the tracker after container's update

[sesshomaru86]

hi people,

i'm running this awesome container for quite some time now (around 1-2 years) i would say, never had a similar issue. I have Ouroboros that updates the container quite often but this time after the latest update it seems that every torrent cannot connect to the tracker. I tried to delete completely the entire image redownload it etc but nothing seems to make it work. From the logs i don't see some critical error or something and it seems that it can connect to the nordvpn server im using . I'm attaching the log in case someone could help me identify the issue. Thanx a lot!

2020-11-01 17:39:21 Searching for group: legacy_p2p,
2020-11-01 17:39:21 Searching for technology: openvpn_tcp,
2020-11-01 17:39:21 Best server : at106.nordvpn.com,
2020-11-01 17:39:21 Downloading config: default.ovpn,
2020-11-01 17:39:21 Downloading from: https://downloads.nordcdn.com/configs/files/ovpn_tcp/servers/at106.nordvpn.com.tcp.ovpn,
2020-11-01 17:39:21 Selecting the best server...,
2020-11-01 17:39:21 Searching for country : Austria (14),
2020-11-01 17:39:21 Searching for group: legacy_p2p,
2020-11-01 17:39:21 Searching for technology: openvpn_tcp,
2020-11-01 17:39:21 Best server : at106.nordvpn.com,
2020-11-01 17:39:21 Downloading config: at106.nordvpn.com.ovpn,
2020-11-01 17:39:21 Downloading from: https://downloads.nordcdn.com/configs/files/ovpn_tcp/servers/at106.nordvpn.com.tcp.ovpn,
2020-11-01 17:39:21 Checking line endings,
2020-11-01 17:39:21 Updating configs for docker-transmission-openvpn,
Starting OpenVPN using config at106.nordvpn.com.ovpn,
Setting OpenVPN credentials...,
adding route to local network 192.168.5.0/24 via 172.18.0.1 dev eth0,
Sun Nov  1 17:39:23 2020 OpenVPN 2.4.9 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr 20 2020,
Sun Nov  1 17:39:23 2020 library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10,
Sun Nov  1 17:39:23 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts,
Sun Nov  1 17:39:23 2020 NOTE: --fast-io is disabled since we are not using UDP,
Sun Nov  1 17:39:23 2020 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication,
Sun Nov  1 17:39:23 2020 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication,
Sun Nov  1 17:39:23 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]185.244.212.51:443,
Sun Nov  1 17:39:23 2020 Socket Buffers: R=[131072->131072] S=[16384->16384],
Sun Nov  1 17:39:23 2020 Attempting to establish TCP connection with [AF_INET]185.244.212.51:443 [nonblock],
Sun Nov  1 17:39:24 2020 TCP connection established with [AF_INET]185.244.212.51:443,
Sun Nov  1 17:39:24 2020 TCP_CLIENT link local: (not bound),
Sun Nov  1 17:39:24 2020 TCP_CLIENT link remote: [AF_INET]185.244.212.51:443,
Sun Nov  1 17:39:24 2020 TLS: Initial packet from [AF_INET]185.244.212.51:443, sid=5bc6cbdd f3aa695d,
Sun Nov  1 17:39:24 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this,
Sun Nov  1 17:39:24 2020 VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA,
Sun Nov  1 17:39:24 2020 VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA5,
Sun Nov  1 17:39:24 2020 VERIFY KU OK,
Sun Nov  1 17:39:24 2020 Validating certificate extended key usage,
Sun Nov  1 17:39:24 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication,
Sun Nov  1 17:39:24 2020 VERIFY EKU OK,
Sun Nov  1 17:39:24 2020 VERIFY OK: depth=0, CN=at106.nordvpn.com,
Sun Nov  1 17:39:24 2020 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA,
Sun Nov  1 17:39:24 2020 [at106.nordvpn.com] Peer Connection Initiated with [AF_INET]185.244.212.51:443,
Sun Nov  1 17:39:25 2020 SENT CONTROL [at106.nordvpn.com]: 'PUSH_REQUEST' (status=1),
Sun Nov  1 17:39:25 2020 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 103.86.96.100,dhcp-option DNS 103.86.99.100,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,comp-lzo no,route-gateway 10.7.0.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.7.0.4 255.255.255.0,peer-id 0,cipher AES-256-GCM',
Sun Nov  1 17:39:25 2020 OPTIONS IMPORT: timers and/or timeouts modified,
Sun Nov  1 17:39:25 2020 OPTIONS IMPORT: --explicit-exit-notify can only be used with --proto udp,
Sun Nov  1 17:39:25 2020 OPTIONS IMPORT: compression parms modified,
Sun Nov  1 17:39:25 2020 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified,
Sun Nov  1 17:39:25 2020 Socket Buffers: R=[131072->425984] S=[87040->425984],
Sun Nov  1 17:39:25 2020 OPTIONS IMPORT: --ifconfig/up options modified,
Sun Nov  1 17:39:25 2020 OPTIONS IMPORT: route options modified,
Sun Nov  1 17:39:25 2020 OPTIONS IMPORT: route-related options modified,
Sun Nov  1 17:39:25 2020 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified,
Sun Nov  1 17:39:25 2020 OPTIONS IMPORT: peer-id set,
Sun Nov  1 17:39:25 2020 OPTIONS IMPORT: adjusting link_mtu to 1659,
Sun Nov  1 17:39:25 2020 OPTIONS IMPORT: data channel crypto options modified,
Sun Nov  1 17:39:25 2020 Data Channel: using negotiated cipher 'AES-256-GCM',
Sun Nov  1 17:39:25 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key,
Sun Nov  1 17:39:25 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key,
Sun Nov  1 17:39:25 2020 ROUTE_GATEWAY 172.18.0.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:12:00:06,
Sun Nov  1 17:39:25 2020 TUN/TAP device tun0 opened,
Sun Nov  1 17:39:25 2020 TUN/TAP TX queue length set to 100,
Sun Nov  1 17:39:25 2020 /sbin/ip link set dev tun0 up mtu 1500,
Sun Nov  1 17:39:25 2020 /sbin/ip addr add dev tun0 10.7.0.4/24 broadcast 10.7.0.255,
Sun Nov  1 17:39:25 2020 /etc/openvpn/tunnelUp.sh tun0 1500 1587 10.7.0.4 255.255.255.0 init,
Up script executed with tun0 1500 1587 10.7.0.4 255.255.255.0 init,
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.7.0.4,
Updating Transmission settings.json with values from env variables,
Using existing settings.json for Transmission /data/transmission-home/settings.json,
Overriding bind-address-ipv4 because TRANSMISSION_BIND_ADDRESS_IPV4 is set to 10.7.0.4,
Overriding blocklist-enabled because TRANSMISSION_BLOCKLIST_ENABLED is set to True,
Overriding blocklist-url because TRANSMISSION_BLOCKLIST_URL is set to http://john.bitsurge.net/public/biglist.p2p.gz,
Overriding download-dir because TRANSMISSION_DOWNLOAD_DIR is set to /data/completed,
Overriding incomplete-dir because TRANSMISSION_INCOMPLETE_DIR is set to /data/incomplete,
Overriding peer-limit-global because TRANSMISSION_PEER_LIMIT_GLOBAL is set to 600,
Overriding peer-limit-per-torrent because TRANSMISSION_PEER_LIMIT_PER_TORRENT is set to 150,
Could not coerce TRANSMISSION_RATIO_LIMIT value 1.00 to expected type <class 'int'>,
Traceback (most recent call last):,
  File "/etc/transmission/updateSettings.py", line 67, in <module>,
    env_value = setting_type(env_value),
ValueError: invalid literal for int() with base 10: '1.00',
sed'ing True to true,
Enforcing ownership on transmission config directories,
Applying permissions to transmission config directories,
Setting owner for transmission paths to 1000:1000,
Setting permission for files (644) and directories (755),
Setting permission for watch directory (775) and its files (664),
,
-------------------------------------,
Transmission will run as,
-------------------------------------,
User name:   abc,
User uid:    1000,
User gid:    1000,
-------------------------------------,
,
STARTING TRANSMISSION,
Transmission startup script complete.,
Sun Nov  1 17:39:31 2020 /sbin/ip route add 185.244.212.51/32 via 172.18.0.1,
Sun Nov  1 17:39:31 2020 /sbin/ip route add 0.0.0.0/1 via 10.7.0.1,
Sun Nov  1 17:39:31 2020 /sbin/ip route add 128.0.0.0/1 via 10.7.0.1,
Sun Nov  1 17:39:31 2020 Initialization Sequence Completed,

[pimvandenbroek]

I had a similar issue today, and after an hour of trying stuff, I checked the logs above:
Could not coerce TRANSMISSION_RATIO_LIMIT value 1.00 to expected type <class 'int'>,

In my docker compose file I had:

• TRANSMISSION_RATIO_LIMIT=1.00
  Changed that to:
• TRANSMISSION_RATIO_LIMIT=1

And downloading started working again. Hopefully it'll work for you too.

[sesshomaru86]

That's it mate !!! It works ! Awesome. I'm really curious how did you decrypt the info and change the specific value to make ti work ? It would be impossible every time changing everything to see what broke what. Thanx 1000x . Really appreciated , i was start breaking everything, changing firewall rules , docker setup just to make it work again. You just saved me a week full of headaches ! Cheers ! I can close the thread but i dont know if @haugene wants to note this as a bug or something. Thanx Kristian by the way once more for this awesome project !

[pimvandenbroek]

Took me a while too, as my initial error was that the openvpn file couldn't be found, even though I never changed that part.
I think somehow the data types got mixed up. Ratios have always been in decimal format, and with the latest update it suddenly expected an int. I think this is an error, as Transmission still requires ratios in decimal format. I would suggest to leave it open for now.

[haugene]

Thanks for pointing this out. It is a bug and should get fixed :+1:

Long story short. We have changed the configuration of the container where you no longer need to set all the transmission options as environment variables. You can change directly in the UI and they will stay persistent through container restarts.

We kept the support for still using the variables for backwards compatability. This flexibility comes with some complexity and we have not taken into account the decimal number arguments. #1413 fixed the last type issues, but needs to be expanded for this.

For future reference @sesshomaru86 the logs says what value is failing. In case you get in a pickle again.

Overriding peer-limit-per-torrent because TRANSMISSION_PEER_LIMIT_PER_TORRENT is set to 150,
Could not coerce TRANSMISSION_RATIO_LIMIT value 1.00 to expected type <class 'int'>,
Traceback (most recent call last):,
  File "/etc/transmission/updateSettings.py", line 67, in <module>,
    env_value = setting_type(env_value),
ValueError: invalid literal for int() with base 10: '1.00',

[mrjmg]

This did the trick for me as well, was looking into a missing .ovpn file as that was the last error shown in the log. But it was the decimal issue!
@haugene, will you keep the environment variables? I prefer using those over setting them in the GUI.

[Psytekk69]

My downloads are also blocking.
My setting TRANSMISSION_RATIO_LIMIT=15 has been updated by TRANSMISSION_RATIO_LIMIT=9 then TRANSMISSION_RATIO_LIMIT=1 but the problem persists.
I have other variables declared :

- PUID=65534
- PGID=100
- OPENVPN_PROVIDER=CUSTOM
- OPENVPN_USERNAME=user
- OPENVPN_PASSWORD=pass
- OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60
- LOCAL_NETWORK=192.168.1.0/24
- TRANSMISSION_DOWNLOAD_DIR=/data/Download
- TRANSMISSION_RATIO_LIMIT=15
- TRANSMISSION_RATIO_LIMIT_ENABLED=true
- TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true
- TRANSMISSION_RPC_USERNAME=admin
- TRANSMISSION_RPC_PASSWORD=xxxxx
- TRANSMISSION_PEER_PORT=3210

I forced version 2.13 to work around this issue.

[thm4tip]

I have the same issue. It stopped working on 10/28.
After, changed the TRANSMISSION_RATIO_LIMIT to 1. That did not fix it.
I downloaded the .openvpn files and named one explicitly in the docker_compose.yml file.
Rebuild the service image. On startup, it still says it can't find the .openvpn file.
I notice that the service keeps restarting but fails to ever come up all the way and the Web UI is not working.
Where do I have to place that .openvpn file on the host system so it gets found by the starting service?

[thm4tip]

I have the same issue. It stopped working on 10/28.
After, changed the TRANSMISSION_RATIO_LIMIT to 1. That did not fix it.
I downloaded the .openvpn files and named one explicitly in the docker_compose.yml file.
Rebuild the service image. On startup, it still says it can't find the .openvpn file.
I notice that the service keeps restarting but fails to ever come up all the way and the Web UI is not working.
Where do I have to place that .openvpn file on the host system so it gets found by the starting service?

I added

• ${MOUNT_POINT}/transmission-vpn/config/ovpn/:/etc/openvpn/custom/
  to my docker_compose, and then copied the .opvn files there.
  I also removed the "" from the
• OPENVPN_CONFIG=ipvanish-US-Los-Angeles-lax-a01
  line.
  Now the transmission is finding the VPN configuration and is starting up fine.
  Multiple VPN configuration file names can be added, separated by commas for failover.
  This fixed the problem for me.

[haugene]

@mrjmg Yes, we will keep the environment variables. At least for as far as I can see into the :crystal_ball:
We're going to try to have both options for configuration. Some options must be set through the environment though, and the rest can be done in the UI.

We're in a kind of limbo now though. If you change something in the UI it will not be reset on restart if you haven't set something for that specific environment variable. I'm thinking of adding a flag to override the settings on every container start so that you can opt in for the completely environment controlled setup.

[haugene]

@thm4tip See #1456. Since you're using IPVanish, would you mind testing a run with the dev tag of the image now? I added a script that will automatically update the configs for IPVanish on each container startup.

[haugene]

The original issue here is solved so I'm closing this.