Transmission Appears to Connect to PIA but will not Connect to Trackers.

[tim2thatom]

Describe the problem Since October 31st 2020 Transmission has stopped connecting to trackers. Sonarr and Radarr are both still able to connect with Transmission but fails to connect or download. My previous Docker Compose worked flawlessly for over two years. I've added PIA_OPENVPN_CONFIG_BUNDLE=openvpn-ip-nextgen, changed the OPENVPN_CONFIG to Israel, and changed the DNS to Google. I tested the container with wget -qO- http://ipecho.net/plain | xargs echo and it returns the PIA Israel server ip so it appears to be connecting to PIA however the trackers will not initialize. I've looked through the other reports of issues with PIA and have tried all solutions I've come across but Transmission still refuses to connect. Any help would be greatly appreciated.

Add your docker run command Current Docker Compose

  transmission-vpn:
    container_name: transmission-vpn
    image: haugene/transmission-openvpn
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    restart: always
    ports:
      - "9091:9091"
    dns:
      - 8.8.8.8
      - 8.8.4.4
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ${USERDIR}/docker/transmission-vpn:/data
      - ${USERDIR}/docker/shared:/shared
      - ${USERDIR}/mnt/downloads:/data/watch
      - ${USERDIR}/mnt/downloads/completed:/data/completed                                                                    - ${USERDIR}/mnt/downloads/incomplete:/data/incomplete
    environment:
      - OPENVPN_PROVIDER=PIA
      - OPENVPN_USERNAME=p
      - OPENVPN_PASSWORD=
      - PIA_OPENVPN_CONFIG_BUNDLE=openvpn-ip-nextgen
      - OPENVPN_CONFIG=Israel
      - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60
      - LOCAL_NETWORK=192.168.84.0/24
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true
      - TRANSMISSION_RPC_HOST_WHITELIST="127.0.0.1,192.168.84.*,192.168.85.*"
      - TRANSMISSION_RPC_PASSWORD=
      - TRANSMISSION_RPC_USERNAME=
      - TRANSMISSION_UMASK=002

Previously Working Docker Compose

  transmission-vpn:
    container_name: transmission-vpn
    image: haugene/transmission-openvpn
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    restart: always
    ports:
      - "9091:9091"
    dns:
      - 1.1.1.1
      - 1.0.0.1
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ${USERDIR}/docker/transmission-vpn:/data
      - ${USERDIR}/docker/shared:/shared
      - ${USERDIR}/mnt/downloads:/data/watch
      - ${USERDIR}/mnt/downloads/completed:/data/completed                                                                    - ${USERDIR}/mnt/downloads/incomplete:/data/incomplete
    environment:
      - OPENVPN_PROVIDER=PIA
      - OPENVPN_USERNAME=p
      - OPENVPN_PASSWORD=
      - OPENVPN_CONFIG=US Texas
      - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60
      - LOCAL_NETWORK=192.168.84.0/24
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true
      - TRANSMISSION_RPC_HOST_WHITELIST="127.0.0.1,192.168.84.*,192.168.85.*"
      - TRANSMISSION_RPC_PASSWORD=
      - TRANSMISSION_RPC_USERNAME=
      - TRANSMISSION_UMASK=002

Logs

Using OpenVPN provider: PIA,
Provider PIA has a custom startup script, executing it,
Downloading OpenVPN config bundle openvpn-ip-nextgen into temporary file /tmp/tmp.nmhcIL,
Extract OpenVPN config bundle into PIA directory /etc/openvpn/pia,
Modify configs for this container,
Starting OpenVPN using config Israel.ovpn,
Setting OpenVPN credentials...,
adding route to local network 192.168.84.0/24 via 172.18.0.1 dev eth0,
Thu Nov 12 13:40:08 2020 OpenVPN 2.4.9 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr 20 2020,
Thu Nov 12 13:40:08 2020 library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10,
Thu Nov 12 13:40:08 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts,
Thu Nov 12 13:40:08 2020 CRL: loaded 1 CRLs from file [[INLINE]],
Thu Nov 12 13:40:08 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]185.77.248.10:1198,
Thu Nov 12 13:40:08 2020 UDP link local: (not bound),
Thu Nov 12 13:40:08 2020 UDP link remote: [AF_INET]185.77.248.10:1198,
Thu Nov 12 13:40:08 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this,
Thu Nov 12 13:40:09 2020 [jerusalem401] Peer Connection Initiated with [AF_INET]185.77.248.10:1198,
Thu Nov 12 13:40:10 2020 TUN/TAP device tun0 opened,
Thu Nov 12 13:40:10 2020 /sbin/ip link set dev tun0 up mtu 1500,
Thu Nov 12 13:40:10 2020 /sbin/ip addr add dev tun0 10.1.112.5/24 broadcast 10.1.112.255,
Thu Nov 12 13:40:10 2020 /etc/openvpn/tunnelUp.sh tun0 1500 1558 10.1.112.5 255.255.255.0 init,
Up script executed with tun0 1500 1558 10.1.112.5 255.255.255.0 init,
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.1.112.5,
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.1.112.5,
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 rpc-authentication-required because TRANSMISSION_RPC_AUTHENTICATION_REQUIRED is set to true,
Overriding rpc-host-whitelist because TRANSMISSION_RPC_HOST_WHITELIST is set to 127.0.0.1,192.168.84.*,192.168.85.*,
Overriding rpc-password because TRANSMISSION_RPC_PASSWORD is set to [REDACTED],
Overriding rpc-port because TRANSMISSION_RPC_PORT is set to 9091,
Overriding rpc-username because TRANSMISSION_RPC_USERNAME is set to tim-nuc-transmission,
Overriding umask because TRANSMISSION_UMASK is set to 002,
Overriding watch-dir because TRANSMISSION_WATCH_DIR is set to /data/watch,
sed'ing True to true,
Enforcing ownership on transmission config directories,
Applying permissions to transmission config directories,
Setting owner for transmission paths to 1000:999,
chown: /data/completed/movie-radarr: Operation not permitted,
chown: /data/completed/movie-radarr: Operation not permitted,
chown: /data/completed/tv-sonarr: Operation not permitted,
chown: /data/completed/tv-sonarr: Operation not permitted,
chown: /data/completed: Operation not permitted,
chown: /data/completed: Operation not permitted,
chown: /data/incomplete: Operation not permitted,
chown: /data/incomplete: Operation not permitted,
chown: /data/watch/#recycle: Operation not permitted,
chown: /data/watch/#recycle: Operation not permitted,
chown: /data/watch/completed/movie-radarr: Operation not permitted,
chown: /data/watch/completed/movie-radarr: Operation not permitted,
chown: /data/watch/completed/tv-sonarr: Operation not permitted,
chown: /data/watch/completed/tv-sonarr: Operation not permitted,
chown: /data/watch/completed: Operation not permitted,
chown: /data/watch/completed: Operation not permitted,
chown: /data/watch/incomplete: Operation not permitted,
chown: /data/watch/incomplete: Operation not permitted,
chown: /data/watch: Operation not permitted,
chown: /data/watch: Operation not permitted,
Setting permission for files (644) and directories (755),
Setting permission for watch directory (775) and its files (664),
chmod: /data/watch: Operation not permitted,
chmod: /data/watch: Operation not permitted,
,
-------------------------------------,
Transmission will run as,
-------------------------------------,
User name:   abc,
User uid:    1000,
User gid:    999,
-------------------------------------,
,
STARTING TRANSMISSION,
Provider PIA has a script for automatic port forwarding. Will run it now.,
If you want to disable this, set environment variable DISABLE_PORT_UPDATER=yes,
Transmission startup script complete.,
Thu Nov 12 13:40:10 2020 Initialization Sequence Completed,
,
,
,
yes: Broken pipe,
port is 28024,
the port has been bound to 28024  Thu Nov 12 13:40:18 EST 2020,
transmission auth required,
waiting for transmission to become responsive,
transmission became responsive,
     2    n/a       None  Unknown      0.0     0.0   None  Idle         Unsolved.Mysteries.S15.COMPLETE.1080p.NF.WEBRip.DDP5.1.Atmos.x264-NTG[rartv],
