activ

So a manual start works? I've just pushed a new version again with some extra log information that will at least tell us which of the two start lines is used.

The new version is up, could one of you see if it fixes the problem?

I think I found something. Can't test because I don't have PIA, but a new version will be online in a few minutes.

@nexusmaniac: Could you try starting it manually? Maybe we'll get an error message or something. b.t.w.: 10 minutes is the sleep time of the script, that's why it's 10 minutes.

On the latest.

Yup, and pointed to the Toronto node: ca-toronto.privateinternetaccess.com Could you do the same checks Nexusmaniac has done? I'm thinking this has something to do with the PIA specific part of the code. (Maybe your is also working after waiting 10 minutes)

The part of the script that starts it is this echo "[info] Attempting to start transmission..." echo "[info] Removing any transmission session lock files left over from the previous run..." rm -f /config/transmission/session/*.lock if [[ "${VPN_PROV}" == "pia" || -n "${VPN_INCOMING_PORT}" ]]; then # run tmux attached to transmission, specifying listening interface and port /usr/bin/script /home/nobody/typescript --command "/usr/bin/tmux new-session -d -s rt -n transmission /usr/bin/transmission-daemon "--foreground" "--config-dir" "/config" "--allowed" "${WHITELIST}" "--bind-address-ipv4" "${transmission_ip}" "--peerport" "$transmission_port"" else # run tmux attached to transmission, specifying listening interface /usr/bin/script /home/nobody/typescript --command "/usr/bin/tmux new-session -d -s rt -n transmission /usr/bin/transmission-daemon "--foreground" "--config-dir" "/config" "--allowed" "${WHITELIST}" "--bind-address-ipv4" "${transmission_ip}"" fi echo "[info] transmission started" You will of course have to replace the variables.

Are you on PIA?

That's what I thought, the initial start is failing and after 10 minutes the script notices transmission is not running and starts it. Now for the real question, why is it not starting the first time. As far as I know the command for the restart is the same as the start.

Sorry, the command should be: docker exec -it Transmission ps -A The weird thing in the log is that at 12:13 transmission is started, but then at 12:23 it's determined to be not running and restarted. Maybe the initial start is failing for some reason. could you try the ps command in the first 10 minutes? 2017-01-29 12:13:55,735 DEBG 'transmission-script' stdout output: [info] transmission started 2017-01-29 12:23:55,876 DEBG 'transmission-script' stdout output: [info] transmission not running

okay, so the network tunnel is working. Maybe do a docker exec -it Transmission ifconfig ps -A to see if transmission is running too

Hmm, nothing weird in there. I'm pretty sure the issue is with the vpn and Transmission doesn't even get started. Maybe put the dns as NAME_SERVERS=8.8.8.8,8.8.4.4 while we figure this out, thats what I have. I don't know how good you are with cli, but can you ssh into the unraid server and run the below command? (it assumes the container is called arc-transmissionvpn) The output should include a network interface called tun0 if the vpn is working. docker exec -it arch-transmissionvpn ifconfig p.s. did the trouble for you also start with updating Unraid?

Could you post your settings? (user and password excluded of course)

That makes it a bit tricky, I don't have an Unraid machine to test on anymore. Since it's broken anyway you could try removing it and doing a clean install from scratch.

I think the real reason you cannot access the web interface is that transmission is not started. I'm not even sure the vpn in actually connecting. Which version are you on? Is it the one form yesterday or from before? Did you just update unraid and it stopped working or did you also update the container? At the moment there are two versions available: Version 1.0 - The version that has been up for the last few months Latest - The version I updated today with new scripting from Binhex for disconnect handling and such.

Okay guys and girls, I hope I got the kinks out enough to now share the new version. The new version is based on the latest scripting by Binhex and it has auto reconnect etc. It does however also need more info passed into the container, so make sure you add the right variables. More info here: https://github.com/activ/arch-transmissionvpn Example: docker run -d \ --cap-add=NET_ADMIN \ -p 9091:9091 \ -p 8118:8118 \ --name=<container name> \ -v <path for data files>:/data \ -v <path for config files>:/config \ -v /etc/localtime:/etc/localtime:ro \ -e VPN_ENABLED=<yes|no> \ -e VPN_USER=<vpn username> \ -e VPN_PASS=<vpn password> \ -e VPN_REMOTE=<vpn remote gateway> \ -e VPN_PORT=<vpn remote port> \ -e VPN_PROTOCOL=<vpn remote protocol> \ -e VPN_DEVICE_TYPE=<tun|tap> \ -e VPN_PROV=<pia|airvpn|custom> \ -e STRONG_CERTS=<yes|no> \ -e ENABLE_PRIVOXY=<yes|no> \ -e LAN_NETWORK=<lan ipv4 network>/<cidr notation> \ -e NAME_SERVERS=<name server ip(s)> \ -e WHITELIST= <example 192.168.*.*> \ -e DEBUG=<true|false> \ -e PHP_TZ=<php timezone> \ -e PUID=<uid for user> \ -e PGID=<gid for user> \ activ/arch-transmissionvpn

The missing mangle support is not your issue, it should still work without. Do you have a more complete log?

There was a bad version up for a while yesterday, just grab the current version and it should work again. Sorry

@Binhex: I've been digging into your updates docker to make a new version of my own. Am I right is thinking that you check processes, ports and IP addresses, but not the actual connection or tunnel interface?

Thanks for the tip, I'll have a look at implementing your changes when I have some time.

I have the same issue, it doesn't seem to reconnect. The docker uses OpenVPN cli to connect, and I guess that doesn't automatically reconnect. I've been meaning to research options to trigger a reconnect automatically, but haven't found the time. If you have a proposed change in the docker to fix if let me know and I'll paste it in.

afaik the rpc password is the same used to log into the web interface. I whitelisted both 192.168.x.x and 172.17.x.x

Don't use it myself, but should be easy enough to configure. Just be aware that the whitelist in transmission needs to include the interal IP range used by docker inside the containers aswel.

You can specify the uid and guid to use inside the container, default is 99 and 100 I believe. You will need to change that or assign rights to that user/group. It's a bit of a tricky affair, but once you get the idea you will never have the problem again.

I configured the incomplete folder from the remote gui, doing it directly in the config file will probably work best for you.