[Support] binhex - DelugeVPN


Recommended Posts

6 hours ago, PassTheSalt said:

I'm having the same issue, except restarting the container doesn't fix it, it eventually comes back chewing up core8 at 100%   
To add a bit more info i ran HTOP and it says its there are two processes, one sleeping, one running, both are  /user/bin python /user/bin/deluged -c /config -L info -l /config/deluged.log
I'm on a 13700k so i have plenty of other cores but still wondering what its doing.  I'm still running 6.11.5

I've tested this a few times for me, upon reboot or restarting the array I will have a single core almost maxed, but after stopping deluge and restarting all cores will have normal utilization

Link to comment

Using ProtonVPN and occasionally natpmpc will fail, has anyone else encountered this? Not sure if this is a ProtonVPN issue or a Deluge issue.

This can go on for some time with Deluge unable to do any downloading/uploading meanwhile.

The only "fix" I've found seems to be to switch to another server but even then it can arise again until I happen to find one where it doesn't... until it happens again later on.

 

2023-08-10 18:56:03,452 DEBG 'start-script' stderr output:
readnatpmpresponseorretry() failed : the gateway does not support nat-pmp
  errno=11 'Resource temporarily unavailable'

2023-08-10 18:56:03,452 DEBG 'start-script' stdout output:
[warn] Unable to assign an incoming port for protocol UDP, returning 1 from function...
[warn] Unable to assign incoming port

2023-08-10 18:56:03,453 DEBG 'start-script' stdout output:
[info] 11 retries left
[info] Retrying in 10 secs...

 

2023-08-11 15:38:33,354 DEBG 'start-script' stdout output:
[debug] Having issues resolving name 'www.google.com'
[debug] Retrying in 5 secs...
[debug] 7 retries left

2023-08-11 15:38:35,706 DEBG 'start-script' stderr output:
readnatpmpresponseorretry() failed : the gateway does not support nat-pmp
  errno=11 'Resource temporarily unavailable'

2023-08-11 15:38:35,706 DEBG 'start-script' stdout output:
initnatpmp() returned 0 (SUCCESS)
using gateway : ***.***.***.***
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -7 (FAILED)

 

Edited by binguser
Link to comment
On 7/27/2023 at 6:59 AM, brent3000 said:

I hope someone can provide some guidance on this issue which came up recently since upgrading to 6.12.2 my deluge client has just stopped loading for some reason.

The docker loads up and shows everything as all good but unable to load the web UI at all,

 

What info can I supply or any suggestions on how to fix? 

I can ping,

VPN connects and has IP

 

I have re-downloaded and removed the old appdata folder but but same results, 

 

Screenshot 2023-07-27 215727.png

Screenshot 2023-07-27 215417.png

Screenshot 2023-07-27 215348.png

 

I'm having this same issue, were you able to resolve this? 
If not, I'd appreciate any assistance, I've followed https://github.com/binhex/documentation/blob/master/docker/faq/help.md for the attached log file. supervisord.log

Link to comment
3 hours ago, Nowjon said:

 

I'm having this same issue, were you able to resolve this? 
If not, I'd appreciate any assistance, I've followed https://github.com/binhex/documentation/blob/master/docker/faq/help.md for the attached log file. supervisord.log

thats a successful start, what is the ip address of the machine running the web browser that you are attempting to connect with?

Link to comment
On 8/11/2023 at 12:03 AM, binguser said:

Using ProtonVPN and occasionally natpmpc will fail, has anyone else encountered this? Not sure if this is a ProtonVPN issue or a Deluge issue.

That will be a protonvpn related issue, deluge is in no way involved in natpmpc, deluge is simply configured to use the incoming port once assigned via natpmpc.

  • Thanks 1
Link to comment
5 hours ago, binhex said:

thats a successful start, what is the ip address of the machine running the web browser that you are attempting to connect with?

 

I'm attempting to connect to http://10.2.2.10:8112/

Here's my running container: 

1548406034_Screenshot2023-08-15at8_52_07AM.thumb.png.01000090313be14d996dbbdbe6f723ee.png

Here's the message I get when attempting to load the site: 
990173751_Screenshot2023-08-15at8_53_44AM.thumb.png.31d191c24874ae83449b460e76c5e882.png

Link to comment
32 minutes ago, binhex said:

i know what you are trying to connect to, my question is what is the ip of the machine running the web browser?

Ah sorry! My current IP is 10.10.10.146 and I can get to 10.2.2.10 just fine via traceroute 
 

traceroute to 10.2.2.10 (10.2.2.10), 64 hops max, 52 byte packets

 1  setup.ubnt.com (10.10.10.1)  3.058 ms *  4.542 ms

 2  10.10.10.201 (10.10.10.201)  2.289 ms  2.838 ms  3.330 ms

 3  docile (10.2.2.10)  3.737 ms  2.480 ms  2.902 ms

 

