Transmission not automatically starting in container #2231

filliravaz · 2022-03-24T21:58:30Z

Is there a pinned issue for this?

I have read the pinned issues and could not find my issue

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

I have searched the existing issues
I have searched the existing discussions

Is there any comment in the documentation for this?

I have read the documentation, especially the FAQ and Troubleshooting parts

Is this related to a provider?

I have checked the provider repo for issues
My issue is NOT related to a provider

Are you using the latest release?

I am using the latest release

Have you tried using the dev branch latest?

I have tried using dev branch

Docker run config used

docker run --cap-add=NET_ADMIN -d -v /home/pi/transmissionvpn:/data
-v /home/pi/transmissionvpnconfig:/etc/openvpn/custom/ -e OPENVPN_PROVIDER=custom
-e OPENVPN_CONFIG=vpnconfig -e OPENVPN_USERNAME=user
-e OPENVPN_PASSWORD=password -e LOCAL_NETWORK=192.168.1.0/24
--log-driver json-file --log-opt max-size=10m -p 9091:9091 haugene/transmission-openvpn

Current Behavior

Transmission WebUI is not reachable, but by attaching to the container and running transmission-daemon then it works as expected

Expected Behavior

transmission daemon should automatically start on container start

How have you tried to solve the problem?

verified that start.sh matches the one on the repository
Added a post start openvpn script, but my bash abilities aren't that great

Log output

