Container stuck in bootloop

[Mega-Bits]

Is there a pinned issue for this?

• [X] I have read the pinned issues and could not find my issue

Is there an existing or similar issue/discussion for this?

• [X] I have searched the existing issues
• [X] I have searched the existing discussions

Is there any comment in the documentation for this?

• [X] I have read the documentation, especially the FAQ and Troubleshooting parts

Is this related to a provider?

• [X] I have checked the provider repo for issues
• [X] My issue is NOT related to a provider

Are you using the latest release?

• [X] I am using the latest release

Have you tried using the dev branch latest?

• [ ] I have tried using dev branch

Docker run config used

version: '3.3'

services:

 transmission-openvpn:

    volumes:
        - /opt/docker/transmission/data_v2:/data
        - /etc/localtime:/etc/localtime:ro
        - /opt/docker/transmission/default.ovpn:/etc/openvpn/custom/default.ovpn
        - /media/extern/RAR:/media/extern/RAR

    environment:

        - PUID=1000
        - PGID=1000
        - CREATE_TUN_DEVICE=true
        - OPENVPN_PROVIDER=CUSTOM
        - OPENVPN_CONFIG=default
        - OPENVPN_USERNAME=REDACTED
        - OPENVPN_PASSWORD=REDACTED
        - TRANSMISSION_WEB_UI=transmission-web-control
        - TRANSMISSION_SCRAPE_PAUSED_TORRENTS_ENABLED=false
        - TRANSMISSION_DOWNLOAD_DIR=/media/extern/RAR
        - TRANSMISSION_WATCH_DIR_ENABLE=true
        - TRANSMISSION_START_ADDED_TORRENTS=false
        - TRANSMISSION_INCOMPLETE_DIR_ENABLED=false
        - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60 --data-ciphers-fallback 'AES-128-CBC'
        - LOCAL_NETWORK=192.168.0.0/16
        - TRANSMISSION_DHT_ENABLED=false
        - TRANSMISSION_PEX_ENABLED=false
        - TRANSMISSION_DOWNLOAD_QUEUE_SIZE=50
        - TRANSMISSION_PEER_PORT=52072
        - WEBPROXY_ENABLED=false
    dns:
        - 1.1.1.1
        - 1.0.0.1

    cap_add:

        - NET_ADMIN

    logging:

        driver: json-file

        options:

            max-size: 100m

    ports:

        - 127.0.0.1:9091:9091

    restart: always

    image: haugene/transmission-openvpn:latest

Current Behavior

It is stuck in a boot loop, after container starts

Expected Behavior

Starting and running (no boot loop)

How have you tried to solve the problem?

1. Switched Versions (latest, 3.7.1, 3.3)
2. Created a new data directory for transmission
3. added - GLOBAL_APPLY_PERMISSIONS=false
4. added - PEER_DNS=false
5. added - DISABLE_PORT_UPDATER=true
6. change the --ping exit from 60 to 300 and got tls-handshake error in response :/
7. apt update -y && apt upgrade -y && reboot
8. pinged the ip i tried to connect (No packet loss at all)

Log output

Default Log

Starting container with revision: 73ec516cc246972289c7b96ffa88c81e037fe364

Creating TUN device /dev/net/tun

Using OpenVPN provider: CUSTOM

Starting OpenVPN using config default.ovpn

Setting OpenVPN credentials...

adding route to local network 192.168.0.0/16 via 172.23.0.1 dev eth0

2022-04-25 19:00:18 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6

2022-04-25 19:00:18 OpenVPN 2.5.2 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May  4 2021

2022-04-25 19:00:18 library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.10

2022-04-25 19:00:18 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2022-04-25 19:00:18 TCP/UDP: Preserving recently used remote address: [AF_INET]REDACTED:1912

2022-04-25 19:00:18 UDP link local: (not bound)

2022-04-25 19:00:18 UDP link remote: [AF_INET]REDACTED:1912

2022-04-25 19:01:18 [UNDEF] Inactivity timeout (--ping-exit), exiting

2022-04-25 19:01:18 SIGTERM[soft,ping-exit] received, process exiting

Log with --ping exit set to 300

Starting container with revision: 73ec516cc246972289c7b96ffa88c81e037fe364

Creating TUN device /dev/net/tun

Using OpenVPN provider: CUSTOM

Starting OpenVPN using config default.ovpn

Setting OpenVPN credentials...

adding route to local network 192.168.0.0/16 via 172.23.0.1 dev eth0

2022-04-25 19:10:58 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6

2022-04-25 19:10:58 OpenVPN 2.5.2 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May  4 2021

2022-04-25 19:10:58 library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.10

2022-04-25 19:10:58 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2022-04-25 19:10:58 TCP/UDP: Preserving recently used remote address: [AF_INET]206.217.216.12:1912

