1 hour ago, bugster said:

You are missing information. I suggest posting your log file. Make sure to remove any info with username/password/wan IP before posting it

 

I'm using binhex-delugevpn and this is what mine looks like.

 

In my initial searching, I noticed that my Network info did not match others. 🤔

 

Do people need to see the Log file found on the Docker page for Deluge, or the complete unRAID log?

On 4/11/2020 at 6:40 PM, bugster said:

 

Same issue here. @justvano which version of the docker are you running. I'm on binhex/arch-delugevpn:1.3.15_18_ge050905b2-1-01

Well I just restarted the container and believe it or not is now working. smh

Edited April 13, 20206 yr by bugster

6 minutes ago, jeff.lebowski said:

In my initial searching, I noticed that my Network info did not match others. 🤔

 

Do people need to see the Log file found on the Docker page for Deluge, or the complete unRAID log?

Deluge.

My Deluge log:

 

https://pastebin.com/Yd6LwJS4

3 minutes ago, jeff.lebowski said:

My Deluge log:

 

https://pastebin.com/Yd6LwJS4

Seems to be an issue with your config. Look at step 3 here:

 

1 hour ago, bugster said:

Seems to be an issue with your config. Look at step 3 here:

 

Followed the steps using MC (I paused the Application first), and restarted. Things seem okay now. I'll report back after a few torrents make a new announcement to the tracker.

If I enter Proxy info into Deluge like here:

 

I can't download any trackers or anything it seems and downloads just sit there indefinitely.  Is there something else I need to do?

8 hours ago, bugster said:

Seems to be an issue with your config. Look at step 3 here:

 

Everything seems fine so far. Thanks for your help.

(Solved) Noticed this morning that both my Delugevpn and Sabnzbdvpn containers were not working. I could not connect to the web ui of either container. The logs show the following error "Error: error sending query: Could not send or receive, because of network error" in both containers. I assumed a problem with PIA and in the Deluge container tried all of the European endpoints with port forwarding, but all failed. The Sabnzbd container uses a different endpoint without port forwarding. I can connect to the web ui of both containers if vpn_enabled is set to false. I have made sure my account and password with PIA are working. I can successfully connect to the various endpoints I have tried in the Deluge container on another computer. I enabled debug and am attaching the supervisord log file. It shows "network error" and "Failed to resolve endpoint" on all the endpoints I have tried. The same errors show up in the Sabnzbd log files.

 

Thanks in advance for any assistance.

supervisord.log

 

Edit: Found a problem with a firewall rule and now everything is working.

Edited April 14, 20206 yr by Arkadin55
problem solved

10 hours ago, alexdodd said:

If I enter Proxy info into Deluge like here:

 

I can't download any trackers or anything it seems and downloads just sit there indefinitely.  Is there something else I need to do?

why are you trying to use a proxy when you already are using a vpn tunnel?, this does not make you any more secure and will cause issues. 

Just an update, PIA added some additional servers.  ca-toronto still doesn't support port forwarding but ca-montreal and ca-vancouver do now so if you're experiencing speed issues using EU based servers, you can try moving back to a Canadian based server. 

Hi I have an issue when deploying this container.  When deployed using the bridge interface all works and the web ui is accessible.  If i use a custom bridge interface and specify a manual ip the container runs and functions as expected (privoxy works, downloads added via other sources work when in the console curl ifconfig.io returns the address of the VPN server i am connecting to).  However when using a custom bridge interface to allow the container to use its own address the web ui cannot be accessed either from within unraid or directly via http://[containerIP]:8112.  Should this container support the use of custom IP address on a container for accessing the web ui?

On 4/14/2020 at 9:37 AM, binhex said:

why are you trying to use a proxy when you already are using a vpn tunnel?, this does not make you any more secure and will cause issues. 

Fair point!  And its definiately causing issues

I shall leave that empty; i just saw a proxy option and thought why not, I now know to.... not 👍

Thanks for all your work you do mate

On 4/11/2020 at 5:40 PM, bugster said:

 

Same issue here. @justvano which version of the docker are you running. I'm on binhex/arch-delugevpn:1.3.15_18_ge050905b2-1-01

Hey Bugster,

 

Thanks for the reply. It looks like I am on version 2.0.4.dev23. Hopefully that is what you are looking for. Still having the same trouble. I haven't tried much else because I am unsure of what to try and do not want to further break things. 

On 4/13/2020 at 9:11 PM, Arkadin55 said:

(Solved) Noticed this morning that both my Delugevpn and Sabnzbdvpn containers were not working. I could not connect to the web ui of either container. The logs show the following error "Error: error sending query: Could not send or receive, because of network error" in both containers. I assumed a problem with PIA and in the Deluge container tried all of the European endpoints with port forwarding, but all failed. The Sabnzbd container uses a different endpoint without port forwarding. I can connect to the web ui of both containers if vpn_enabled is set to false. I have made sure my account and password with PIA are working. I can successfully connect to the various endpoints I have tried in the Deluge container on another computer. I enabled debug and am attaching the supervisord log file. It shows "network error" and "Failed to resolve endpoint" on all the endpoints I have tried. The same errors show up in the Sabnzbd log files.

 