Sum:                None               0.0     0.0,
setting transmission port to 28024,
localhost:9091/transmission/rpc/ responded: "success",
Checking port...,
Port is open: Yes,
,
initial setup complete!,
,
waiting for rebind loop.................,
token expiry 1610624360,
remaining = 5417930,
the port has been bound to 28024  Thu Nov 12 14:10:30 EST 2020,
the port has been bound to 28024  Thu Nov 12 14:40:31 EST 2020,

Host system:

Ubuntu 18.04.5 LTS Docker Engine - Community Version: 19.03.13 docker-compose version 1.21.2, build a133471

[lastb0isct]

Check your settings.json and docker-compose.yaml. It could be that you enable speed limit, but do not overwrite it to the correct values in this case you will see very low speed as per default https://github.com/haugene/docker-transmission-openvpn/blob/master/transmission/default-settings.json

@GAS85 -- settings.json looks fine, nothing about limiting the download speed (it is set to false). In my yml I only have these specified

      - TRANSMISSION_INCOMPLETE_DIR=/mnt/freenas/Downloads/TOR
      - TRANSMISSION_SCRIPT_TORRENT_DONE_ENABLED=true
      - TRANSMISSION_SCRIPT_TORRENT_DONE_FILENAME=/scripts/on-complete.sh
      - TRANSMISSION_RATIO_LIMIT_ENABLED=true
      - TRANSMISSION_RATIO_LIMIT=2
      - TRANSMISSION_SPEED_LIMIT_UP_ENABLED=true
      - TRANSMISSION_SPEED_LIMIT_UP=3000

here is the settings.json

{
    "alt-speed-down": 50,
    "alt-speed-enabled": false,
    "alt-speed-time-begin": 540,
    "alt-speed-time-day": 127,
    "alt-speed-time-enabled": false,
    "alt-speed-time-end": 1020,
    "alt-speed-up": 50,
    "bind-address-ipv4": "10.28.112.38",
    "bind-address-ipv6": "::",
    "blocklist-enabled": false,
    "blocklist-url": "http://www.example.com/blocklist",
    "cache-size-mb": 4,
    "dht-enabled": true,
    "download-dir": "/data/completed",
    "download-limit": 100,
    "download-limit-enabled": 0,
    "download-queue-enabled": true,
    "download-queue-size": 5,
    "encryption": 1,
    "idle-seeding-limit": 30,
    "idle-seeding-limit-enabled": false,
    "incomplete-dir": "/mnt/freenas/Downloads/TOR",
    "incomplete-dir-enabled": true,
    "lpd-enabled": false,
    "max-peers-global": 240,
    "message-level": 2,
    "peer-congestion-algorithm": "",
    "peer-id-ttl-hours": 6,
    "peer-limit-global": 200,
    "peer-limit-per-torrent": 50,
    "peer-port": 51413,
    "peer-port-random-high": 65535,
    "peer-port-random-low": 49152,
    "peer-port-random-on-start": false,
    "peer-socket-tos": "default",
    "pex-enabled": true,
    "port-forwarding-enabled": false,
    "preallocation": 1,
    "prefetch-enabled": true,
    "queue-stalled-enabled": true,
    "queue-stalled-minutes": 30,
    "ratio-limit": 2,
    "ratio-limit-enabled": true,
    "rename-partial-files": true,
    "rpc-authentication-required": false,
    "rpc-bind-address": "0.0.0.0",
    "rpc-enabled": true,
    "rpc-host-whitelist": "",
    "rpc-host-whitelist-enabled": false,
    "rpc-password": "{73ad144c5e5b8ae43ccc2f563d0886800e4f6aaft4Bl4wnn",
    "rpc-port": 9091,
    "rpc-url": "/transmission/",
    "rpc-username": "username",
    "rpc-whitelist": "127.0.0.1,::1",
    "rpc-whitelist-enabled": false,
    "scrape-paused-torrents-enabled": true,
    "script-torrent-done-enabled": true,
    "script-torrent-done-filename": "/scripts/on-complete.sh",
    "seed-queue-enabled": false,
    "seed-queue-size": 10,
    "speed-limit-down": 100,
    "speed-limit-down-enabled": false,
    "speed-limit-up": 3000,
    "speed-limit-up-enabled": true,
    "start-added-torrents": true,
    "trash-original-torrent-files": false,
    "umask": 2,
    "upload-slots-per-torrent": 14,
    "utp-enabled": false,
    "watch-dir": "/data/watch",
    "watch-dir-enabled": true,
    "watch-dir-force-generic": false
}

[erajtob]

I've been having the same problem, all of a sudden today all my UDP trackers stopped working, the HTTP/S ones were working mostly fine, I use PROTONVPN and I tried running it through another regular transmission install on a raspberry pi with the same vpn config and it was working fine there.

Deleting the transmission-home directory and restarting the container fixed my issue too, I just re-added all my torrents and it verified the local data and everything is working again.

[d4real]

Yes ! Removing the transmission-home worked for me too ! I tried removing only settings.json and dht.datfrom the folder first and it did not work.

Thanks @GAS85 for the solution

This worked for me too! I initially just renamed the "transmission-home" directory to '-old' but it didn't work. Second time around I renamed the now new "transmissions-home" to -old2 and then deleting the .json file and after recreating the docker container everything worked again.

[CurtC2]

I had stuck at magnet link torrents, connection refused UDP trackers. After reading this thread, in my docker compose I changed only: Old: TRANSMISSION_RATIO_LIMIT=0.1 New: TRANSMISSION_RATIO_LIMIT=1

Deleted the container image, up'd it again, voila the torrents started right up from UDP trackers

[cbturnertx]

I thought this might be pertinent: I don't use compose. I run the container from the command line or a bash script, using the env-transmission-openvpn file, on Ubuntu server. I'm a PIA user. I started seeing this problem when I upgraded to Ubuntu 20.x with do-release-upgrade, and I was totally hosed, not being able to connect to trackers. Drove me crazy. After some testing with VMs, both kvm and vmware player under Win10, I believe I've proven that I can be set up and running again quickly on anything up through 19.10, using the exact same scripts and directory structure. 20.x is still a no-go. I think it might have something to do with release 20.

[CurtC2]

FYI, I'm on Ubuntu 18.04.5 LTS and was experiencing this.

[cbturnertx]

I just re-read your previous comment, CurtC2, regarding the TRANSMISSION_RATIO_LIMIT. Mine has always been set to 10 with no decimal, so that shouldn't have influenced my testing. I think I will delete the transmission_home directory and test on the failing machine, just to see. Don't know how that would affect things though, because in each case, I rsync my docker/bin and docker/apps directory structures to the new machine, and transmission home is under there. Still, it wouldn't hurt to check it out.

15 minutes later: deleting that subdirectory fixed the problem. Many, many thanks!

[lastb0isct]

Well, looks like even AFTER doing the fix and being fine for almost a month I am seeing the same issue crop up again. If this is going to be a recurring issue I may have to ditch this as it is not behaving well at all anymore.

EDIT: Removing settings.json fixed it. Can we get someone to look into what is causing this issue?! Is there a different json format required now? What is causing it to not initialize magnet links after a period of time? I can provide logs or anything else required.

[haugene]

If that's all it takes to get it working again then it would be interesting to know how the settings.json looks like before you have to delete it, and then the new one that gets created after. The difference between those hopefully points us in the right direction.

If you help out finding what's causing it I'm in on trying to fix it :slightly_smiling_face:

[gacpac]

@haugene If you want PM me and we can test couple things. I have not had issues ever since, previously it was the value the seed ratio that wouldn't take decimal value, but that's been fixed.