2022-04-25 19:10:58 UDP link local: (not bound)

2022-04-25 19:10:58 UDP link remote: [AF_INET]206.217.216.12:1912

2022-04-25 19:11:58 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

2022-04-25 19:11:58 TLS Error: TLS handshake failed

2022-04-25 19:11:58 SIGUSR1[soft,tls-error] received, process restarting

HW/SW Environment

- OS: Ubuntu 18.04.6 LTS 64bit
- Docker: 20.10.14

Anything else?

I run the exact stack on my raspberry pi 4 64bit and there is no problem. Same provider, diffrent ip of course. And i should mention that this container used to work on my machine. Dont know what happend.

When i go inside the container and do an ip check, i get the host ip. Dont know if this is wanted ,:)

[herlon214]

Same issue here.

[edgd1er]

seems to me that your vpn provider is unstable and/or your connection. Either you have ping timeout or handshake errors. check your vpn configuration with the vpn's support. if possible check transmission errors on your router.

is there a limitation on your simultaneous account usage ?

[herlon214]

Not for me, everything was working fine. I deleted the container a couple of times and it worked, no idea why.

[Mega-Bits]

seems to me that your vpn provider is unstable and/or your connection. Either you have ping timeout or handshake errors. check your vpn configuration with the vpn's support. if possible check transmission errors on your router.

is there a limitation on your simultaneous account usage ?

If got a dedicated root on my end and even pinged the ip i want to connect. There was no problem and i didnt reached the account limit. When i tried a wrong username and password i get an error that says that the information isnt correct. So it seems that i can connect.

[vinchi007]

I had similar issue, after disabling Firewall within container ENV it started to work. Also, I'd suggest to increase log level to max to see better details. Just include in ENV line VPN_LOG_LEVEL=11

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[MattDGTL]

Am having the same/similar issue using MULLVAS. Just loops the below output.

Starting container with revision: a95f586492b2b7e8ff2cc8ac7f91bc43c0cccc40
Creating TUN device /dev/net/tun
Using OpenVPN provider: MULLVAD
Running with VPN_CONFIG_SOURCE auto
No bundled config script found for MULLVAD. Defaulting to external config
Downloading configs from https://github.com/haugene/vpn-configs-contrib/archive/main.zip into /tmp/tmp.LWu6I0hMle
Extracting configs to /tmp/tmp.iIoGNP9H9G
Found configs for MULLVAD in /tmp/tmp.iIoGNP9H9G/vpn-configs-contrib-main/openvpn/mullvad, will replace current content in /etc/openvpn/mullvad
Cleanup: deleting /tmp/tmp.LWu6I0hMle and /tmp/tmp.iIoGNP9H9G
Starting OpenVPN using config de_all.ovpn
Modifying /etc/openvpn/mullvad/de_all.ovpn for best behaviour in this container
Modification: Point auth-user-pass option to the username/password file
Modification: Change ca certificate path
Modification: Change ping options
Modification: Update/set resolv-retry to 15 seconds
Modification: Change tls-crypt keyfile path
Modification: Set output verbosity to 3
Modification: Remap SIGUSR1 signal to SIGTERM, avoid OpenVPN restart loop
Setting OpenVPN credentials...
adding route to local network 192.168.1.0/24 via 192.168.1.1 dev eth0
RTNETLINK answers: File exists
Wed Aug 31 14:42:11 2022 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022
Wed Aug 31 14:42:11 2022 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Wed Aug 31 14:42:11 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Aug 31 14:42:11 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]185.213.155.134:1194
Wed Aug 31 14:42:11 2022 Socket Buffers: R=[212992->425984] S=[212992->425984]
Wed Aug 31 14:42:11 2022 UDP link local: (not bound)
Wed Aug 31 14:42:11 2022 UDP link remote: [AF_INET]185.213.155.134:1194
Wed Aug 31 14:43:11 2022 [UNDEF] Inactivity timeout (--ping-exit), exiting
Wed Aug 31 14:43:11 2022 SIGTERM[soft,ping-exit] received, process exiting