Thanks in advance for any assistance.

supervisord.log 12.14 kB · 1 download

 

Edit: Found a problem with a firewall rule and now everything is working.

Can you be more specific about what firewall rule you changed and why?

2 hours ago, justvano said:

Can you be more specific about what firewall rule you changed and why?

I have a rule on some of my subnets to force DNS queries to only go through my Pfsense. I had this rule disabled for my unRaid server, but mistakenly enabled it when I was making some changes the other day. So totally nothing to do with any problems with the Delugevpn container and just user error.

5 hours ago, TheGrownUpGeek said:

Should this container support the use of custom IP address on a container for accessing the web ui?

No, this container does not support this at this time. You should be able to use desktop/thin client to get access though. I have mine working on windows at least (with the old v1), on custom br0 with it's own IP.. AFAIK there is no finished windows/mac client ready for v2 yet, but there are instructions on how to build it on your own, I just haven't had the time to do it yet. 

1 hour ago, strike said:

No, this container does not support this at this time. You should be able to use desktop/thin client to get access though. I have mine working on windows at least (with the old v1), on custom br0 with it's own IP.. AFAIK there is no finished windows/mac client ready for v2 yet, but there are instructions on how to build it on your own, I just haven't had the time to do it yet. 

Ok cool thanks i will do it that way, thanks for the reply

 

On 4/10/2020 at 4:25 PM, justvano said:

Hi all,

 

I've been having the same problem once I upgraded to 6.8.3. I have been using Switzerland for the last year or more with no trouble. Now the last week I have no internet access from Sonarr, Radarr or Lidarr. Also Plex appears to be struggling to upload content for posters, etc even though I don not have plex running through a proxy. 

 

Error's i'm getting:

Sonarr - Failed to test proxy: Error: ServerProtocolViolation: 'https://radarr.aeonlucid.com/v1/ping'

Radarr - Failed to test proxy: http://services.sonarr.tv/v1/ping

Lidarr - Failed to test proxy: https://services.lidarr.audio/v1/ping

 

I don't think I've changed anything before or after the update. I am running pfsense on it's own hardware but also haven't changed any settings. I have tried changing the port forward location from Switzerland to Berlin, France and Sweden with no change. 

 

If you require any logs please let me know. 

Still having the same problem guys despite more effort to trouble shoot. The one thing I thought of was that I recently turned Snort on in Pfsense so I tried turning that off but no change. Any ideas?

Edited April 16, 20206 yr by justvano