Only thing I did, because the template changed was backup my settings.json and delete the template. Then I copied back my settings.json and I've been adding the override values slowly to easier modifications, although settings.json changes are persistent I rather use the GUI to make changes if needed.

[lastb0isct]

If that's all it takes to get it working again then it would be interesting to know how the settings.json looks like before you have to delete it, and then the new one that gets created after. The difference between those hopefully points us in the right direction.

If you help out finding what's causing it I'm in on trying to fix it 🙂

That would have been smart of me -- I usually back up files before I delete them too! Next time this happens I will keep an eye on it.

EDIT: I actually found my original settings.json.bkp from when I was having the issue the first time. Here is the file that was broken:

{
    "alt-speed-down": 50,
    "alt-speed-enabled": false,
    "alt-speed-time-begin": 540,
    "alt-speed-time-day": 127,
    "alt-speed-time-enabled": false,
    "alt-speed-time-end": 1020,
    "alt-speed-up": 50,
    "bind-address-ipv4": "10.15.112.172",
    "bind-address-ipv6": "::",
    "blocklist-enabled": false,
    "blocklist-url": "http://www.example.com/blocklist",
    "cache-size-mb": 4,
    "dht-enabled": true,
    "download-dir": "/data/completed",
    "download-limit": 100,
    "download-limit-enabled": 0,
    "download-queue-enabled": true,
    "download-queue-size": 5,
    "encryption": 1,
    "idle-seeding-limit": 30,
    "idle-seeding-limit-enabled": false,
    "incomplete-dir": "/mnt/freenas/Downloads/TOR",
    "incomplete-dir-enabled": true,
    "lpd-enabled": false,
    "max-peers-global": 240,
    "message-level": 2,
    "peer-congestion-algorithm": "",
    "peer-id-ttl-hours": 6,
    "peer-limit-global": 200,
    "peer-limit-per-torrent": 50,
    "peer-port": 51413,
    "peer-port-random-high": 65535,
    "peer-port-random-low": 49152,
    "peer-port-random-on-start": false,
    "peer-socket-tos": "default",
    "pex-enabled": true,
    "port-forwarding-enabled": false,
    "preallocation": 1,
    "prefetch-enabled": true,
    "queue-stalled-enabled": true,
    "queue-stalled-minutes": 30,
    "ratio-limit": 2,
    "ratio-limit-enabled": true,
    "rename-partial-files": true,
    "rpc-authentication-required": false,
    "rpc-bind-address": "0.0.0.0",
    "rpc-enabled": true,
    "rpc-host-whitelist": "",
    "rpc-host-whitelist-enabled": false,
    "rpc-password": "{da10aaf0a15f82810deb90e8f5d78a5bc5e88d39h4IirJQ2",
    "rpc-port": 9091,
    "rpc-url": "/transmission/",
    "rpc-username": "username",
    "rpc-whitelist": "127.0.0.1,::1",
    "rpc-whitelist-enabled": false,
    "scrape-paused-torrents-enabled": true,
    "script-torrent-done-enabled": true,
    "script-torrent-done-filename": "/scripts/on-complete.sh",
    "seed-queue-enabled": false,
    "seed-queue-size": 10,
    "speed-limit-down": 100,
    "speed-limit-down-enabled": false,
    "speed-limit-up": 3000,
    "speed-limit-up-enabled": true,
    "start-added-torrents": true,
    "trash-original-torrent-files": false,
    "umask": 2,
    "upload-slots-per-torrent": 14,
    "utp-enabled": false,
    "watch-dir": "/data/watch",
    "watch-dir-enabled": true,
    "watch-dir-force-generic": false
}

Here is the file now after I've deleted and recreated:

{
    "alt-speed-down": 50,
    "alt-speed-enabled": false,
    "alt-speed-time-begin": 540,
    "alt-speed-time-day": 127,
    "alt-speed-time-enabled": false,
    "alt-speed-time-end": 1020,
    "alt-speed-up": 50,
    "bind-address-ipv4": "10.25.112.247",
    "bind-address-ipv6": "::",
    "blocklist-enabled": false,
    "blocklist-url": "http://www.example.com/blocklist",
    "cache-size-mb": 4,
    "dht-enabled": true,
    "download-dir": "/mnt/freenas/Downloads/TOR",
    "download-queue-enabled": true,
    "download-queue-size": 5,
    "encryption": 1,
    "idle-seeding-limit": 30,
    "idle-seeding-limit-enabled": false,
    "incomplete-dir": "/mnt/freenas/Downloads/Incomplete",
    "incomplete-dir-enabled": true,
    "lpd-enabled": false,
    "message-level": 2,
    "peer-congestion-algorithm": "",
    "peer-id-ttl-hours": 6,
    "peer-limit-global": 240,
    "peer-limit-per-torrent": 60,
    "peer-port": 51413,
    "peer-port-random-high": 65535,
    "peer-port-random-low": 49152,
    "peer-port-random-on-start": false,
    "peer-socket-tos": "default",
    "pex-enabled": true,
    "port-forwarding-enabled": false,
    "preallocation": 1,
    "prefetch-enabled": true,
    "queue-stalled-enabled": true,
    "queue-stalled-minutes": 30,
    "ratio-limit": 2,
    "ratio-limit-enabled": true,
    "rename-partial-files": true,
    "rpc-authentication-required": false,
    "rpc-bind-address": "0.0.0.0",
    "rpc-enabled": true,
    "rpc-host-whitelist": "",
    "rpc-host-whitelist-enabled": false,
    "rpc-password": "{5a230261f8c6d20f0cde23b14c372e20932497f4V76apVn4",
    "rpc-port": 9091,
    "rpc-url": "/transmission/",
    "rpc-username": "username",
    "rpc-whitelist": "127.0.0.1,::1",
    "rpc-whitelist-enabled": false,
    "scrape-paused-torrents-enabled": true,
    "script-torrent-done-enabled": true,
    "script-torrent-done-filename": "/scripts/on-complete.sh",
    "seed-queue-enabled": false,
    "seed-queue-size": 10,
    "speed-limit-down": 10000,
    "speed-limit-down-enabled": true,
    "speed-limit-up": 3000,
    "speed-limit-up-enabled": true,
    "start-added-torrents": true,
    "trash-original-torrent-files": false,
    "umask": 2,
    "upload-slots-per-torrent": 14,
    "utp-enabled": false,
    "watch-dir": "/data/watch",
    "watch-dir-enabled": true,
    "watch-dir-force-generic": false
}

And the diff between the two:

diff transmission-home/settings.json transmission-home.bkp/settings.json.bkp

9c9
<     "bind-address-ipv4": "10.25.112.247",
---
>     "bind-address-ipv4": "10.15.112.172",
15c15,17
<     "download-dir": "/mnt/freenas/Downloads/TOR",
---
>     "download-dir": "/data/completed",
>     "download-limit": 100,
>     "download-limit-enabled": 0,
21c23
<     "incomplete-dir": "/mnt/freenas/Downloads/Incomplete",
---
>     "incomplete-dir": "/mnt/freenas/Downloads/TOR",
23a26
>     "max-peers-global": 240,
27,28c30,31
<     "peer-limit-global": 240,
<     "peer-limit-per-torrent": 60,
---
>     "peer-limit-global": 200,
>     "peer-limit-per-torrent": 50,
48c51
<     "rpc-password": "{5a230261f8c6d20f0cde23b14c372e20932497f4V76apVn4",
---
>     "rpc-password": "{da10aaf0a15f82810deb90e8f5d78a5bc5e88d39h4IirJQ2",
59,60c62,63
<     "speed-limit-down": 10000,
<     "speed-limit-down-enabled": true,
---
>     "speed-limit-down": 100,
>     "speed-limit-down-enabled": false,

[ilike2burnthing]

