nexusmaniac

It's not up to date We're on 2.92, latest available was pushed to github 18 days ago - https://github.com/transmission/transmission/releases Version 2.93:

Aha I see, fair enough - I'll trust that the right solution is in the works Thanks for the update

Cheers for looking into it Any luck so far?

Shameless bump...

Just pulled the latest update, 07/07/17. I wasn't bumped to 2.1.9 I take it the updating without it actually updating 'issue' is still around? Because if I delete my appdata for this container the version sets to 2.1.9 I just can't delete my appdata because there's so many devices which I have to update my certs / creds on Any ideas LSIO?

A good question, I just like operations to & from my NAS to go as quickly as possible I likely could turn off the SSD cache for the backups share - I did this time 6 months ago - But if there's speed available then I'll take advantage of it (Not all device backups happen at night, docker is 5am Monday, main PC is late Sunday night, other systems are random throughout the week as they're not powered up 24/7, laptops and the like

So these settings would work ok with faster rsync?

Ah ok! I could've sworn it did haha Nevermind I completely agree, but at the same time I do use my /backups directory for network backups of Windows PCs, etc. So having those put new data on the SSDs while overriding whatever already exists on the array speeds things right up And I don't want to split my appdata / usb backups off into another share, I'm leaving them in a sub-dir of the /backups share Indeed it does! Which is great for if things go wrong! I considered just turning off mover logging but it's always better to have a fairly verbose syslog... Ohhhh, so ticking that option does essentially a 'delta update' ? that's a fantastic setting!! I'm using pretty much exactly those settings, I think I'll stick the faster rsync option on and see how it goes - thanks Squid!

Hi @Squid I recently uninstalled the backup / restore application as it didn't really feel useful - until I started messing around more with some of my appdata, then I figured I'd best be safe than sorry But from what I recall ~3 months ago, I had the plugin setup to backup weekly to a date folder - but the folder was then automatically zipped up, now I only see folders. Which is fine... except that my mover log (/user/backup/ uses the cache drive too then moves to the array) gets filled to 100% when it auto moves my large appdata directory Am I mistaken? Or did the backup plugin previously zip up the dated folder?

Brill! Good update

It did indeed! I haven't actually had a chance to look at the other changes you've made haha - All I saw was updating from binhex, what kinda stuff's changed? Thanks for being an incredibly responsive dev!!

Manual start did work, yeah I've just updated to the latest version (after looking through your latest commits) You've fixed it I think line 34 in "apps/nobody/transmission.sh" solved it, I can restart the container and have Transmission back up and running in seconds Thanks Activ!

SUCCESS!! rm -f /config/transmission/session/*.lock if [[ "${VPN_PROV}" == "pia" || -n "${VPN_INCOMING_PORT}" ]]; then /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" "*.*.*.*" "--bind-address-ipv4" "$0.0.0.0" "--peerport" "9091"" else /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" "*.*.*.*" "--bind-address-ipv4" "0.0.0.0"" fi I can restart the docker, run that code block in the docker exec. webUI starts, the ps -A has tmux:server, etc. All is good

Issue persists with the latest version sadly, I've tried manually starting both via "/home/nobody/transmission.sh" & 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 I've not got either one working yet, only thing that lets it work is waiting 10 mins, I'll continue to mess with manually running the script

I just ran "/home/nobody/transmission.sh" from inside the container. [root@fcd67ab57d28 /]# /home/nobody/transmission.sh [info] VPN is enabled, checking VPN tunnel local ip is valid [info] transmission not running [info] transmission listening interface IP 0.0.0.0 and VPN provider IP 10.47.10.6 different, marking for reconfigure [info] Attempting to start transmission... [info] Removing any transmission session lock files left over from the previous run... Script started, file is /home/nobody/typescript Script done, file is /home/nobody/typescript [info] transmission started [debug] VPN incoming port is 35595 [debug] VPN IP is 10.47.10.6 [debug] transmission incoming port is 35595 [debug] transmissionn IP is 10.47.10.6 I ran it 3 times, every time it is adamant that "transmission not running"

What's the command to start it? If I restart the container I could manually run the command via docker exec That would rule out the script being the issue (which I guess it's not if it works after 10 mins) but would point towards some kind of weird and wonderful other reason behind this

First 10 seconds: root@Raptor:~# docker exec -it Transmission ps -A PID TTY TIME CMD 1 ? 00:00:00 tini 7 ? 00:00:00 bash 15 ? 00:00:00 supervisord 18 ? 00:00:00 checkproc.sh 19 ? 00:00:00 start.sh 20 ? 00:00:00 transmission.sh 111 ? 00:00:00 openvpn 112 ? 00:00:00 sleep 279 ? 00:00:00 transmission.sh 280 ? 00:00:00 curl 281 ? 00:00:00 head 282 ? 00:00:00 grep 308 ? 00:00:00 ps First minute: root@Raptor:~# docker exec -it Transmission ps -A PID TTY TIME CMD 1 ? 00:00:00 tini 7 ? 00:00:00 bash 15 ? 00:00:00 supervisord 18 ? 00:00:00 checkproc.sh 19 ? 00:00:00 start.sh 20 ? 00:00:00 transmission.sh 111 ? 00:00:00 openvpn 330 ? 00:00:00 sleep 3819 ? 00:00:00 sleep 3981 ? 00:00:00 sleep 3982 ? 00:00:00 ps After 10 mins: PID TTY TIME CMD 1 ? 00:00:00 tini 7 ? 00:00:00 bash 15 ? 00:00:00 supervisord 18 ? 00:00:02 checkproc.sh 19 ? 00:00:00 start.sh 20 ? 00:00:00 transmission.sh 111 ? 00:00:00 openvpn 23186 ? 00:00:00 tmux: server 23187 pts/1 00:00:00 transmission-da 23191 ? 00:00:00 sleep 23209 ? 00:00:00 sleep 23211 ? 00:00:00 sleep 23212 pts/1 00:00:00 ps Here's the debug log again in case it's useful 2017-01-29 12:44:59,446 DEBG 'start-script' stdout output: [info] Starting OpenVPN... 2017-01-29 12:44:59,451 DEBG 'start-script' stdout output: [info] OpenVPN started 2017-01-29 12:45:00,919 DEBG 'transmission-script' stdout output: [info] transmission not running [info] transmission listening interface IP 0.0.0.0 and VPN provider IP 10.4.10.6 different, marking for reconfigure 2017-01-29 12:45:01,711 DEBG 'transmission-script' stdout output: [info] Attempting to start transmission... [info] Removing any transmission session lock files left over from the previous run... 2017-01-29 12:45:01,713 DEBG 'transmission-script' stdout output: Script started, file is /home/nobody/typescript 2017-01-29 12:45:01,729 DEBG 'transmission-script' stdout output: Script done, file is /home/nobody/typescript 2017-01-29 12:45:01,729 DEBG 'transmission-script' stdout output: [info] transmission started [debug] VPN incoming port is 38887 [debug] VPN IP is 10.4.10.6 [debug] transmission incoming port is 38887 [debug] transmissionn IP is 10.4.10.6 2017-01-29 12:55:01,852 DEBG 'transmission-script' stdout output: [info] transmission not running 2017-01-29 12:55:02,473 DEBG 'transmission-script' stdout output: [info] Attempting to start transmission... [info] Removing any transmission session lock files left over from the previous run... 2017-01-29 12:55:02,475 DEBG 'transmission-script' stdout output: Script started, file is /home/nobody/typescript 2017-01-29 12:55:02,492 DEBG 'transmission-script' stdout output: Script done, file is /home/nobody/typescript 2017-01-29 12:55:02,492 DEBG 'transmission-script' stdout output: [info] transmission started [debug] VPN incoming port is 38887 [debug] VPN IP is 10.4.10.6 [debug] transmission incoming port is 38887 2017-01-29 12:55:02,492 DEBG 'transmission-script' stdout output: [debug] transmissionn IP is 10.4.10.6

Here's the debut output: 2017-01-29 12:29:46,826 DEBG 'start-script' stdout output: [info] Starting OpenVPN... 2017-01-29 12:29:46,837 DEBG 'start-script' stdout output: [info] OpenVPN started 2017-01-29 12:29:48,322 DEBG 'transmission-script' stdout output: [info] transmission not running [info] transmission listening interface IP 0.0.0.0 and VPN provider IP 10.32.10.6 different, marking for reconfigure 2017-01-29 12:29:49,143 DEBG 'transmission-script' stdout output: [info] Attempting to start transmission... [info] Removing any transmission session lock files left over from the previous run... 2017-01-29 12:29:49,146 DEBG 'transmission-script' stdout output: Script started, file is /home/nobody/typescript 2017-01-29 12:29:49,166 DEBG 'transmission-script' stdout output: Script done, file is /home/nobody/typescript 2017-01-29 12:29:49,166 DEBG 'transmission-script' stdout output: [info] transmission started [debug] VPN incoming port is 35004 [debug] VPN IP is 10.32.10.6 [debug] transmission incoming port is 35004 [debug] transmissionn IP is 10.32.10.6 2017-01-29 12:39:49,303 DEBG 'transmission-script' stdout output: [info] transmission not running 2017-01-29 12:39:49,949 DEBG 'transmission-script' stdout output: [info] Attempting to start transmission... [info] Removing any transmission session lock files left over from the previous run... 2017-01-29 12:39:49,952 DEBG 'transmission-script' stdout output: Script started, file is /home/nobody/typescript 2017-01-29 12:39:49,972 DEBG 'transmission-script' stdout output: Script done, file is /home/nobody/typescript 2017-01-29 12:39:49,972 DEBG 'transmission-script' stdout output: [info] transmission started [debug] VPN incoming port is 35004 [debug] VPN IP is 10.32.10.6 2017-01-29 12:39:49,972 DEBG 'transmission-script' stdout output: [debug] transmission incoming port is 35004 [debug] transmissionn IP is 10.32.10.6 I'll run the ps -A now

I've enabled debug mode for your docker, I'll leave it running until the 10 minute mark and post the end of the log Could it be a timing issue for a script somewhere? 10 mins seems too specific haha

So here's a weird one... Exactly 10 mins of the docker running with no access to the webUI *poof* I can access it! If I restart the container, it's exactly another 10 mins until I can reach it again... Strange wouldn't you say? 2017-01-29 12:13:53,228 DEBG 'start-script' stdout output: -P INPUT DROP -P FORWARD ACCEPT -P OUTPUT DROP -A INPUT -i tun0 -j ACCEPT -A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --sport 1198 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 9091 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --sport 9091 -j ACCEPT -A INPUT -p udp -m udp --sport 53 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT -A INPUT -i lo -j ACCEPT -A OUTPUT -o tun0 -j ACCEPT -A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT -A OUTPUT -o eth0 -p udp -m udp --dport 1198 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 9091 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --sport 9091 -j ACCEPT -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT 2017-01-29 12:13:53,228 DEBG 'start-script' stdout output: -------------------- 2017-01-29 12:13:53,228 DEBG 'start-script' stdout output: [info] Starting OpenVPN... 2017-01-29 12:13:53,235 DEBG 'start-script' stdout output: [info] OpenVPN started 2017-01-29 12:13:54,858 DEBG 'transmission-script' stdout output: [info] transmission not running [info] transmission listening interface IP 0.0.0.0 and VPN provider IP 10.32.10.6 different, marking for reconfigure 2017-01-29 12:13:55,714 DEBG 'transmission-script' stdout output: [info] Attempting to start transmission... [info] Removing any transmission session lock files left over from the previous run... 2017-01-29 12:13:55,716 DEBG 'transmission-script' stdout output: Script started, file is /home/nobody/typescript 2017-01-29 12:13:55,734 DEBG 'transmission-script' stdout output: Script done, file is /home/nobody/typescript 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 2017-01-29 12:23:56,580 DEBG 'transmission-script' stdout output: [info] Attempting to start transmission... [info] Removing any transmission session lock files left over from the previous run... 2017-01-29 12:23:56,583 DEBG 'transmission-script' stdout output: Script started, file is /home/nobody/typescript 2017-01-29 12:23:56,608 DEBG 'transmission-script' stdout output: Script done, file is /home/nobody/typescript 2017-01-29 12:23:56,609 DEBG 'transmission-script' stdout output: [info] transmission started That's the docker log from unRAID, I could reach the webUI at 12:23:56 ----- docker exec -it Transmission ifconfig ps -A root@Raptor:~# docker exec -it Transmission ifconfig ps -A -A: Unknown host ifconfig: `--help' gives usage information. Didn't work for me

Ok, I'll change the name servers I'm pretty comfortable with it haha Here's the output of the command: root@Raptor:~# docker exec -it Transmission ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.2 netmask 255.255.0.0 broadcast 0.0.0.0 ether 02:42:ac:11:00:02 txqueuelen 0 (Ethernet) RX packets 122 bytes 19717 (19.2 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 104 bytes 12202 (11.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 10.32.10.6 netmask 255.255.255.255 destination 10.32.10.5 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC) RX packets 13 bytes 5890 (5.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 30 bytes 3699 (3.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="Transmission" --net="bridge" --privileged="true" -e TZ="Europe/London" -e HOST_OS="unRAID" -e "VPN_ENABLED"="yes" -e "VPN_USER"="BLANK" -e "VPN_PASS"="BLANK" -e "VPN_REMOTE"="nl.privateinternetaccess.com" -e "VPN_PORT"="1194" -e "VPN_PROTOCOL"="udp" -e "VPN_PROV"="pia" -e "ENABLE_PRIVOXY"="no" -e "LAN_NETWORK"="192.168.0.0/24" -e "WHITELIST"="*.*.*.*" -e "DEBUG"="false" -e "PUID"="99" -e "PGID"="100" -e "VPN_DEVICE_TYPE"="tun" -e "STRONG_CERTS"="no" -e "PHP_TZ"="Europe/London" -e "NAME_SERVERS"="192.168.0.254" -p 9091:9091/tcp -p 8118:8118/tcp -v "/mnt/user/Media/Transmission/":"/data":rw -v "/etc/localtime":"/etc/localtime":ro -v "/mnt/cache/appdata/transmission/":"/config":rw activ/arch-transmissionvpn

Neither 1.0 or latest work on unRAID 6.3 rc9. The version you uploaded yday did work for me (I just had to add the extra config options) The logs seem normal: ErrorWarningSystemArrayLogin usermod: no changes [info] Env var PUID defined as 99 [info] Env var PGID defined as 100 [info] Permissions already set for /config [info] Starting Supervisor... 2017-01-29 11:41:40,184 CRIT Set uid to user 0 2017-01-29 11:41:40,184 INFO Included extra file "/etc/supervisor/conf.d/transmission.conf" during parsing 2017-01-29 11:41:40,187 INFO supervisord started with pid 15 2017-01-29 11:41:41,189 INFO spawned: 'checkproc-script' with pid 18 2017-01-29 11:41:41,191 INFO spawned: 'start-script' with pid 19 2017-01-29 11:41:41,192 INFO spawned: 'transmission-script' with pid 20 2017-01-29 11:41:41,194 INFO spawned: 'privoxy-script' with pid 21 2017-01-29 11:41:41,199 DEBG 'start-script' stdout output: [info] VPN is enabled, beginning configuration of VPN 2017-01-29 11:41:41,199 INFO success: checkproc-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2017-01-29 11:41:41,199 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2017-01-29 11:41:41,199 INFO success: transmission-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2017-01-29 11:41:41,199 INFO success: privoxy-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2017-01-29 11:41:41,201 DEBG 'transmission-script' stdout output: [info] VPN is enabled, checking VPN tunnel local ip is valid 2017-01-29 11:41:41,202 DEBG 'privoxy-script' stdout output: [info] Privoxy set to disabled 2017-01-29 11:41:41,202 DEBG fd 24 closed, stopped monitoring <POutputDispatcher at 47749247123608 for <Subprocess at 47749247226944 with name privoxy-script in state RUNNING> (stderr)> 2017-01-29 11:41:41,202 DEBG fd 20 closed, stopped monitoring <POutputDispatcher at 47749247125336 for <Subprocess at 47749247226944 with name privoxy-script in state RUNNING> (stdout)> 2017-01-29 11:41:41,202 INFO exited: privoxy-script (exit status 0; expected) 2017-01-29 11:41:41,202 DEBG received SIGCLD indicating a child quit 2017-01-29 11:41:41,207 DEBG 'start-script' stdout output: [info] VPN default certs defined, copying to /config/openvpn/... 2017-01-29 11:41:41,209 DEBG 'start-script' stdout output: [info] VPN config file (ovpn extension) is located at /config/openvpn/openvpn.ovpn 2017-01-29 11:41:41,211 DEBG 'start-script' stdout output: [warn] VPN provider remote port incorrect, overriding to 1198 2017-01-29 11:41:41,249 DEBG 'start-script' stdout output: [info] Default route for container is 172.17.0.1 2017-01-29 11:41:41,251 DEBG 'start-script' stdout output: [info] Adding 192.168.0.0/24 as route via docker eth0 2017-01-29 11:41:41,252 DEBG 'start-script' stdout output: [info] ip route defined as follows... -------------------- 2017-01-29 11:41:41,253 DEBG 'start-script' stdout output: default via 172.17.0.1 dev eth0 172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2 192.168.0.0/24 via 172.17.0.1 dev eth0 2017-01-29 11:41:41,253 DEBG 'start-script' stdout output: -------------------- 2017-01-29 11:41:41,256 DEBG 'start-script' stdout output: [info] iptable_mangle support detected, adding fwmark for tables 2017-01-29 11:41:41,284 DEBG 'start-script' stdout output: [info] iptables defined as follows... -------------------- 2017-01-29 11:41:41,285 DEBG 'start-script' stdout output: -P INPUT DROP -P FORWARD ACCEPT -P OUTPUT DROP -A INPUT -i tun0 -j ACCEPT -A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --sport 1198 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 9091 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --sport 9091 -j ACCEPT -A INPUT -p udp -m udp --sport 53 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT -A INPUT -i lo -j ACCEPT -A OUTPUT -o tun0 -j ACCEPT -A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT -A OUTPUT -o eth0 -p udp -m udp --dport 1198 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 9091 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --sport 9091 -j ACCEPT -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT 2017-01-29 11:41:41,285 DEBG 'start-script' stdout output: -------------------- 2017-01-29 11:41:41,285 DEBG 'start-script' stdout output: [info] Starting OpenVPN... 2017-01-29 11:41:41,299 DEBG 'start-script' stdout output: [info] OpenVPN started But I cannot connect the the webUI

Yeah, I understand what you want, it's just a bad idea unless you know exactly what you are doing. The VPN service does not firewall the endpoint connection, so theoretically connecting to them allows other vpn users on the same network node free access to your system totally bypassing your router, since unraid doesn't have a built in firewall. I personally would never risk it. Binhex's dockers go to great lengths to ensure isolation and security, to make sure VPN traffic doesn't leak out of the docker, or vice versa. Network security is hard. Too many ways for things to go wrong, and not many ways to do it right. Aha, ok cool - Well that's fair enough! Sadly my Linux networking knowledge is very lacking... I'll have to sacrifice using my tiny docker containers and grab VPN specific versions Thanks!

Normally this specific plugin is used to provide a private tunnel for you to connect back to your server from outside securely. Connecting to a VPN service is better served by Binhex's VPN enabled torrent and nzb dockers. I'm talking about the client, to push all traffic through a PIA VPN As opposed to hosting a VPN server to connect back into my home network I have used various VPN dockers but I very much prefer this implementation, meaning I can use dockers which take up less room, all use the same alpine base image (big user of LinuxServerIO dockers ) I just hoped there would be a way of either excluding a docker from the tun5 network... OR a way in the docker config to use a completely separate network / network interface