My seeding has fallen off a cliff with the last few updates (I only update periodically, so I can't pinpoint an exact update that effected me). Any recent changes that would cause me to experience this change?

All of a sudden I can't access my container anymore.  I get the error below and don't have web access to the docker anymore.  Any ideas??

 

2020-04-16 13:51:42,209 DEBG 'start-script' stdout output:

[info] Starting OpenVPN...

 

2020-04-16 13:51:42,224 DEBG 'start-script' stdout output:

Thu Apr 16 13:51:42 2020 WARNING: file 'credentials.conf' is group or others accessible

 

Thu Apr 16 13:51:42 2020 OpenVPN 2.4.8 [git:makepkg/3976acda9bf10b5e+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jan 3 2020

Thu Apr 16 13:51:42 2020 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10

 

2020-04-16 13:51:42,224 DEBG 'start-script' stdout output:

[info] OpenVPN started

Thu Apr 16 13:51:42 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

 

2020-04-16 13:51:42,226 DEBG 'start-script' stdout output:

Thu Apr 16 13:51:42 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]172.98.67.58:1198

Thu Apr 16 13:51:42 2020 UDP link local: (not bound)

Thu Apr 16 13:51:42 2020 UDP link remote: [AF_INET]172.98.67.58:1198

 

2020-04-16 13:51:42,497 DEBG 'start-script' stdout output:

Thu Apr 16 13:51:42 2020 [26bdbf7600612ac4bc63113e87dcc560] Peer Connection Initiated with [AF_INET]172.98.67.58:1198

 

2020-04-16 13:51:43,802 DEBG 'start-script' stdout output:

Thu Apr 16 13:51:43 2020 TUN/TAP device tun0 opened

Thu Apr 16 13:51:43 2020 /usr/bin/ip link set dev tun0 up mtu 1500

 

2020-04-16 13:51:43,803 DEBG 'start-script' stdout output:

Thu Apr 16 13:51:43 2020 /usr/bin/ip addr add dev tun0 local 10.14.10.6 peer 10.14.10.5

 

2020-04-16 13:51:43,804 DEBG 'start-script' stdout output:

Thu Apr 16 13:51:43 2020 /root/openvpnup.sh tun0 1500 1558 10.14.10.6 10.14.10.5 init

 

2020-04-16 13:51:43,808 DEBG 'start-script' stdout output:

Thu Apr 16 13:51:43 2020 Initialization Sequence Completed

 

2020-04-16 13:51:43,916 DEBG 'start-script' stdout output:

[info] Port forwarding is enabled

[info] Checking endpoint 'ca-toronto.privateinternetaccess.com' is port forward enabled...

 

2020-04-16 13:51:43,918 DEBG 'start-script' stdout output:

[info] Attempting to curl https://www.privateinternetaccess.com/vpninfo/servers?version=82...

 

 

2020-04-16 13:51:44,416 DEBG 'start-script' stdout output:

[info] Curl successful for https://www.privateinternetaccess.com/vpninfo/servers?version=82, response code 200

 

 

2020-04-16 13:51:44,472 DEBG 'start-script' stdout output:

[warn] PIA endpoint 'ca-toronto.privateinternetaccess.com' is not in the list of endpoints that support port forwarding, DL/UL speeds maybe slow

[info] Please consider switching to one of the endpoints shown below

 

2020-04-16 13:51:44,472 DEBG 'start-script' stdout output:

[info] List of PIA endpoints that support port forwarding:-

[info] ca-montreal.privateinternetaccess.com

[info] ca-vancouver.privateinternetaccess.com

[info] de-berlin.privateinternetaccess.com

[info] de-frankfurt.privateinternetaccess.com

[info] sweden.privateinternetaccess.com

[info] swiss.privateinternetaccess.com

[info] france.privateinternetaccess.com

[info] czech.privateinternetaccess.com

[info] spain.privateinternetaccess.com

[info] ro.privateinternetaccess.com

[info] israel.privateinternetaccess.com

[info] Attempting to get dynamically assigned port...

 

2020-04-16 13:51:44,476 DEBG 'start-script' stdout output:

[info] Attempting to curl http://209.222.18.222:2000/?client_id=takenoutbyme............

 

2020-04-16 13:51:44,542 DEBG 'start-script' stdout output:

[warn] Response code 000 from curl != 2xx

[warn] Exit code 7 from curl != 0

[info] 12 retries left

[info] Retrying in 10 secs...

 

2020-04-16 13:51:54,611 DEBG 'start-script' stdout output:

[warn] Response code 000 from curl != 2xx

[warn] Exit code 7 from curl != 0

[info] 11 retries left

[info] Retrying in 10 secs...

15 minutes ago, GreenEyedMonster said:

  Any ideas

Yes. As the error states, Toronto no longer supports port forwarding. You should use one of the servers listed in the error message.

24 minutes ago, BBLV said:

My seeding has fallen off a cliff with the last few updates (I only update periodically, so I can't pinpoint an exact update that effected me). Any recent changes that would cause me to experience this change?

My log is showing this on repeat, might this be a clue to the issue?

 

2020-04-16 12:14:43,218 DEBG 'watchdog-script' stdout output:
[debug] Waiting for iptables chain policies to be in place...

2020-04-16 12:14:43,229 DEBG 'watchdog-script' stdout output:
[debug] iptables chain policies are in place

2020-04-16 12:14:43,312 DEBG 'watchdog-script' stdout output:
[debug] VPN IP is 10.118.218.7
[debug] Deluge IP is 10.118.218.7

It's been such a difficult 18 hours, I can't even recall why I had to delete my Docker image and reinstall Deluge.

 

1) I didn't sleep well last night. Maybe 45 minutes total.

2) I am just dumb enough to not understand "Volume Mappings" and how everything works together. I could NOT make AutoAdd save the watch folder. Only after I had downloaded a couple new torrents for testing did I see my Download destination was wrong (one folder extra deep), which clicked something in my brain. I fixed the watch folder and AutoAdd now works (by the way, WTF is a .egg?) and I'm slowly re-adding the torrents.

3) The path in the Docker settings DOES NOT match what the path Deluge. That's today's tip. I believe typing out mnt/user/Torrentz in the Docker settings creates a path that Deluge sees as /data. I could not figure this out. For hours.

 

About five hours ago, I would have given my kingdom for a simple setup tutorial that clearly lays out why paths are setup the way they are. 🤪

 

I've been seeding nearly nonstop since about 2004. Thousands and thousands of sessions, with gobs and gobs of data. I *almost* considered just stopping. It was that bad today.

 

Thanks for reading. 🙂

Edited April 17, 20206 yr by jeff.lebowski

27 minutes ago, jeff.lebowski said:

About five hours ago, I would have given my kingdom for a simple setup tutorial that clearly lays out why paths are setup the way they are. 🤪

This may be a little dated but the principles haven’t changed.

https://youtu.be/ISJczs06pD8