I recognise some of these differences - https://github.com/haugene/docker-transmission-openvpn/commit/e5cba237e06176232cdc402b1d3b40a42ac729b9 & https://github.com/haugene/docker-transmission-openvpn/commit/32e7fd4a661e0a3fec1cd0d762dfd742d307800f

Really hope I've not been the cause of all these issues 😐

[haugene]

@gacpac Did you some specific testing in mind? I don't know what I would do to try to force it to happen. It seems like it occurs after some time running the container?

@lastb0isct Great that you found it. That gives us one data point to consider. Now hopefully others also can post something similar and we can see if there are any overlapping changes. I would be a bit surprised if it is those changes @ilike2burnthing. After all, the new settings.json file that he gets after removing the old one works. So if anything, you fixed it? :man_shrugging:

Looking at the diff above I have two main suspects. Although I don't really understand why they should be so bad. Number one is a concern that the ipv4 bind address somehow didn't get updated. If Transmission is not bound to the right address then it wouldn't be able to connect to anything. But... That has been working for years and there is no real change there now I think. Second is the "download-limit": 100, "download-limit-enabled": 0, because they reference download and because the limit-enabled: 0 is a bit weird. It should be boolean? I would expect Transmission to just interpret it as false but.

If it happens again. First take a backup of the settings.json, then try just restarting the container to make sure that this isn't just Transmission getting a deadlock of sorts, backup the settings.json again (ipv4 should have changed, nothing else) and finally remove settings.json and we'll make a new diff with the new one if it works after the template has created it.

Not sure what else to do. But I'm grateful for the help in debugging and I want to help out to get to the bottom of this :thinking:

[gacpac]

I might be assumming on this one but every time the settings have something they don't like that's when problem starts. This is the output of my settings.json and the "download-limit":100 doesn't exist. Instead I have this "speed-limit-down": 100, "speed-limit-down-enabled": false, which makes more sense as opposed to 0

Please see my settings.json

/data/transmission-home # cat settings.json { "alt-speed-down": 50, "alt-speed-enabled": false, "alt-speed-time-begin": 540, "alt-speed-time-day": 127, "alt-speed-time-enabled": false, "alt-speed-time-end": 1020, "alt-speed-up": 50, "bind-address-ipv4": "10.43.111.18", "bind-address-ipv6": "::", "blocklist-enabled": true, "blocklist-url": "http://john.bitsurge.net/public/biglist.p2p.gz", "cache-size-mb": 10, "dht-enabled": true, "download-dir": "/downloads", "download-queue-enabled": true, "download-queue-size": 50, "encryption": 1, "idle-seeding-limit": 30, "idle-seeding-limit-enabled": true, "incomplete-dir": "/downloads/incomplete", "incomplete-dir-enabled": true, "lpd-enabled": false, "message-level": 2, "peer-congestion-algorithm": "", "peer-id-ttl-hours": 6, "peer-limit-global": 400, "peer-limit-per-torrent": 80, "peer-port": 57358, "peer-port-random-high": 65535, "peer-port-random-low": 49152, "peer-port-random-on-start": false, "peer-socket-tos": "default", "pex-enabled": true, "port-forwarding-enabled": true, "preallocation": 1, "prefetch-enabled": true, "queue-stalled-enabled": true, "queue-stalled-minutes": 30, "ratio-limit": 0.3000, "ratio-limit-enabled": true, "rename-partial-files": true, "rpc-authentication-required": false, "rpc-bind-address": "0.0.0.0", "rpc-enabled": true, "rpc-host-whitelist": "", "rpc-host-whitelist-enabled": false, "rpc-password": "{c7cb95e8e658f2357fecc3a9a468879419bdca0fm8NwMv/L", "rpc-port": 9091, "rpc-url": "/transmission/", "rpc-username": "admin", "rpc-whitelist": "127.0.0.1,::1", "rpc-whitelist-enabled": false, "scrape-paused-torrents-enabled": true, "script-torrent-done-enabled": false, "script-torrent-done-filename": "", "seed-queue-enabled": false, "seed-queue-size": 10, "speed-limit-down": 100, "speed-limit-down-enabled": false, "speed-limit-up": 100, "speed-limit-up-enabled": false, "start-added-torrents": true, "trash-original-torrent-files": false, "umask": 18, "upload-slots-per-torrent": 14, "utp-enabled": true

[gacpac]

And you know what. I installed the transmission for Windows version and looked at the default settings.

Also looked the values over from the official transmission site. https://github.com/transmission/transmission/wiki/Editing-Configuration-Files#bandwidth-1

This are the correct values from a fresh install.
"speed-limit-down": 100, "speed-limit-down-enabled": false,

[ilike2burnthing]

download-limit and download-limit-enabled are long depreciated values for Transmission, and were removed here in https://github.com/haugene/docker-transmission-openvpn/pull/1523/

What wasn't included, was a method to scrub these settings from established installs, it just changed what settings were used as default.

I'll have a play about with my settings file to see if I can recreate the issues and pin down what the specific cause is.

[gacpac]

I totally get what you are saying, it should be fixed like you say. I'm going based on @lastb0isct settings.json file

[ilike2burnthing]

I'm using NordVPN rather than PIA, but I wasn't able to reproduce any issues.

The quick test was stopping the container, changing the settings file, restarting the container, adding a magnet, then waiting for it to connect to trackers, fill the torrent's information, and begin to download.

If there's any problem with that methodology let me know and I'll repeat with necessary adjustments.

I changed/added:

"download-limit": 100,
"download-limit-enabled": 0,
"max-peers-global": 240,
"peer-limit-global": 200,
"peer-limit-per-torrent": 50,

Without issue, I am already using:

"speed-limit-down": 100,
"speed-limit-down-enabled": false,

No difference when just adding "download-limit": 100, and "download-limit-enabled": 0,, was able to download fine.

This would leave the settings to look at being:

9c9
<     "bind-address-ipv4": "10.25.112.247",
---
>     "bind-address-ipv4": "10.15.112.172",
15c15,17
<     "download-dir": "/mnt/freenas/Downloads/TOR",
---
>     "download-dir": "/data/completed",
21c23
<     "incomplete-dir": "/mnt/freenas/Downloads/Incomplete",
---
>     "incomplete-dir": "/mnt/freenas/Downloads/TOR",
48c51
<     "rpc-password": "{5a230261f8c6d20f0cde23b14c372e20932497f4V76apVn4",
---
>     "rpc-password": "{da10aaf0a15f82810deb90e8f5d78a5bc5e88d39h4IirJQ2",

@lastb0isct do your old download-dir and incomplete-dir look like they would have been correct at the time? Just wondering if /data/completed in particular could have been a problem.

[lastb0isct]

It happened to me again! I have gathered a BUNCH of info this time (startup logs, settings.json, etc). Have a busy day but will upload later today when I have time. For now, the difference between the settings.json files (settings.json is the one that was created after recreating the container):

 root /mnt/jails/transmission/transmission-home    $ diff settings.json ~/transmission.settings.json                                                                                                                                   PLEX
9c9
<     "bind-address-ipv4": "10.29.112.136",
---
>     "bind-address-ipv4": "10.60.112.7",
29c29
<     "peer-port": 51413,
---
>     "peer-port": 0,
48c48
<     "rpc-password": "{4f9c02fc79391b35c0a4e86669eaef3f478c205bhc5pgo7m",
---
>     "rpc-password": "{5a230261f8c6d20f0cde23b14c372e20932497f4V76apVn4",

EDIT: It looks like the peer-port is getting erased on the version that was not working...

[lastb0isct]

Here is some more information on this.

Restarting the docker container does not fix the issue. Stopping, deleting settings.json, recreating the container fixes the issue. Here is the entire container log before I removed the settings.json (this is after a restart of the container but with the same settings.json):