Is there anything within the container locking down access to the LAN_NETWORK or something similar? 

Update: 
I set my webtop container to the same network as the host (10.2.2.0/24) and verified I was unable to access it there either. 

 

Update 2: 
I set my webtop container to the bestitpros network, and I can access it here via 10.2.2.10:8112 in the container. 
Now I'm really wondering if there is an allowance or something for the WebUI 

Edited by Nowjon
Added update
Link to comment
1 minute ago, Nowjon said:

Ah sorry! My current IP is 10.10.10.146 and I can get to 10.2.2.10 just fine via traceroute 

routing maybe working fine but this image is locked down hard to prevent ip leakage, if you are connecting from a different network range than what is defined in LAN_NETWORK then you will be unable to connect, change LAN_NETWORK value to 10.2.2.0/24,10.10.10.0/24

Link to comment
9 minutes ago, binhex said:

routing maybe working fine but this image is locked down hard to prevent ip leakage, if you are connecting from a different network range than what is defined in LAN_NETWORK then you will be unable to connect, change LAN_NETWORK value to 10.2.2.0/24,10.10.10.0/24

I see! I updated this and it started working as expected. 

I appreciate your assistance & commitment to ensuring great containers are available for us and supporting issues related to them :)

  • Like 1
Link to comment
On 8/7/2023 at 2:20 PM, T_Matz said:

I am having an issue with Deluge. Upon a fresh reboot or array restart Deluge pings one core above 80% utilization, it jumps between core 0 and 12 but one of them will always be above 80%. If I stop the docker and restart it after, it corrects the issue. The first two pictures show the utilization prior to the docker being restarted, the third picture is after the docker restarts. Restarting the docker also brings down the CPU temps. 

 

Is there a way to correct this issue so i do not have to manually reboot the docker at every restart?

 

Rig details 

 

Intel Core i7-12700K | ASUS ROG Strix Z690-G Gaming WiFi | CORSAIR Vengeance 64GB (2 x 32GB) RAM DDR5 5200 | 5 - Seagate IronWolf Pro 12TB | SAMSUNG 980 PRO M.2 2TB (cache drive) | SAMSUNG 970 EVO PLUS m.2 250GB (VM drive) | MSI 2070 super (VM GPU) | WD Purple Pro 14 TB (VM Passthrough) | Sandisk Ultra Dual -64 GB (boot device)

Screenshot 2023-08-06 142645.png

Screenshot 2023-08-06 142658.png

Screenshot 2023-08-07 091956.png

Has anyone found a solution to stop deluge from utilizing 90% of a single core upon start up? Ive only been able to stop it from doing this by stopping the container and restarting it. After that it seems to run fine for days, but if i do not restart the container it will ping a CPU core to 90% utilization causing the cpu temps to sit above 60c.

Link to comment

I am getting constant alerts on my Deluge logs. I get constant disconnects during file transfers and using the proxy. I am using PIA for VPN.

 

09:24:24 [INFO    ][deluge.core.rpcserver         :1622] Deluge Client connection made from: 127.0.0.1:45082

09:24:25 [INFO    ][deluge.core.rpcserver         :1622] Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost.

 

 

Link to comment

Hello together,

I'm trying to get it to work with WireGuard but don't know what to put in VPN_USER & VPN_PASS.

The WireGuard configuration of my provider I have stored as follows:
/config/wireguard/wg0.conf 

I have adjusted the following setting:
Extra Parameters: --privileged=true (<- nothing else; as described in Q21: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md)
Container Path: /data/MYFOLDER
VPN_USER: ??????
VPN_PASS ??????
VPN_PROV: custom
VPN_CLIENT: wireguard
LAN_NETWORK: MY.LOCAL.NET.WORK/xx

 

At what point do I need the public and private key?

 

In the log I have the following messages (Attachment)

Would you be so kind and help me please.
Thank you!

Screenshot 2023-08-20 180744.png

Edited by AceBurn90
Link to comment

I cannot get it to work with AirVPN and its DNS config. The DNS name servers persist even if I establish a VPN connection - I cannot simply put in the VPN DNS server because they are not reachable outside of the network - hence the container throws errors that it cannot reach www.google.com and does not proceed with the normal sequence.

 

With Mullvad it worked just fine and name servers were overwritten in /etc/resolv.conf. What am I missing?

 

Just double-checked the workaround for up/down /etc/openvpn/update-resolv-conf is removed from the configuration during boot up.

 

With wireguard it works fine so I blame it on the missing update of /etc/resolv.conf - with wireguard deluge is not available from another VLAN (even when configured via LAN_NETWORK variable) though which is a deal breaker.

Edited by Evidenz
Link to comment

WebUI is accessible, but the status at the bottom shows Error and IP n/a.

 

Hey all, I'm having issues with setting up this docker application.

 