Starting container with revision: 8cc1870
Creating TUN device /dev/net/tun
Using OpenVPN provider: CUSTOM
Running with VPN_CONFIG_SOURCE auto
No bundled config script found for CUSTOM. Defaulting to external config
Downloading configs from https://github.com/haugene/vpn-configs-contrib/archive/main.zip into /tmp/tmp.kJGnvYsO8q
Extracting configs to /tmp/tmp.fpEyVImGjS
ERROR: Could not find any configs for provider CUSTOM in downloaded configs
Cleanup: deleting /tmp/tmp.kJGnvYsO8q and /tmp/tmp.fpEyVImGjS
Starting OpenVPN using config vpnconfig.ovpn
Modifying /etc/openvpn/custom/vpnconfig.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 172.17.0.1 dev eth0
Thu Mar 24 21:37:33 2022 Multiple --up scripts defined. The previously configured script is overridden.
Thu Mar 24 21:37:33 2022 OpenVPN 2.4.7 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021
Thu Mar 24 21:37:33 2022 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
Thu Mar 24 21:37:33 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Thu Mar 24 21:37:33 2022 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Mar 24 21:37:33 2022 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Mar 24 21:37:33 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]138.199.7.240:80
Thu Mar 24 21:37:33 2022 Socket Buffers: R=[180224->180224] S=[180224->180224]
Thu Mar 24 21:37:33 2022 UDP link local: (not bound)
Thu Mar 24 21:37:33 2022 UDP link remote: [AF_INET]138.199.7.240:80
Thu Mar 24 21:37:33 2022 TLS: Initial packet from [AF_INET]138.199.7.240:80, sid=55eef9f0 6193b3b7
Thu Mar 24 21:37:33 2022 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Mar 24 21:37:33 2022 VERIFY OK: depth=2, C=CH, O=x AG, CN=x Root CA
Thu Mar 24 21:37:33 2022 VERIFY OK: depth=1, C=CH, O=x AG, CN=x Intermediate CA 1
Thu Mar 24 21:37:33 2022 VERIFY KU OK
Thu Mar 24 21:37:33 2022 Validating certificate extended key usage
Thu Mar 24 21:37:33 2022 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Server Authentication
Thu Mar 24 21:37:33 2022 ++ Certificate has EKU (oid) 1.3.6.1.5.5.7.3.2, expects TLS Web Server Authentication
Thu Mar 24 21:37:33 2022 ++ Certificate has EKU (str) 1.3.6.1.5.5.8.2.2, expects TLS Web Server Authentication
Thu Mar 24 21:37:33 2022 ++ Certificate has EKU (oid) 1.3.6.1.5.5.8.2.2, expects TLS Web Server Authentication
Thu Mar 24 21:37:33 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Mar 24 21:37:33 2022 VERIFY EKU OK
Thu Mar 24 21:37:33 2022 VERIFY OK: depth=0, CN=x
Thu Mar 24 21:37:33 2022 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1634'
Thu Mar 24 21:37:33 2022 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Thu Mar 24 21:37:33 2022 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA
Thu Mar 24 21:37:33 2022 [x] Peer Connection Initiated with [AF_INET]138.199.7.240:80
Thu Mar 24 21:37:34 2022 SENT CONTROL [x]: 'PUSH_REQUEST' (status=1)
Thu Mar 24 21:37:34 2022 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.19.0.1,sndbuf 524288,rcvbuf 524288,redirect-gateway def1,explicit-exit-notify,comp-lzo no,route-gateway 10.19.0.1,topology subnet,ping 10,ping-restart 60,socket-flags TCP_NODELAY,ifconfig 10.19.0.47 255.255.0.0,peer-id 196707,cipher AES-256-GCM'
Thu Mar 24 21:37:34 2022 OPTIONS IMPORT: timers and/or timeouts modified
Thu Mar 24 21:37:34 2022 OPTIONS IMPORT: explicit notify parm(s) modified
Thu Mar 24 21:37:34 2022 OPTIONS IMPORT: compression parms modified
Thu Mar 24 21:37:34 2022 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Thu Mar 24 21:37:34 2022 Socket Buffers: R=[180224->360448] S=[180224->360448]
Thu Mar 24 21:37:34 2022 OPTIONS IMPORT: --socket-flags option modified
Thu Mar 24 21:37:34 2022 NOTE: setsockopt TCP_NODELAY=1 failed
Thu Mar 24 21:37:34 2022 OPTIONS IMPORT: --ifconfig/up options modified
Thu Mar 24 21:37:34 2022 OPTIONS IMPORT: route options modified
Thu Mar 24 21:37:34 2022 OPTIONS IMPORT: route-related options modified
Thu Mar 24 21:37:34 2022 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Mar 24 21:37:34 2022 OPTIONS IMPORT: peer-id set
Thu Mar 24 21:37:34 2022 OPTIONS IMPORT: adjusting link_mtu to 1656
Thu Mar 24 21:37:34 2022 OPTIONS IMPORT: data channel crypto options modified
Thu Mar 24 21:37:34 2022 Data Channel: using negotiated cipher 'AES-256-GCM'
Thu Mar 24 21:37:34 2022 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Mar 24 21:37:34 2022 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Mar 24 21:37:34 2022 ROUTE_GATEWAY 172.17.0.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:11:00:06
Thu Mar 24 21:37:34 2022 TUN/TAP device tun0 opened
Thu Mar 24 21:37:34 2022 TUN/TAP TX queue length set to 100
Thu Mar 24 21:37:34 2022 /sbin/ip link set dev tun0 up mtu 1500
Thu Mar 24 21:37:34 2022 /sbin/ip addr add dev tun0 10.19.0.47/16 broadcast 10.19.255.255
Thu Mar 24 21:37:34 2022 /etc/openvpn/update-resolv-conf tun0 1500 1584 10.19.0.47 255.255.0.0 init
Thu Mar 24 21:37:34 2022 /sbin/ip route add 138.199.7.240/32 via 172.17.0.1
Thu Mar 24 21:37:34 2022 /sbin/ip route add 0.0.0.0/1 via 10.19.0.1
Thu Mar 24 21:37:34 2022 /sbin/ip route add 128.0.0.0/1 via 10.19.0.1
Thu Mar 24 21:37:34 2022 Initialization Sequence Completed
Thu Mar 24 21:44:09 2022 AEAD Decrypt error: bad packet ID (may be a replay): [ #50 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Thu Mar 24 21:45:37 2022 AEAD Decrypt error: bad packet ID (may be a replay): [ #62 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Thu Mar 24 21:45:37 2022 AEAD Decrypt error: bad packet ID (may be a replay): [ #62 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Thu Mar 24 21:45:37 2022 AEAD Decrypt error: bad packet ID (may be a replay): [ #62 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Thu Mar 24 21:45:37 2022 AEAD Decrypt error: bad packet ID (may be a replay): [ #62 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Thu Mar 24 21:45:37 2022 AEAD Decrypt error: bad packet ID (may be a replay): [ #62 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Thu Mar 24 21:45:37 2022 AEAD Decrypt error: bad packet ID (may be a replay): [ #62 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Thu Mar 24 21:45:37 2022 AEAD Decrypt error: bad packet ID (may be a replay): [ #62 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

HW/SW Environment

- OS: Raspbian Linux 10 (Buster)
- Docker: 20.10.12 

Raspberry Pi 3B+ with OMV on it. External USB drive is mounted to /mnt

Anything else?

No response

The text was updated successfully, but these errors were encountered:

kgadberry · 2022-04-07T20:25:28Z

I'm having the same issue on Ubuntu 20.04/Docker 20.10.14 on Raspberry Pi 4b. Log stops at Initialization Sequence Completed.
Manually running transmission-daemon starts transmission, but accessing it gives me a 403 page.

pkishino · 2022-04-09T12:52:40Z

this log entry is the problem:

Thu Mar 24 21:37:33 2022 Multiple --up scripts defined. The previously configured script is overridden.

something is conflicting with the startup and overriding the openvpn --up script..
as I don't see this behaviour on my test-platforms can you check if you have any other openvpn processes or configs going?

pkishino · 2022-04-09T12:55:01Z

this is what the lines should be :

Using OpenVPN provider: CUSTOM

Setting OpenVPN credentials...

adding route to local network 10.1.125.0/24 via 172.20.10.1 dev eth0

Sat Apr  9 21:49:57 2022 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021

Sat Apr  9 21:49:57 2022 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10

and the bottom part:

Sat Apr  9 21:49:59 2022 /sbin/ip route add 0.0.0.0/1 via 193.234.55.1

Sat Apr  9 21:49:59 2022 /sbin/ip route add 128.0.0.0/1 via xxx

Up script executed with device=tun0 ifconfig_local=xxx

Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : xxx

Using Flood for Transmission UI, overriding TRANSMISSION_WEB_HOME
...
.
.
DROPPING DEFAULT ROUTE

STARTING TRANSMISSION

Transmission startup script complete.

Sat Apr  9 21:49:59 2022 Initialization Sequence Completed

filliravaz · 2022-04-09T12:59:16Z

can you check if you have any other openvpn processes or configs going?

I have a OpenVPN server running on the host, not in a container. Could that be the issue?

Apart from that, no there is nothing else in the container. As far as i can tell, the startup script is completely missing a call to the transmission start.sh

pkishino · 2022-04-09T13:04:02Z

this is the tunnelUp script

docker-transmission-openvpn/openvpn/tunnelUp.sh

Line 54 in 8cc1870

/etc/transmission/start.sh "$@"

calls transmission once openVPN has established a tunnel
based on

docker-transmission-openvpn/openvpn/start.sh

Line 172 in 8cc1870

    
           TRANSMISSION_CONTROL_OPTS="--script-security 2 --up-delay --up /etc/openvpn/tunnelUp.sh --route-pre-down /etc/openvpn/tunnelDown.sh"

filliravaz · 2022-04-09T13:09:24Z

this is the tunnelUp script

docker-transmission-openvpn/openvpn/tunnelUp.sh

Line 54 in 8cc1870

/etc/transmission/start.sh "$@"

calls transmission once openVPN has established a tunnel

based on

docker-transmission-openvpn/openvpn/start.sh

Line 172 in 8cc1870

TRANSMISSION_CONTROL_OPTS="--script-security 2 --up-delay --up /etc/openvpn/tunnelUp.sh --route-pre-down /etc/openvpn/tunnelDown.sh"

I cannot check on stuff now, but when I checked looking for start.sh or transmission inside the OpenVPN script resulted in 0 lines found.

Maybe it was a bug with an old image for ARM?
I'll check again when I'm back home.

kgadberry · 2022-04-09T18:38:25Z

Using the :dev image fixed the issue of Transmission not starting (VPN_CONFIG_SOURCE has to be set, which is different from :latest). ~~I'm still greeted with a 403 page, but I imagine this could be a configuration issue.~~

Edit: Not entirely sure what was wrong but it was definitely a configuration issue.

pkishino · 2022-04-09T20:52:09Z

this is the tunnelUp script

docker-transmission-openvpn/openvpn/tunnelUp.sh

Line 54 in 8cc1870

/etc/transmission/start.sh "$@"

calls transmission once openVPN has established a tunnel
based on

docker-transmission-openvpn/openvpn/start.sh

Line 172 in 8cc1870

TRANSMISSION_CONTROL_OPTS="--script-security 2 --up-delay --up /etc/openvpn/tunnelUp.sh --route-pre-down /etc/openvpn/tunnelDown.sh"

I cannot check on stuff now, but when I checked looking for start.sh or transmission inside the OpenVPN script resulted in 0 lines found.

Maybe it was a bug with an old image for ARM? I'll check again when I'm back home.

Yeah, you should definitely do a docker pull as that must be an ancient version..

pkishino · 2022-04-09T20:53:03Z

Using the :dev image fixed the issue of Transmission not starting (VPN_CONFIG_SOURCE has to be set, which is different from :latest). ~~I'm still greeted with a 403 page, but I imagine this could be a configuration issue.~~

Edit: Not entirely sure what was wrong but it was definitely a configuration issue.

403 most likely the transmission settings for whitelist not correctly set

pkishino · 2022-04-09T20:54:11Z

VPN_CONFIG_SOURCE does not need to be set, it has a default value..

kgadberry · 2022-04-09T21:12:44Z

Using the :dev image fixed the issue of Transmission not starting (VPN_CONFIG_SOURCE has to be set, which is different from :latest). ~~I'm still greeted with a 403 page, but I imagine this could be a configuration issue.~~
Edit: Not entirely sure what was wrong but it was definitely a configuration issue.

403 most likely the transmission settings for whitelist not correctly set

The 403 was fixed when I removed and recreated the container using the command line instead of through Portainer like I normally do. Not sure what happened, but it works now and I'm not complaining.

VPN_CONFIG_SOURCE does not need to be set, it has a default value..

This is the log output I get if I don't set VPN_CONFIG_SOURCE=default using a custom configuration set up to bind as /etc/openvpn/custom/default.ovpn as suggested in the documentation:

Starting container with revision: 8952476945eaf542dd2fdf74f8820458a891565f
Creating TUN device /dev/net/tun
Using OpenVPN provider: CUSTOM
Running with VPN_CONFIG_SOURCE auto
No bundled config script found for CUSTOM. Defaulting to external config
Downloading configs from https://github.com/haugene/vpn-configs-contrib/archive/main.zip into /tmp/tmp.sUCHYoiOh1
Extracting configs to /tmp/tmp.SFerNoWAUk
ERROR: Could not find any configs for provider CUSTOM in downloaded configs
Cleanup: deleting /tmp/tmp.sUCHYoiOh1 and /tmp/tmp.SFerNoWAUk

I had no problem using :latest, other than Transmission not starting.

pkishino · 2022-04-09T21:15:56Z

Yeah, that error is expected and can be ignored if using CUSTOM.. I think I fixed that in :dev to remove the error but still works fine.
Anyway, closing for now

kgadberry · 2022-04-09T21:24:47Z

Yeah, that error is expected and can be ignored if using CUSTOM.. I think I fixed that in :dev to remove the error but still works fine. Anyway, closing for now

To clarify, that log output is all I get and the container doesn't start unless VPN_CONFIG_SOURCE is set.

pkishino · 2022-04-10T03:37:15Z

in that case something in your config isn't correct..
if you set OPENVPN_PROVIDER to Custom (or don't set it) it should not even reach that point

docker-transmission-openvpn/openvpn/start.sh

Line 50 in 8952476

VPN_PROVIDER="${OPENVPN_PROVIDER:-custom}"

pkishino · 2022-04-10T03:46:40Z

I just added an additional check and pushed it..try to pull in a few minutes.
it should not even try to fetch config if CUSTOM is set as provider..
did you mount the ovpn properly?

kgadberry · 2022-04-11T05:45:58Z

I just added an additional check and pushed it..try to pull in a few minutes. it should not even try to fetch config if CUSTOM is set as provider.. did you mount the ovpn properly?

Pulling the latest :dev image seems to have removed the need to set VPN_CONFIG_SOURCE and the log does not show that it tried to download the configs now.
The .ovpn file is mounted with -v /srv/transmission/default.ovpn:/etc/openvpn/custom/default.ovpn just like the documentation suggests, and it otherwise works fine.

filliravaz · 2022-04-12T15:18:18Z

Latest image is still not working, however the dev image fixed it.
Thanks for the help!

pkishino closed this as completed Apr 9, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Transmission not automatically starting in container #2231

Transmission not automatically starting in container #2231

filliravaz commented Mar 24, 2022 •

edited

Loading

kgadberry commented Apr 7, 2022

pkishino commented Apr 9, 2022

pkishino commented Apr 9, 2022

filliravaz commented Apr 9, 2022 •

edited

Loading

pkishino commented Apr 9, 2022 •

edited

Loading

filliravaz commented Apr 9, 2022 •

edited

Loading

kgadberry commented Apr 9, 2022 •

edited

Loading

pkishino commented Apr 9, 2022

pkishino commented Apr 9, 2022

pkishino commented Apr 9, 2022

kgadberry commented Apr 9, 2022

pkishino commented Apr 9, 2022

kgadberry commented Apr 9, 2022

pkishino commented Apr 10, 2022 •

edited

Loading

pkishino commented Apr 10, 2022

kgadberry commented Apr 11, 2022

filliravaz commented Apr 12, 2022

Transmission not automatically starting in container #2231

Transmission not automatically starting in container #2231

Comments

filliravaz commented Mar 24, 2022 • edited Loading

Is there a pinned issue for this?

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

Is there any comment in the documentation for this?

Is this related to a provider?

Are you using the latest release?

Have you tried using the dev branch latest?

Docker run config used

Current Behavior

Expected Behavior

How have you tried to solve the problem?

Log output

HW/SW Environment

Anything else?

kgadberry commented Apr 7, 2022

pkishino commented Apr 9, 2022

pkishino commented Apr 9, 2022

filliravaz commented Apr 9, 2022 • edited Loading

pkishino commented Apr 9, 2022 • edited Loading

filliravaz commented Apr 9, 2022 • edited Loading

kgadberry commented Apr 9, 2022 • edited Loading

pkishino commented Apr 9, 2022

pkishino commented Apr 9, 2022

pkishino commented Apr 9, 2022

kgadberry commented Apr 9, 2022

pkishino commented Apr 9, 2022

kgadberry commented Apr 9, 2022

pkishino commented Apr 10, 2022 • edited Loading

pkishino commented Apr 10, 2022

kgadberry commented Apr 11, 2022

filliravaz commented Apr 12, 2022

filliravaz commented Mar 24, 2022 •

edited

Loading

filliravaz commented Apr 9, 2022 •

edited

Loading

pkishino commented Apr 9, 2022 •

edited

Loading

filliravaz commented Apr 9, 2022 •

edited

Loading

kgadberry commented Apr 9, 2022 •

edited

Loading

pkishino commented Apr 10, 2022 •

edited

Loading