adding route to local network 192.168.0.0/16 via 172.20.0.1 dev eth0,
Thu Dec 17 08:46:38 2020 OpenVPN 2.4.9 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr 20 2020,
Thu Dec 17 08:46:38 2020 library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10,
Thu Dec 17 08:46:38 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts,
Thu Dec 17 08:46:38 2020 CRL: loaded 1 CRLs from file [[INLINE]],
Thu Dec 17 08:46:38 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]154.21.20.52:1198,
Thu Dec 17 08:46:38 2020 UDP link local: (not bound),
Thu Dec 17 08:46:38 2020 UDP link remote: [AF_INET]154.21.20.52:1198,
Thu Dec 17 08:46:38 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this,
Thu Dec 17 08:46:38 2020 [seattle413] Peer Connection Initiated with [AF_INET]154.21.20.52:1198,
Thu Dec 17 08:46:39 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options,
Thu Dec 17 08:46:39 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: 2000::/3,
Thu Dec 17 08:46:39 2020 TUN/TAP device tun0 opened,
Thu Dec 17 08:46:39 2020 /sbin/ip link set dev tun0 up mtu 1500,
Thu Dec 17 08:46:39 2020 /sbin/ip addr add dev tun0 10.19.112.143/24 broadcast 10.19.112.255,
Thu Dec 17 08:46:39 2020 /etc/openvpn/tunnelUp.sh tun0 1500 1553 10.19.112.143 255.255.255.0 init,
Up script executed with tun0 1500 1553 10.19.112.143 255.255.255.0 init,
Executing /scripts/transmission-pre-start.sh,
/scripts/transmission-pre-start.sh returned 0,
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.19.112.143,
Using Combustion UI, overriding TRANSMISSION_WEB_HOME,
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.29.112.136,
Overriding download-dir because TRANSMISSION_DOWNLOAD_DIR is set to /mnt/freenas/Downloads/TOR,
Overriding incomplete-dir because TRANSMISSION_INCOMPLETE_DIR is set to /mnt/freenas/Downloads/Incomplete,
Overriding ratio-limit because TRANSMISSION_RATIO_LIMIT is set to 2,
Overriding ratio-limit-enabled because TRANSMISSION_RATIO_LIMIT_ENABLED is set to true,
Overriding rpc-port because TRANSMISSION_RPC_PORT is set to 9091,
Overriding script-torrent-done-enabled because TRANSMISSION_SCRIPT_TORRENT_DONE_ENABLED is set to true,
Overriding script-torrent-done-filename because TRANSMISSION_SCRIPT_TORRENT_DONE_FILENAME is set to /scripts/on-complete.sh,
Overriding speed-limit-down because TRANSMISSION_SPEED_LIMIT_DOWN is set to 10000,
Overriding speed-limit-down-enabled because TRANSMISSION_SPEED_LIMIT_DOWN_ENABLED is set to true,
Overriding speed-limit-up because TRANSMISSION_SPEED_LIMIT_UP is set to 3000,
Overriding speed-limit-up-enabled because TRANSMISSION_SPEED_LIMIT_UP_ENABLED is set to true,
Overriding watch-dir because TRANSMISSION_WATCH_DIR is set to /data/watch,
sed'ing True to true,
,
-------------------------------------,
Transmission will run as,
-------------------------------------,
User name:   root,
User uid:    0,
User gid:    0,
-------------------------------------,
,
STARTING TRANSMISSION,
Provider PIA has a script for automatic port forwarding. Will run it now.,
If you want to disable this, set environment variable DISABLE_PORT_UPDATER=true,
Transmission startup script complete.,
Thu Dec 17 08:46:39 2020 WARNING: OpenVPN was configured to add an IPv6 route over tun0. However, no IPv6 has been configured for this interface, therefore the route installation may fail or may not work as expected.,
Thu Dec 17 08:46:39 2020 Initialization Sequence Completed,
Running functions for token based port fowarding,
curl: (7) Failed to connect to 10.19.112.1 port 19999: Connection refused,
Thu Dec 17 08:46:45 PST 2020: getSignature error,
,
the has been a fatal_error,
date: invalid date '',
curl: (7) Failed to connect to 10.19.112.1 port 19999: Connection refused,
Thu Dec 17 08:46:45 PST 2020: bindPort error,
,
the has been a fatal_error,
transmission auth not required,
waiting for transmission to become responsive,
transmission became responsive,
     2    n/a       None  Unknown      0.0     0.0   None  Idle         
Sum:            111.2 GB               0.0     0.0,
setting transmission port to ,
localhost:9091/transmission/rpc/ responded: "success",
Checking port...,
Error: portTested: http error 400: Bad Request,
date: invalid date '@',
#######################,
        SUCCESS        ,
#######################,
Port: ,
Expiration ,
#######################,
Entering infinite while loop,
Every 15 minutes, check port status,
60 day port reservation reached,
Getting a new one,
curl: (7) Failed to connect to 10.19.112.1 port 19999: Connection refused,
Thu Dec 17 08:46:57 PST 2020: getSignature error,
,
the has been a fatal_error,
date: invalid date '',
curl: (7) Failed to connect to 10.19.112.1 port 19999: Connection refused,
Thu Dec 17 08:46:57 PST 2020: bindPort error,
,
the has been a fatal_error,
transmission auth not required,
waiting for transmission to become responsive,
transmission became responsive,
     2    n/a       None  Unknown      0.0     0.0   None  Idle         
Sum:            111.2 GB             349.0    49.0,
setting transmission port to ,
localhost:9091/transmission/rpc/ responded: "success",
Checking port...,
Error: portTested: http error 400: Bad Request,

Here is the log AFTER deleting the settings.json and recreating (working state):

adding route to local network 192.168.0.0/16 via 172.20.0.1 dev eth0,
Thu Dec 17 08:57:16 2020 OpenVPN 2.4.9 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr 20 2020,
Thu Dec 17 08:57:16 2020 library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10,
Thu Dec 17 08:57:16 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts,
Thu Dec 17 08:57:16 2020 CRL: loaded 1 CRLs from file [[INLINE]],
Thu Dec 17 08:57:16 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]212.102.46.222:1198,
Thu Dec 17 08:57:16 2020 UDP link local: (not bound),
Thu Dec 17 08:57:16 2020 UDP link remote: [AF_INET]212.102.46.222:1198,
Thu Dec 17 08:57:16 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this,
Thu Dec 17 08:57:16 2020 [seattle425] Peer Connection Initiated with [AF_INET]212.102.46.222:1198,
Thu Dec 17 08:57:17 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options,
Thu Dec 17 08:57:17 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: 2000::/3,
Thu Dec 17 08:57:17 2020 TUN/TAP device tun0 opened,
Thu Dec 17 08:57:17 2020 /sbin/ip link set dev tun0 up mtu 1500,
Thu Dec 17 08:57:17 2020 /sbin/ip addr add dev tun0 10.29.112.136/24 broadcast 10.29.112.255,
Thu Dec 17 08:57:17 2020 /etc/openvpn/tunnelUp.sh tun0 1500 1553 10.29.112.136 255.255.255.0 init,
Up script executed with tun0 1500 1553 10.29.112.136 255.255.255.0 init,
Executing /scripts/transmission-pre-start.sh,
/scripts/transmission-pre-start.sh returned 0,
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.29.112.136,
Using Combustion UI, overriding TRANSMISSION_WEB_HOME,
Updating Transmission settings.json with values from env variables,
Generating settings.json for Transmission from environment and defaults /etc/transmission/default-settings.json,
Overriding bind-address-ipv4 because TRANSMISSION_BIND_ADDRESS_IPV4 is set to 10.29.112.136,
Overriding download-dir because TRANSMISSION_DOWNLOAD_DIR is set to /mnt/freenas/Downloads/TOR,
Overriding incomplete-dir because TRANSMISSION_INCOMPLETE_DIR is set to /mnt/freenas/Downloads/Incomplete,
Overriding ratio-limit because TRANSMISSION_RATIO_LIMIT is set to 2,
Overriding ratio-limit-enabled because TRANSMISSION_RATIO_LIMIT_ENABLED is set to true,
Overriding rpc-port because TRANSMISSION_RPC_PORT is set to 9091,
Overriding script-torrent-done-enabled because TRANSMISSION_SCRIPT_TORRENT_DONE_ENABLED is set to true,
Overriding script-torrent-done-filename because TRANSMISSION_SCRIPT_TORRENT_DONE_FILENAME is set to /scripts/on-complete.sh,
Overriding speed-limit-down because TRANSMISSION_SPEED_LIMIT_DOWN is set to 10000,
Overriding speed-limit-down-enabled because TRANSMISSION_SPEED_LIMIT_DOWN_ENABLED is set to true,
Overriding speed-limit-up because TRANSMISSION_SPEED_LIMIT_UP is set to 3000,
Overriding speed-limit-up-enabled because TRANSMISSION_SPEED_LIMIT_UP_ENABLED is set to true,
Overriding watch-dir because TRANSMISSION_WATCH_DIR is set to /data/watch,
sed'ing True to true,
,
-------------------------------------,
Transmission will run as,
-------------------------------------,
User name:   root,
User uid:    0,
User gid:    0,
-------------------------------------,
,
STARTING TRANSMISSION,
Provider PIA has a script for automatic port forwarding. Will run it now.,
If you want to disable this, set environment variable DISABLE_PORT_UPDATER=true,
Transmission startup script complete.,
Thu Dec 17 08:57:17 2020 WARNING: OpenVPN was configured to add an IPv6 route over tun0. However, no IPv6 has been configured for this interface, therefore the route installation may fail or may not work as expected.,
Thu Dec 17 08:57:17 2020 Initialization Sequence Completed,
Running functions for token based port fowarding,
curl: (7) Failed to connect to 10.29.112.1 port 19999: Connection refused,
Thu Dec 17 08:57:23 PST 2020: getSignature error,
,
the has been a fatal_error,
date: invalid date '',
curl: (7) Failed to connect to 10.29.112.1 port 19999: Connection refused,
Thu Dec 17 08:57:23 PST 2020: bindPort error,
,
the has been a fatal_error,
transmission auth not required,
waiting for transmission to become responsive,
transmission became responsive,
     2    n/a       None  Unknown      0.0     0.0   None  Idle         