My stack config:

 transmission-openvpn:
   container_name: transmission-openvpn
   image: haugene/transmission-openvpn:latest
   restart: always
   cap_add:
     - NET_ADMIN
   logging:
     driver: json-file
     options:
       max-size: 10m
   network_mode: DGTLNet
   sysctls:
     - net.ipv6.conf.all.disable_ipv6=0
   ports:
     - 9091:9091
   environment:
     - PUID=1000
     - PGID=1000
     - TZ=America/New_York
     - OPENVPN_PROVIDER=MULLVAD
     - OPENVPN_CONFIG=de_all
     - OPENVPN_USERNAME=1
     - OPENVPN_PASSWORD=m
     - LOCAL_NETWORK=192.168.1.0/24
     - ENABLE_UFW=false
     - CREATE_TUN_DEVICE=true
     - TRANSMISSION_CACHE_SIZE_MB=8
     - TRANSMISSION_DOWNLOAD_DIR=/data/torrents/
     - TRANSMISSION_DOWNLOAD_QUEUE_SIZE=10
     - TRANSMISSION_INCOMPLETE_DIR=/data/torrents/
     - TRANSMISSION_INCOMPLETE_DIR_ENABLED=true
     - TRANSMISSION_PEER_LIMIT_GLOBAL=500
     - TRANSMISSION_PEER_LIMIT_PER_TORRENT=100
     - TRANSMISSION_PREALLOCATION=0
     - TRANSMISSION_QUEUE_STALLED_ENABLED=true
     - TRANSMISSION_QUEUE_STALLED_MINUTES=30
     - TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true
     - TRANSMISSION_RPC_WHITELIST=127.0.0.1,192.168.1.*
     - TRANSMISSION_RPC_WHITELIST_ENABLED=true
     - TRANSMISSION_WATCH_DIR_ENABLED=false
   volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/appdata/transmission-openvpn:/config
     - /data/torrents/:/data/torrents/

[pkishino]

try :dev instead of :latest..

[jfessard]

I see the same issue/boot loop with Mullvad as Matt, that started just today, with exactly the same log trace, where the UDP link local is not bound. I tried :dev to no avail. Health shows as starting, it never is fully connected/running.

Wed Aug 31 22:35:12 2022 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Wed Aug 31 22:35:12 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Aug 31 22:35:12 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]198.54.134.50:1195
Wed Aug 31 22:35:12 2022 Socket Buffers: R=[212992->425984] S=[212992->425984]
Wed Aug 31 22:35:12 2022 UDP link local: (not bound)
Wed Aug 31 22:35:12 2022 UDP link remote: [AF_INET]198.54.134.50:1195

[MattDGTL]

try :dev instead of :latest..

Tried but same outcome.

[jfessard]

Turns out mullvad has maintenance/changes on the servers I was using. I changed the ovpn target to one without maintenance and it was fine. See https://mullvad.net/en/servers/ for details and if yours is impacted.

[MattDGTL]

awesome find! mind showing how to go about changing the OVPN Target?

[jfessard]

I just pointed it to us_lax instead of us_sjc and it worked for me in the OPENVPN_CONFIG field

[MattDGTL]

us_lax

just tried with us_lax and same issue. mind sharing your config?

[jfessard]

This config works for me (as of today) I removed my username, and changed my local network (you need to make sure LOCAL_NETWORK matches your IP)

  transmission-openvpn:
    image: haugene/transmission-openvpn
    container_name: transmission
    restart: always
    volumes:
      - "/mnt/media/torrent/:/data"
      - "/etc/localtime:/etc/localtime:ro"
    environment:
      - PUID=1000
      - PGID=1000
      - OPENVPN_PROVIDER=MULLVAD
      - OPENVPN_CONFIG=us_lax
      - OPENVPN_USERNAME=XXXXXXXXXXXXXXXXX
      - OPENVPN_PASSWORD=m
      - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60
      - WEBPROXY_ENABLED=false
      - LOCAL_NETWORK=192.168.1.0/24
      - TRANSMISSION_PEER_PORT=55000
      - TRANSMISSION_RATIO_LIMIT=1.5
      - TRANSMISSION_MAX_PEERS_GLOBAL=500
      - TRANSMISSION_PEER_LIMIT_PER_TORRENT=60
      - TRANSMISSION_RATIO_LIMIT_ENABLED=true
      - TRANSMISSION_SPEED_LIMIT_UP=1500
      - TRANSMISSION_SPEED_LIMIT_UP_ENABLED=true
      - DROP_DEFAULT_ROUTE=true
      - LOG_TO_STDOUT=true
    devices:
      - "/dev/net/tun"
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0
    cap_add:
      - NET_ADMIN
    logging:
      driver: json-file
      options:
        max-size: 10m
    ports:
      - "9091:9091"
    dns:
      - 8.8.8.8
      - 8.8.4.4

[GregHilston]

Has anyone else solved this? As simply changing the OPENVPN_CONFIG has not fixed this for me...

[Mega-Bits]

Oh god was i stupid. My problem is solved. I triplechecked if the ip it wants to connect to is still owned by my vpn provider. After that i found out that is was not the case anymore. So i switched to a new one and everything works fine now.

I thought i checked this before, but after some recent events i needed to refresh my other container and got the same error there.

Maybe this helps some of you :)

[haugene]

I'm closing this because the original issue is solved and it seems that hunting good Mullvad servers have solved most of the other commented issues.

If you're seeing this and is still having issues, open a new one. And (just like this one) include your docker setup and some logs. We need to know at least which configs and provider you are running with and what the logs look like in order to make any real debugging.