Gog

Can you generate new logs with debug set to true? Sent from my SGH-I337M using Tapatalk

VPN looks fine there, do you have transmission logs? Does transmission work if you set VPN_ENABLED to false?

Binhex is the one who can do a code update, not you. Did you try the docker with "tun"?

I think the problem is with your tun5. When starting openvpn, it does indeed VPN_DEVICE_TYPE+0, take a look: OpenVPN command line '/usr/bin/openvpn --cd /config/openvpn --config /config/openvpn/IPredator-NetworkManager-Password.ovpn --daemon --dev tun50 --remote pw.openvpn.ipredator.se 1194 --proto udp --reneg-sec 0 --mute-replay-warnings --auth-nocache --keepalive 10 60 --auth-user-pass credentials.conf' The --dev tun50 is probably what breaks it. Try using just "tun" as device type and see how that goes. I admit I don't know what is the difference between tun0 and tun5. A quick google seems to say that the number is sometimes assigned randomly so this will probably work but YMMV If you absolutely need to use tun5, you'll need a code update.

Wrong support thread, this is deluge, not transmission. That being sent, the VPN part should be the same so... It looks like there is something wrong with your VPN config, openVPN is not initialising I don't know why tou would define 'tun5' for device type. If memory serves, the script hardcodes it to device_type+0 so I would expect tun50 but I can't check from work. Can you stop the docker, set debug to true, start the docker, wait a few minutes and post supervisor.log?

Have you tried stopping the deluge docker then run the mover manually? Sent from my SGH-I337M using Tapatalk

What is /data mapped to in your delugeVPN docker? I'm thinking that if you map it to /mnt/cache/Downloads, the file could be locked *on the cache drive* by deluge. If it's moved, you'd stop seeding. If you map /data to /mnt/user/Downloads in the docker, it should be movable but then sometimes containers don't like to be mapped on user shares so that might not work for completely different reasons

I can't say I've seen this running on FreeNAS but openVPN is not initializing correctly. It looks like you are missing environment variables: VPN_ENABLED : 'yes' DEBUG: true VPN_PROV VPN_REMOTE VPN_PORT VPN_PROTOCOL (custom/pia/airvpn) LAN_NETWORK VPN_USER VPN_PASS VPN_DEVICE_TYPE I think user and password are needed because the script generates credentials.conf every time. It resets permissions on my copy anyway... Be careful if you post debug logs, your use and password will be in there if you don't remove them manually

There is a bonehead in each of us. The role of the computer is to make it shine!

It looks like your VPN credentials are not valid: AUTH: Received control message: AUTH_FAILED Not related but it looks like the ifconfig you posted are straight from the unraid server. To know it the vpn network interface is up, you need to run it from inside the docker, like so: docker exec -it binhex-delugevpn bash ifconfig

Are you kidding? I try to help here and I'm a bona fide bonehead! You configured the right port? device type? LAN_NETWORK address? Stop the docker, set debug to true, delete the supervisor.log file, start the docker, wait 5 minutes, edit supervisor.log to remove your username and password and post it here.

The sneaky bastards changed the port! I redownloaded the .ovpn package last night and the one I was using before used 1194 and the new one I downloaded uses 1196. My old one probably kept working until I disconnected and the server ignored me when I tried to reconnect on 1194. It was not all because of what's sitting in my chair!

I work in support, we call those "code 18" as in 18 inches in front of the keyboard Sent from my SGH-I337M using Tapatalk

&*(?$&/$ I swear I checked that. Why the hell would that change??? Anyway, thanks for the catch, I'll try that tonight.

Well, shit, it's my turn. Had to reboot today and it won't come up. I don't see any error in the logs, just this coming over and over: Thu Apr 6 23:23:12 2017 Server poll timeout, restarting Thu Apr 6 23:23:12 2017 SIGUSR1[soft,server_poll] received, process restarting Thu Apr 6 23:23:12 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Thu Apr 6 23:23:12 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]91.231.84.93:1194 Thu Apr 6 23:23:12 2017 Socket Buffers: R=[212992->212992] S=[212992->212992] Thu Apr 6 23:23:12 2017 UDP link local: (not bound) Thu Apr 6 23:23:12 2017 UDP link remote: [AF_INET]91.231.84.93:1194 I can ping the VPN server with IP and FQDN. I don't see more when I try the command manually. I redownloaded the .ovpn files from my provider. There were a few differences but it didn't help. I tried other VPN servers from my provider with the same result. I'm stumped. supervisord.1.log

FYI, It is fairly easy to setup with nginx-letsencrypt as a reverse proxy Sent from my SGH-I337M using Tapatalk

How about a log entry to complain about the encrypted file then? Sent from my SGH-I337M using Tapatalk

It should and it does. I'm afraid I can't find the issue, you'll have to wait for the pros... Sent from my SGH-I337M using Tapatalk

You don't have a tun0 interface, the VPN is not up. Which is weird since the iptables rules are loaded which means you should not be able to reach 8.8.8.8 without going through the tun0 interface. Are you sure about the VPN_PORT is 1282? Is that what's defined in "/config/openvpn/ca1-kodibear.ovpn"?

You might want to edit your logs to remove the sensitive information... Your logs look a lot like mine but they stop short. Deluge starts after "OpenVPN started" I get this: You have this: 2017-03-31 15:06:39,422 DEBG 'start-script' stdout output: [info] OpenVPN started I have this: 2017-03-26 07:20:58,371 DEBG 'start-script' stdout output: [info] OpenVPN started 2017-03-26 07:21:00,274 DEBG 'privoxy-script' stdout output: [info] Configuring Privoxy... 2017-03-26 07:21:00,278 DEBG 'deluge-script' stdout output: [info] Deluge not running You have privoxy at false but it should just skip that. If you open a putty connection to the server and do this: docker exec -it binhex-delugevpn bash ifconfig Do you have a "tun0" section? Can you ping 8.8.8.8?

I use the same setup, same version of delugesiphon and the connection info shows up for mine. I don't see how your delugeVPN could be responsible for that...

I haven't had issues with this personnaly but while setting up I read that the path to your downloaded files needs to be the same in both container. Same path, same container path I haven't looked at the API but I'm guessing that when Deluge talks to sonarr to say the file is ready, the filepath is sent and if it doesn't match sonarr is left swinging in the wind. As for the remove, I just use the label option -> remove at ratio but I'm not sure that really works yet

Hey there Sorry I wasn't clear, I did not mean to suggest that deluge would stop working, just that it's using space in your docker image file for nothing. Since the "/Downloads" path was not mapped to a drive on your server, everything that was downloaded there by deluge stayed inside the docker container. I'm suggesting that you redeploy the docker to wipe that data. You could also just delete the files as follow: docker exec -it binhex-delugevpn bash rm -r /Downloads/*

I'd refresh the docker too, just in case you have a bunch of semi downloaded files in your /Downloads directory inside your docker image

I get the same warnings, repeatedly, in my functionning docker. Can you post your supervisord.log after a reboot?