Sum:            111.8 GB               0.0     0.0,
setting transmission port to ,
localhost:9091/transmission/rpc/ responded: "success",
Checking port...,
Error: portTested: http error 400: Bad Request,
date: invalid date '@',
#######################,
        SUCCESS        ,
#######################,
Port: ,
Expiration ,
#######################,
Entering infinite while loop,
Every 15 minutes, check port status,
60 day port reservation reached,
Getting a new one,
curl: (7) Failed to connect to 10.29.112.1 port 19999: Connection refused,
Thu Dec 17 08:57:35 PST 2020: getSignature error,
,
the has been a fatal_error,
date: invalid date '',
curl: (7) Failed to connect to 10.29.112.1 port 19999: Connection refused,
Thu Dec 17 08:57:35 PST 2020: bindPort error,
,
the has been a fatal_error,
transmission auth not required,
waiting for transmission to become responsive,
transmission became responsive,
     2    n/a       None  Unknown      0.0     0.0   None  Idle         
Sum:            111.8 GB            1265.0   334.0,
setting transmission port to ,
localhost:9091/transmission/rpc/ responded: "success",
Checking port...,
Error: portTested: http error 400: Bad Request,

[d4real]

@lastb0isct I'm getting the same thing you are seeing. The container will work for some time but then just randomly stop working, new torrents will try and download but they stay stuck at the "magnetized" step.

To get the container working again I usually delete settings.json in the transmission-home directory, then I rename transmission-home to something like transmission-home-old. I then recreate the container in Portainer and toggle "pull latest image" and everything works again.

I did a diff against the settings.json file when it wasn't working compared to when it is working and the only difference was the bind IP and rpc password which I don't think would make a difference but I could be wrong.

9c9 < "bind-address-ipv4": "10.44.112.226",

"bind-address-ipv4": "10.41.112.75",

48c48 < "rpc-password": "{59303e83dcc85a2cb2e07003bc021ea4c8f3ac505rvyp9Wl",

"rpc-password": "{c37866fc4b51d7be8fdff33a45b135d3c4328bfdiAJEkcZy",

I will check the logs next time and compare a non-working container vs a working one.

[lastb0isct]

@d4real -- I just had it happen again. same as you but with the peer-port being 0 in the not-working json.

[Djangox]

Guys, this isn't just a PIA thing. I use both PRIVATEVPN & SLICKVPN and no love. sometime around Thanksgiving I updated to "latest" after so long with no issues. I was not able to connect to any of my 1500+ torrents across multiple private trackers (all mine are https no UDP). I can't even get IPMAGNET (http) to work. Torrents are stuck either "updating" or "could not connect to tracker". After futzing around (with all the PIA issues here) for a week or two I was able to start connecting my torrents very slowly [starting with all stopped then enabling in batches of about 20] (question- how do you delete TRANSMISSION-HOME when you got 1500+ seeds going?). However, I was never stable. took a long time to enable all torrents and I'd never get 100% connectivity. AND we're talking from the same tracker I could have a mix of connected/not connected. torrents would "randomly" loose their connectivity at time of update.

I don't know of any additional information that I could provide that hasn't already been given by others, other than I am running on Synology and prior to the update my "original" container was created via the Synology GUI and I had filled out a lot of the "Environment variables". When I did the update in November, I had just began with Portainer, so I used that to do a recreate w/pull latest image. I've also tried using exported json of container settings (Synology feature) to recreate container from "scratch" via an import of the json (keeping the same "data" volume on my host... 1500 torrents..sigh).. I have also tried creating from command line, docker-compose, all with same results. I just wish I knew what "latest" I was on before that killer update so I could at least try and go back. OH..., additional information... in my circumstance (don't recall anyone else reporting), I am also experiencing timeouts connecting to the container via transgui (and disconnects) and web interface.

I have now been up & running for 59 minutes and am currently looking at 1 "working" torrent. the other two "active" torrents are "could not connect to tracker", but have a single peer each.

[ilike2burnthing]

Try just deleting the settings and dht json files and restarting Transmission.

[Djangox]

been there done that. I swear I tried EVERY "solution" each person claimed... I started rolling back to each earlier release... 2.14 seems to have fixed my issue. I've been "stable" for the last day and a half. So.. something in the way the 3.x code is different than the 2.x code may be the culprit?

[eth0izzle]

I was having the same issue and nothing in this thread worked for me. What did work was switching to the dev branch by updating your docker-compose to

image: haugene/transmission-openvpn:dev

[Djangox]

@eth0izzle I'll give that a try as now that I am up and running using the 2.14 tag, transmission is constantly failing (openvpn up, transmission down). did find the autoheal container suggestion on here to work around that issue (but sometimes that's not even working).

[eth0izzle]

@Djangox I spoke too soon. It's died off after ~5 hours. Really frustrating. I'll try the 2.14 tag now.

[lastb0isct]

:dev didn't work for me either. I haven't tried the 2.14 tag yet...maybe i'll give that a shot

[ilike2burnthing]

Currently the only difference between latest and dev is https://github.com/haugene/docker-transmission-openvpn/commit/53d3f05b7a1cad1a93f98fb99dec4fc9fee5ba6e, so there's no reason for one to work and not the other.

@Djangox, if you're up for trying something (hopefully at least slightly different to what you have already tried), backup the transmission-home folder elsewhere and delete the original. Pull latest/dev image with your current settings, download a new torrent, see if your issues continue.

If so, delete the new transmission-home folder, and try using these stripped back settings, download a torrent again and see if your issues still continue.

If at either point things seem to be resolved, copy the resume and torrents folders from your backup to the new transmission-home folder, redeploy, and see if that has solved things.

