2 minutes ago, BBLV said:

Here is the screenshot - first line is without the docker running, second line is WITH the docker running.

 

yeah completely expected, if you grep for port 8112 with the container stopped then it wont match anything (and thus nothing is returned), if you start the container then it will return something as the port is listening and thus a grep (match) is found for port 8112.

12 minutes ago, BBLV said:

Maybe something funky is going on

According to your screenshot, you've got the same port mapped three times in your container settings (port 58846).  That doesn't look right.

1 minute ago, Cessquill said:

According to your screenshot, you've got the same port mapped three times in your container settings (port 58846).  That doesn't look right.

no he doesnt, he has 58846 mapped once and 58946 mapped twice (tcp and udp) completely normal.

so far i see no problems, time to dig into it, do the following procedure in the link below:-

 

https://forums.unraid.net/topic/44108-support-binhex-general/?do=findComment&comment=435831

 

2 minutes ago, binhex said:

no he doesnt, he has 58846 mapped once and 58946 mapped twice (tcp and udp) completely normal.

Apologies - I stared at that for ages and still missed it.  Long day.  Didn't help that I checked against mine on a mobile phone and don't have 58946 mapped.

 

As you were...

2 minutes ago, Cessquill said:

Apologies - I stared at that for ages and still missed it.  Long day.  Didn't help that I checked against mine on a mobile phone and don't have 58946 mapped.

 

As you were...

lol no apology required 🙂

18 hours ago, l3gion said:

Hi everyone,

 

Maybe a stupid question, but can someone explain me why the eth0 and tun0 values diverge? Should't they kind be the same, since tun0 goes through eth0?

 

See attached image. This was from the binhex-delugevpn console.

 

Thanks.

Any idea anyone? @binhex maybe?

Thanks.

1 hour ago, binhex said:

so far i see no problems, time to dig into it, do the following procedure in the link below:-

 

https://forums.unraid.net/topic/44108-support-binhex-general/?do=findComment&comment=435831

 

I'll perform this when I get home this evening. One thing I was thinking about is that it worked just fine (I just wasn't connectable) until I added the new Windscribe Static IP OpenVPN config file. Nothing else changed. Would that have anything to do with the internal app port being buggered?

1 hour ago, BBLV said:

One thing I was thinking about is that it worked just fine (I just wasn't connectable) until I added the new Windscribe Static IP OpenVPN config file. Nothing else changed. Would that have anything to do with the internal app port being buggered?

i would suspect the ovpn file you have downloaded is either corrupt or simply badly formed, this in turn will mean the vpn tunnel cannot be established, and this is turn means the app cant start (designed not to start until tunnel is running) and thus cannot be accessed via the web ui.

1 hour ago, l3gion said:

Any idea anyone? @binhex maybe?

Thanks.

completely normal:-

tun0 = vpn traffic only

eth0 = vpn traffic (tunnel runs over eth0) AND all local traffic (web interface, api calls from sonarr etc).

18 hours ago, seventhaxis said:

Just got this docker installed and working, but I'm having issue adding torrents. When adding via File, the upload fails. When attempting to add via URL, it also fails to download the .torrent content and add to the system. The only way I've found so far is to stop the docker, add the .torrent file to a folder which auto-imports into Deluge, then start the docker again and manage the newly added torrents.

 

Any help with this is greatly appreciated.

@BBLV Thanks for the suggestion. I'll remember that one but I'm trying to stay away from all things Google.

 

@binhex Any ideas what I should try or what could be wrong? Or is it working as expected?

Hello, Been trying to get this to work for a while.  I bash in to the container and the VPN is working but Deluge is not accessible.  I need a new set of eyes on it.  There is so much information I cannot parse it all.  Thank you.

supervisord.log

3 hours ago, binhex said:

completely normal:-

tun0 = vpn traffic only

eth0 = vpn traffic (tunnel runs over eth0) AND all local traffic (web interface, api calls from sonarr etc).

Thanks for getting back to me. I imagined it could be all the local traffic on deluge. Now I'm just surprised at the amount of data transfered locally from the web interface, sonarr, radarr and jackett. 10gb download and 6gb upload over a couple of days 😅

9 hours ago, binhex said:

so far i see no problems, time to dig into it, do the following procedure in the link below:-

 

https://forums.unraid.net/topic/44108-support-binhex-general/?do=findComment&comment=435831

 

Here's my supervisord log file. FYI I switched back to the non-static ip OpenVPN config that previously worked - no longer working and kicking back that same "address already in use" error in the log. Something must be jammed up somewhere indicating that the container is already running and therefore the 8112 port is blocked/in use. Looking forward to your feedback.

supervisord.log

10 hours ago, BBLV said:

Here's my supervisord log file. FYI I switched back to the non-static ip OpenVPN config that previously worked - no longer working and kicking back that same "address already in use" error in the log. Something must be jammed up somewhere indicating that the container is already running and therefore the 8112 port is blocked/in use. Looking forward to your feedback.

supervisord.log

hmm ok so it looks like its twisted (python module) that is reporting the port clash, lets have a look at your deluge config file then, can you attach /config/core.conf here.

1 hour ago, binhex said:

hmm ok so it looks like its twisted (python module) that is reporting the port clash, lets have a look at your deluge config file then, can you attach /config/core.conf here.

Here's my core.cong and a screenshot of my delugevpn folder (directory and duplicate files normal?).

core.conf

41 minutes ago, BBLV said:

Here's my core.cong and a screenshot of my delugevpn folder (directory and duplicate files normal?).

core.conf

yep so this is your issue, in the file core.conf line 59 to 62 you have somehow got the incoming port set to the same port number as the web interface, as in port 8112, so when deluge-ui tries to start it starts the web ui on port 8112 (separate process to deluge), then deluged reads the core.conf and attempts to set the incoming port to 8112, which it cant cos its already in use by the web interface and then blows up.

 

here is the misconfigured section:-

 

  "listen_ports": [
    8112, 
    8112
  ], 

 

so the fix is stop the container, and set it to the following, do NOT use windows notepad, use notepad++ or atom:-

 

  "listen_ports": [
    1234, 
    1234
  ], 

save the file and then start the container.

47 minutes ago, binhex said:

yep so this is your issue, in the file core.conf line 59 to 62 you have somehow got the incoming port set to the same port number as the web interface, as in port 8112, so when deluge-ui tries to start it starts the web ui on port 8112 (separate process to deluge), then deluged reads the core.conf and attempts to set the incoming port to 8112, which it cant cos its already in use by the web interface and then blows up.

 

here is the misconfigured section:-

 

  "listen_ports": [
    8112, 
    8112
  ], 

 

so the fix is stop the container, and set it to the following, do NOT use windows notepad, use notepad++ or atom:-

 

  "listen_ports": [
    1234, 
    1234
  ], 

save the file and then start the container.

That did it. Thanks!

20 hours ago, Rudder2 said:

Hello, Been trying to get this to work for a while.  I bash in to the container and the VPN is working but Deluge is not accessible.  I need a new set of eyes on it.  There is so much information I cannot parse it all.  Thank you.

supervisord.log

Any ideas anyone?  More information needed?  Please help.

Here is a new supervisord.log.  Please help.  I ping things in the container and the TX and RX of the tunnel increase so the tunnel is working.  Just something isn't working.  No idea what.

supervisord.log

The log you posted contains your vpn password. You should change it. There are also warnings in the log regarding special characters in the password. Might want to stick with letters and numbers on the new one. Not sure if this is the cause of your problem but it’s a place to start.

1 minute ago, wgstarks said:

The log you posted contains your vpn password. You should change it. There are also warnings in the log regarding special characters in the password. Might want to stick with letters and numbers on the new one. Not sure if this is the cause of your problem but it’s a place to start.

I will change it.  Sounds like is was good I accidentally missed all the entries.  Thank you for the tip.  I use random passwords for all services.

 

5 minutes ago, wgstarks said:

The log you posted contains your vpn password. You should change it. There are also warnings in the log regarding special characters in the password. Might want to stick with letters and numbers on the new one. Not sure if this is the cause of your problem but it’s a place to start.

My VPN provider requires special characters....

1 minute ago, Rudder2 said:

My VPN provider requires special characters....

Maybe underscore, probably safe.

5 minutes ago, wgstarks said:

Maybe underscore, probably safe.

I used !'s in it and it still gives the warning.  When I Bash in to the Container the tunnel responds to pings....This has me mindboggled...

 

[root@335280eb9ecb /]# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=36.7 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=35.7 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=44.8 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=36.0 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=37.2 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=36.8 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=57 time=37.4 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=57 time=36.6 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=57 time=36.2 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=57 time=36.8 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=57 time=39.6 ms
64 bytes from 1.1.1.1: icmp_seq=12 ttl=57 time=37.2 ms
^C
--- 1.1.1.1 ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 22ms
rtt min/avg/max/mdev = 35.743/37.599/44.827/2.380 ms
[root@335280eb9ecb /]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.16  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:ac:11:00:10  txqueuelen 0  (Ethernet)
        RX packets 171  bytes 25136 (24.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 43  bytes 5317 (5.1 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 1000  (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

tun5: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 172.21.94.34  netmask 255.255.254.0  destination 172.21.94.34
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 20  bytes 1680 (1.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1680 (1.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0