The VPN appears to be functioning from within the container (tested with curl http://checkip.amazonaws.com/), however the webui does not seem to have access to the outside world. 

 

I've spent some hours researching errors in deluge-web.log, however I was not able to figure out the root cause. In any event, I attached here three log files to give a full picture of my running container. Note that in supervisord.log, I redacted the keys that are in the wg0.conf file, for privacy.

 

Any hint or advice would be greatly appreciated 

 

Cheers

Alon

deluge-web.log supervisord.log deluged.log

Edited by alonjr
Link to comment

Hello!

First sorry for my english.

I use DelugeVPN with a Synology NAS and everything was perfect. But last month it didn't work anymore.

My VPN is NORDVPN and I saw in this discussion that the authentification method has changerd : so I changed the credentials files (credentials.conf) by overwriting with the new identifiant/password found on nordvpn website. But i also change the variables VPN_USER and VPN_PASS in the environment tab in the docker container. with these sames identifiant/password

But nothing works, when I launch on the web the Deluge Interface (http://<my_synology_ip>:8112) nothing works.

If I try to read the supervisord.log, i understand nothing.

I have tried to manage by myself by reading and reading this discussion but now i can't do nothing more.

can you help me please ?

Thank you very much

Link to comment
On 8/20/2023 at 6:11 PM, AceBurn90 said:

Hello together,

I'm trying to get it to work with WireGuard but don't know what to put in VPN_USER & VPN_PASS.

The WireGuard configuration of my provider I have stored as follows:
/config/wireguard/wg0.conf 

I have adjusted the following setting:
Extra Parameters: --privileged=true (<- nothing else; as described in Q21: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md)
Container Path: /data/MYFOLDER
VPN_USER: ??????
VPN_PASS ??????
VPN_PROV: custom
VPN_CLIENT: wireguard
LAN_NETWORK: MY.LOCAL.NET.WORK/xx

 

At what point do I need the public and private key?

 

In the log I have the following messages (Attachment)

Would you be so kind and help me please.
Thank you!

Screenshot 2023-08-20 180744.png

Any idea how to solve my problem?

Could a log file help with troubleshooting? If so, which one do you need.

Link to comment
1 hour ago, AceBurn90 said:

Any idea how to solve my problem?

Could a log file help with troubleshooting? If so, which one do you need.

Have you tried leaving them blank? If you have the configuration file with keys in it it should work without having to put a username/password.

Link to comment
On 7/26/2023 at 5:26 PM, JonathanM said:

What location are you downloading to inside deluge, and where is that location mapped on the server?

 

Post the docker run and a screenshot of the deluge path settings if you are unclear.

 

I am downloading to a downloads media folder wirh RW - SHARED

 

Here is the docker run:

 

docker run
  -d
  --name='binhex-delugevpn'
  --net='bridge'
  --privileged=true
  -e TZ="America/Phoenix"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Server"
  -e HOST_CONTAINERNAME="binhex-delugevpn"
  -e 'VPN_ENABLED'='yes'
  -e 'VPN_USER'='***************************'
  -e 'VPN_PASS'='**********************'
  -e 'VPN_PROV'='custom'
  -e 'VPN_CLIENT'='openvpn'
  -e 'VPN_OPTIONS'=''
  -e 'STRICT_PORT_FORWARD'='yes'
  -e 'ENABLE_PRIVOXY'='no'
  -e 'LAN_NETWORK'='192.168.1.0/24'
  -e 'NAME_SERVERS'='84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1'
  -e 'DELUGE_DAEMON_LOG_LEVEL'='info'
  -e 'DELUGE_WEB_LOG_LEVEL'='info'
  -e 'DELUGE_ENABLE_WEBUI_PASSWORD'='yes'
  -e 'VPN_INPUT_PORTS'=''
  -e 'VPN_OUTPUT_PORTS'=''
  -e 'DEBUG'='true'
  -e 'UMASK'='000'
  -e 'PUID'='99'
  -e 'PGID'='100'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:8112]/'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/deluge-icon.png'
  -p '8112:8112/tcp'
  -p '58846:58846/tcp'
  -p '58946:58946/tcp'
  -p '58946:58946/udp'
  -p '8118:8118/tcp'
  -v '/mnt/user/appdata/data':'/data':'rw'
  -v '/mnt/user/Media/TV/':'/Media/TV':'rw,shared'
  -v '/mnt/user/Media/Movies/':'/Media/Movies':'rw,shared'
  -v '/mnt/user/Media/Downloads/':'/Media/Downloads':'rw,shared'
  -v '/mnt/user/Media/Apps/':'/Software':'rw'
  -v '/mnt/user/appdata/binhex-delugevpn':'/config':'rw'
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-delugevpn'

fff9e513c340de31cd3314f83e6014eb0e7a0918d7f4814264e6ebfd51364e4d

The command finished successfully!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.