If it only works with the stripped back settings, you'll have to work out which of your settings was causing the problem - add them back in blocks until the problem repeats, then narrow it down until you find the problematic one(s).

If it doesn't work even when downloading a new torrent with the stripped back settings, then try adding DNS options (try Cloudflare's 1.1.1.1/1.0.0.1 as well). You can add the env OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60 as well, and set the container to always restart.

That's pretty much everything I can think of, so hopefully something sticks.

[Djangox]

using dev image is also a "no go". Same results as using "latest" or anything above 2.14. All torrents error out with "could not connect to tracker" and local client timing out/disconnecting.

edit: didn't refresh my screen before posting. I didn't see the replies. I'm starting to get the feeling with all the PIA "broken" talk, devs have done a lot to resolve PIA integration with this container and possibly breaking (inadvertently of course) other configs in the process.

I will give your "minimum" config a try. already tried brand new containers using default params other than my OpenVPN info, multiple vendors. just NOT PIA (torrents immediately fail) on a different machine (as well as on this one that I am currently struggling with) during all the failed testing. I'm already passing resolv.conf to container and doubt it's DNS related as I am able to resolve the trackers from a console into the container. I've also tried tracker by IP address (I think..that may have been prior to this issue).

[lastb0isct]

I am still experiencing the issues every couple days or so...

[ilike2burnthing]

Up for trying the above as well?

[lastb0isct]

Will try when I get the time! Thanks!

[cbturnertx]

Just thought I'd send a ray of sunshine. 23 days ago, I deleted the subdirectory and re-started. Mine's been running like a scalded dog ever since.

[Djangox]

Looked at your "minimal" settings. Basically "use all defaults except VPN config". Been there done that. Nothing above 2.14 works brand new or otherwise.

Here is what is created w/"latest":

PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
OPENVPN_USERNAME | **None**
OPENVPN_PASSWORD | **None**
OPENVPN_PROVIDER | **None**
GLOBAL_APPLY_PERMISSIONS | true
TRANSMISSION_HOME | /data/transmission-home
TRANSMISSION_RPC_PORT | 9091
TRANSMISSION_DOWNLOAD_DIR | /data/completed
TRANSMISSION_INCOMPLETE_DIR | /data/incomplete
TRANSMISSION_WATCH_DIR | /data/watch
CREATE_TUN_DEVICE | true
ENABLE_UFW | false
UFW_ALLOW_GW_NET | false
UFW_EXTRA_PORTS |  
UFW_DISABLE_IPTABLES_REJECT | false
PUID |  
PGID |  
DROP_DEFAULT_ROUTE |  
WEBPROXY_ENABLED | false
WEBPROXY_PORT | 8888
WEBPROXY_USERNAME |  
WEBPROXY_PASSWORD |  
LOG_TO_STDOUT | false
HEALTH_CHECK_HOST | google.com
REVISION | a4d65774f855a04070766e53346661f48c76fa0e

Here's what's created w/2.14:

PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DEBIAN_FRONTEND | noninteractive
OPENVPN_USERNAME | **None**
OPENVPN_PASSWORD | **None**
OPENVPN_PROVIDER | **None**
GLOBAL_APPLY_PERMISSIONS | true
TRANSMISSION_ALT_SPEED_DOWN | 50
TRANSMISSION_ALT_SPEED_ENABLED | false
TRANSMISSION_ALT_SPEED_TIME_BEGIN | 540
TRANSMISSION_ALT_SPEED_TIME_DAY | 127
TRANSMISSION_ALT_SPEED_TIME_ENABLED | false
TRANSMISSION_ALT_SPEED_TIME_END | 1020
TRANSMISSION_ALT_SPEED_UP | 50
TRANSMISSION_BIND_ADDRESS_IPV4 | 0.0.0.0
TRANSMISSION_BIND_ADDRESS_IPV6 | ::
TRANSMISSION_BLOCKLIST_ENABLED | false
TRANSMISSION_BLOCKLIST_URL | http://www.example.com/blocklist
TRANSMISSION_CACHE_SIZE_MB | 4
TRANSMISSION_DHT_ENABLED | true
TRANSMISSION_DOWNLOAD_DIR | /data/completed
TRANSMISSION_DOWNLOAD_LIMIT | 100
TRANSMISSION_DOWNLOAD_LIMIT_ENABLED | 0
TRANSMISSION_DOWNLOAD_QUEUE_ENABLED | true
TRANSMISSION_DOWNLOAD_QUEUE_SIZE | 5
TRANSMISSION_ENCRYPTION | 1
TRANSMISSION_IDLE_SEEDING_LIMIT | 30
TRANSMISSION_IDLE_SEEDING_LIMIT_ENABLED | false
TRANSMISSION_INCOMPLETE_DIR | /data/incomplete
TRANSMISSION_INCOMPLETE_DIR_ENABLED | true
TRANSMISSION_LPD_ENABLED | false
TRANSMISSION_MAX_PEERS_GLOBAL | 200
TRANSMISSION_MESSAGE_LEVEL | 2
TRANSMISSION_PEER_CONGESTION_ALGORITHM |  
TRANSMISSION_PEER_ID_TTL_HOURS | 6
TRANSMISSION_PEER_LIMIT_GLOBAL | 200
TRANSMISSION_PEER_LIMIT_PER_TORRENT | 50
TRANSMISSION_PEER_PORT | 51413
TRANSMISSION_PEER_PORT_RANDOM_HIGH | 65535
TRANSMISSION_PEER_PORT_RANDOM_LOW | 49152
TRANSMISSION_PEER_PORT_RANDOM_ON_START | false
TRANSMISSION_PEER_SOCKET_TOS | default
TRANSMISSION_PEX_ENABLED | true
TRANSMISSION_PORT_FORWARDING_ENABLED | false
TRANSMISSION_PREALLOCATION | 1
TRANSMISSION_PREFETCH_ENABLED | 1
TRANSMISSION_QUEUE_STALLED_ENABLED | true
TRANSMISSION_QUEUE_STALLED_MINUTES | 30
TRANSMISSION_RATIO_LIMIT | 2
TRANSMISSION_RATIO_LIMIT_ENABLED | false
TRANSMISSION_RENAME_PARTIAL_FILES | true
TRANSMISSION_RPC_AUTHENTICATION_REQUIRED | false
TRANSMISSION_RPC_BIND_ADDRESS | 0.0.0.0
TRANSMISSION_RPC_ENABLED | true
TRANSMISSION_RPC_HOST_WHITELIST |  
TRANSMISSION_RPC_HOST_WHITELIST_ENABLED | false
TRANSMISSION_RPC_PASSWORD | password
TRANSMISSION_RPC_PORT | 9091
TRANSMISSION_RPC_URL | /transmission/
TRANSMISSION_RPC_USERNAME | username
TRANSMISSION_RPC_WHITELIST | 127.0.0.1
TRANSMISSION_RPC_WHITELIST_ENABLED | false
TRANSMISSION_SCRAPE_PAUSED_TORRENTS_ENABLED | true
TRANSMISSION_SCRIPT_TORRENT_DONE_ENABLED | false
TRANSMISSION_SCRIPT_TORRENT_DONE_FILENAME |  
TRANSMISSION_SEED_QUEUE_ENABLED | false
TRANSMISSION_SEED_QUEUE_SIZE | 10
TRANSMISSION_SPEED_LIMIT_DOWN | 100
TRANSMISSION_SPEED_LIMIT_DOWN_ENABLED | false
TRANSMISSION_SPEED_LIMIT_UP | 100
TRANSMISSION_SPEED_LIMIT_UP_ENABLED | false
TRANSMISSION_START_ADDED_TORRENTS | true
TRANSMISSION_TRASH_ORIGINAL_TORRENT_FILES | false
TRANSMISSION_UMASK | 2
TRANSMISSION_UPLOAD_LIMIT | 100
TRANSMISSION_UPLOAD_LIMIT_ENABLED | 0
TRANSMISSION_UPLOAD_SLOTS_PER_TORRENT | 14
TRANSMISSION_UTP_ENABLED | false
TRANSMISSION_WATCH_DIR | /data/watch
TRANSMISSION_WATCH_DIR_ENABLED | true
TRANSMISSION_HOME | /data/transmission-home
TRANSMISSION_WATCH_DIR_FORCE_GENERIC | false
ENABLE_UFW | false
UFW_ALLOW_GW_NET | false
UFW_EXTRA_PORTS |  
UFW_DISABLE_IPTABLES_REJECT | false
TRANSMISSION_WEB_UI |  
PUID |  
PGID |  
TRANSMISSION_WEB_HOME |  
DROP_DEFAULT_ROUTE |  
WEBPROXY_ENABLED | false
WEBPROXY_PORT | 8888
WEBPROXY_USERNAME |  
WEBPROXY_PASSWORD |  
HEALTH_CHECK_HOST | google.com
DOCKER_LOG | false
LOG_TO_STDOUT | false

The only actual parameters that stand out between 2.x & 3.x is "CREATE_TUN_DEVICE" and on my Synology I had tried both true & false with no difference to outcome. Also tried changing the "GLOBAL_APPLY_PERMISSIONS" true breaks other apps for me, but new install of transmission container works the same no matter if it's true or false (2.14 works / later doesn't).

Also.. between the time I was working with no issue and then flat out not... I was pretty sure that I took a 2.x to 3.x update (however in addition to latest I have also tried 3.0,3.1,3.2,3.3 tags that all fail).

My original container was based on 2.10, I then switched to using the "latest" tag when time to update to 2.11 or 2.12.

[Djangox]

Just thought I'd send a ray of sunshine. 23 days ago, I deleted the subdirectory and re-started. Mine's been running like a scalded dog ever since.

by chance, who's your OpenVPN provider?

[cbturnertx]

PIA

[Djangox]

PIA

thought so. GRIN

[ndokmai]

@Djangox I'm also using PIA but I eventually got the issue resolved. The problem I had wasn't with PIA by itself because running PIA's own binary on my Ubuntu Desktop works. (This is some thing you might want to try yourself to double check.) I tried a combination of deleting transmission-home and changing PIA's region. It finally started working when I switched to the dev branch.

[Djangox]

@ndokmai My belief is that there has been code changes in this container (3.x flavor) that created this "tracker disconnect" issue. The fact that everyone with "resolved" appear to be PIA only (unless I missed others), kinda points to there possibly being PIA only fixes. I would expect you running things outside of the container w/PIA would work, same as for me, a different container I run with QBittorrent & my current VPN provider also work (as well as ver 2.14 of this container), this was/is a container specific problem. The more I think about it, I don't know if my issue began BEFORE/WITH the first reported PIA failure (which would point to generic 3.x code change). (the first "issues" that I read were opened way before I noticed I had a problem) or AFTER the first reported PIA "fix" (which would point to a change made in 3.x to fix PIA "can't connect to tracker" issue broke me).

[rutravis]

I'm running the full stack with Torguard on docker 19.03.08 (portainer-ce 2.0) on ARM64 Ubuntu 20.10 on a raspberry pi 4 (4gb version). Using latest version of image. All works well. I did change the containers to always restart as sometimes they would stop. Finding media in radarr, using jackett as indexer, and download via transmission-openvpn. Works great.

On Sat, Jan 2, 2021, 1:23 PM Djangox notifications@github.com wrote:

@ndokmai https://github.com/ndokmai My belief is that there has been code changes in this container (3.x flavor) that created this "tracker disconnect" issue. The fact that everyone with "resolved" appear to be PIA only (unless I missed others), kinda points to there possibly being PIA only fixes. I would expect you running things outside of the container w/PIA would work, same as for me, a different container I run with QBittorrent & my current VPN provider also work (as well as ver 2.14 of this container), this was/is a container specific problem. The more I think about it, I don't know if my issue began BEFORE/WITH the first reported PIA failure (which would point to generic 3.x code change). (the first "issues" that I read were opened way before I noticed I had a problem) or AFTER the first reported PIA "fix" (which would point to a change made in 3.x to fix PIA "can't connect to tracker" issue broke me).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/haugene/docker-transmission-openvpn/issues/1507#issuecomment-753512000, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQXJ5PFI75JX7MASOEJS5YTSX5QCTANCNFSM4TTW62FA .

[rutravis]

I would like to see transmission upgraded to the new 3.0 version. UI is much improved.

On Sat, Jan 2, 2021, 1:47 PM Travis Tompkins rutravis@gmail.com wrote:

I'm running the full stack with Torguard on docker 19.03.08 (portainer-ce 2.0) on ARM64 Ubuntu 20.10 on a raspberry pi 4 (4gb version). Using latest version of image. All works well. I did change the containers to always restart as sometimes they would stop. Finding media in radarr, using jackett as indexer, and download via transmission-openvpn. Works great.

On Sat, Jan 2, 2021, 1:23 PM Djangox notifications@github.com wrote:

@ndokmai https://github.com/ndokmai My belief is that there has been code changes in this container (3.x flavor) that created this "tracker disconnect" issue. The fact that everyone with "resolved" appear to be PIA only (unless I missed others), kinda points to there possibly being PIA only fixes. I would expect you running things outside of the container w/PIA would work, same as for me, a different container I run with QBittorrent & my current VPN provider also work (as well as ver 2.14 of this container), this was/is a container specific problem. The more I think about it, I don't know if my issue began BEFORE/WITH the first reported PIA failure (which would point to generic 3.x code change). (the first "issues" that I read were opened way before I noticed I had a problem) or AFTER the first reported PIA "fix" (which would point to a change made in 3.x to fix PIA "can't connect to tracker" issue broke me).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/haugene/docker-transmission-openvpn/issues/1507#issuecomment-753512000, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQXJ5PFI75JX7MASOEJS5YTSX5QCTANCNFSM4TTW62FA .

[opswhisperer]

Seeing the same as everyone else. Setting PIA_OPENVPN_CONFIG_BUNDLE=openvpn-tcp seemed to work for me (for now)

[lastb0isct]

@opswhisperer -- Doesn't seem to fix my setup.

I have competely recreated my /data directory from scratch. Still not having constant success with this. It seems to do well for a few days and then drop just as before. Any other ideas on what we can look into here?

I might just create my own setup with VPN configured outside of this...

[GAS85]

That comment was hidden https://github.com/haugene/docker-transmission-openvpn/issues/1507#issuecomment-727578613, but somehow root cause is in the Transmission configuration. Try to delete your transmission config from compose file and transmission folder and then check if it works, add back line by line to find out what is wrong!

[lastb0isct]

I have done just this...to no avail.

[lastb0isct]

Okay, one interesting thing I've found -- If i remove the transmission-home folder (moving the "torrents" folder to /tmp) and recreate the container, shutdown the container, add ONLY the contents of the torrents folder (all of the torrents I had going previously) and restart the container it can not connect to those torrents (all of them say connection errors when connecting to the trackers).

If I repeat this and instead of adding the torrents back in that way I added one of the torrents magnet links manually instead and it worked. Something is not right here....

To add to this, once i restarted the container again after I had added the torrent via magnet link it would not reconnect...

[florianehmke]

Had the same issue - was solved by adding --pull-filter ignore ping to the Open VPN options (see docs: https://haugene.github.io/docker-transmission-openvpn/faq/#set_the_ping-exit_option_for_openvpn_and_restart-flag_in_docker):

OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60 --pull-filter ignore ping

On top of that I had to set DNS via OVERRIDE_DNS_1 + 2, although that was probably an unrelated problem.

[Djangox]

@florianehmke not sure what OPENVPN exit/restart options would have to do with "tracker not connecting". it's not a DNS issue either. trackers by name or ip... there's no descrimination.