[Support] binhex - DelugeVPN


Recommended Posts

So I am having a very odd issue that I am hoping fill fix itself now as I feel as though I have tried everything... I have now re installed unRAID and the issue persists. :'( Whenever I add a torrent to Deluge it begins to download, speeds up as usual then slows down until it stalls only seconds later... checking the downloads folder show no data has been downloaded. I have played with every setting imaginable so I'm sure I'm just being an idiot.

 

I am using binhex-delugevpn with Private Internet Access. This issue started yesterday. I have been playing around with downloaders like Couch Potato but after removing every trace of those I could find and even re-installing the OS and re-configuring unRAID I am at a loss...

 

Please help! 

 

Here are some logs from Deluge:

 


2017-03-07 22:28:19.696152 [info] Starting Supervisor...
2017-03-07 22:28:19,885 CRIT Set uid to user 0
2017-03-07 22:28:19,885 INFO Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing
2017-03-07 22:28:19,887 INFO supervisord started with pid 6
2017-03-07 22:28:20,889 INFO spawned: 'start-script' with pid 113
2017-03-07 22:28:20,889 INFO spawned: 'deluge-script' with pid 114
2017-03-07 22:28:20,890 INFO spawned: 'deluge-web-script' with pid 115
2017-03-07 22:28:20,891 INFO spawned: 'privoxy-script' with pid 116
2017-03-07 22:28:20,894 DEBG 'start-script' stdout output:
[info] VPN is enabled, beginning configuration of VPN

2017-03-07 22:28:20,894 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2017-03-07 22:28:20,894 INFO success: deluge-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2017-03-07 22:28:20,894 INFO success: deluge-web-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2017-03-07 22:28:20,894 INFO success: privoxy-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2017-03-07 22:28:20,895 DEBG 'privoxy-script' stdout output:
[info] Privoxy set to disabled

2017-03-07 22:28:20,895 DEBG fd 26 closed, stopped monitoring <POutputDispatcher at 46949059601544 for <Subprocess at 46949059024512 with name privoxy-script in state RUNNING> (stderr)>
2017-03-07 22:28:20,895 DEBG fd 22 closed, stopped monitoring <POutputDispatcher at 46949059602984 for <Subprocess at 46949059024512 with name privoxy-script in state RUNNING> (stdout)>
2017-03-07 22:28:20,895 INFO exited: privoxy-script (exit status 0; expected)
2017-03-07 22:28:20,896 DEBG received SIGCLD indicating a child quit
2017-03-07 22:28:20,896 DEBG 'deluge-script' stdout output:
[info] Deluge config file doesn't exist, copying default...

2017-03-07 22:28:20,898 DEBG 'deluge-script' stdout output:
[info] VPN is enabled, checking VPN tunnel local ip is valid

2017-03-07 22:28:20,899 DEBG 'start-script' stdout output:
[info] VPN default certs defined, copying to /config/openvpn/...

2017-03-07 22:28:20,901 DEBG 'start-script' stdout output:
[info] VPN config file (ovpn extension) is located at /config/openvpn/openvpn.ovpn

2017-03-07 22:28:20,901 DEBG 'start-script' stderr output:
dos2unix: converting file /config/openvpn/openvpn.ovpn to Unix format...

2017-03-07 22:28:20,928 DEBG 'start-script' stdout output:
[info] Default route for container is 172.17.0.1

2017-03-07 22:28:20,930 DEBG 'start-script' stdout output:
[info] Adding 8.8.8.8 to /etc/resolv.conf

2017-03-07 22:28:20,932 DEBG 'start-script' stdout output:
[info] Adding 37.235.1.174 to /etc/resolv.conf

2017-03-07 22:28:20,934 DEBG 'start-script' stdout output:
[info] Adding 8.8.4.4 to /etc/resolv.conf

2017-03-07 22:28:20,936 DEBG 'start-script' stdout output:
[info] Adding 37.235.1.177 to /etc/resolv.conf

2017-03-07 22:28:20,940 DEBG 'start-script' stdout output:
[info] Adding 192.168.0.0/24 as route via docker eth0

2017-03-07 22:28:20,941 DEBG 'start-script' stdout output:
[info] ip route defined as follows...
--------------------

2017-03-07 22:28:20,941 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-03-07 22:28:20,941 DEBG 'start-script' stdout output:
--------------------

2017-03-07 22:28:20,945 DEBG 'start-script' stdout output:
[info] iptable_mangle support detected, adding fwmark for tables

2017-03-07 22:28:20,965 DEBG 'start-script' stdout output:
[info] iptables defined as follows...
--------------------

2017-03-07 22:28:20,966 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 8112 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
-A INPUT -s 192.168.0.0/24 -i eth0 -p tcp -m tcp --dport 58846 -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 8112 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
-A OUTPUT -d 192.168.0.0/24 -o eth0 -p tcp -m tcp --sport 58846 -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-03-07 22:28:20,966 DEBG 'start-script' stdout output:
--------------------

2017-03-07 22:28:20,966 DEBG 'start-script' stdout output:
[info] Starting OpenVPN...

2017-03-07 22:28:20,974 DEBG 'start-script' stdout output:
[info] OpenVPN started

2017-03-07 22:28:23,036 DEBG 'deluge-script' stdout output:
[info] Deluge not running
[info] Deluge listening interface IP 0.0.0.0 and VPN provider IP 10.43.10.6 different, marking for reconfigure

2017-03-07 22:28:29,789 DEBG 'deluge-script' stdout output:
[info] Attempting to start Deluge...

2017-03-07 22:28:30,351 DEBG 'deluge-script' stdout output:
[info] Deluge listening interface currently defined as 0.0.0.0
[info] Deluge listening interface will be changed to 10.43.10.6
[info] Saving changes to Deluge config file /config/core.conf...

2017-03-07 22:28:30,603 DEBG 'deluge-script' stderr output:
/usr/lib/python2.7/site-packages/deluge/_libtorrent.py:59: RuntimeWarning: to-Python converter for boost::shared_ptr<libtorrent::alert> already registered; second conversion method ignored.
import libtorrent as lt

2017-03-07 22:28:30,749 DEBG 'deluge-web-script' stdout output:
[info] Starting Deluge webui...

2017-03-07 22:28:30,977 DEBG 'deluge-script' stdout output:
Setting random_port to False..
Configuration value successfully updated.

2017-03-07 22:28:31,238 DEBG 'deluge-script' stdout output:
Setting listen_ports to (55923, 55923)..
Configuration value successfully updated.

2017-03-07 22:28:31,257 DEBG 'deluge-script' stdout output:
[info] Deluge started

 

Edited by dultcers
Link to comment
6 hours ago, dultcers said:

So I am having a very odd issue that I am hoping fill fix itself now as I feel as though I have tried everything... I have now re installed unRAID and the issue persists. :'( Whenever I add a torrent to Deluge it begins to download, speeds up as usual then slows down until it stalls only seconds later... checking the downloads folder show no data has been downloaded. I have played with every setting imaginable so I'm sure I'm just being an idiot.

 

I am using binhex-delugevpn with Private Internet Access. This issue started yesterday. I have been playing around with downloaders like Couch Potato but after removing every trace of those I could find and even re-installing the OS and re-configuring unRAID I am at a loss...

 

Please help! 

 

Here are some logs from Deluge:

 



2017-03-07 22:28:19.696152 [info] Starting Supervisor...
2017-03-07 22:28:19,885 CRIT Set uid to user 0
2017-03-07 22:28:19,885 INFO Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing
2017-03-07 22:28:19,887 INFO supervisord started with pid 6
2017-03-07 22:28:20,889 INFO spawned: 'start-script' with pid 113
2017-03-07 22:28:20,889 INFO spawned: 'deluge-script' with pid 114
2017-03-07 22:28:20,890 INFO spawned: 'deluge-web-script' with pid 115
2017-03-07 22:28:20,891 INFO spawned: 'privoxy-script' with pid 116
2017-03-07 22:28:20,894 DEBG 'start-script' stdout output:
[info] VPN is enabled, beginning configuration of VPN

2017-03-07 22:28:20,894 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2017-03-07 22:28:20,894 INFO success: deluge-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2017-03-07 22:28:20,894 INFO success: deluge-web-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2017-03-07 22:28:20,894 INFO success: privoxy-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2017-03-07 22:28:20,895 DEBG 'privoxy-script' stdout output:
[info] Privoxy set to disabled

2017-03-07 22:28:20,895 DEBG fd 26 closed, stopped monitoring <POutputDispatcher at 46949059601544 for <Subprocess at 46949059024512 with name privoxy-script in state RUNNING> (stderr)>
2017-03-07 22:28:20,895 DEBG fd 22 closed, stopped monitoring <POutputDispatcher at 46949059602984 for <Subprocess at 46949059024512 with name privoxy-script in state RUNNING> (stdout)>
2017-03-07 22:28:20,895 INFO exited: privoxy-script (exit status 0; expected)
2017-03-07 22:28:20,896 DEBG received SIGCLD indicating a child quit
2017-03-07 22:28:20,896 DEBG 'deluge-script' stdout output:
[info] Deluge config file doesn't exist, copying default...

2017-03-07 22:28:20,898 DEBG 'deluge-script' stdout output:
[info] VPN is enabled, checking VPN tunnel local ip is valid

2017-03-07 22:28:20,899 DEBG 'start-script' stdout output:
[info] VPN default certs defined, copying to /config/openvpn/...

2017-03-07 22:28:20,901 DEBG 'start-script' stdout output:
[info] VPN config file (ovpn extension) is located at /config/openvpn/openvpn.ovpn

2017-03-07 22:28:20,901 DEBG 'start-script' stderr output:
dos2unix: converting file /config/openvpn/openvpn.ovpn to Unix format...

2017-03-07 22:28:20,928 DEBG 'start-script' stdout output:
[info] Default route for container is 172.17.0.1

2017-03-07 22:28:20,930 DEBG 'start-script' stdout output:
[info] Adding 8.8.8.8 to /etc/resolv.conf

2017-03-07 22:28:20,932 DEBG 'start-script' stdout output:
[info] Adding 37.235.1.174 to /etc/resolv.conf

2017-03-07 22:28:20,934 DEBG 'start-script' stdout output:
[info] Adding 8.8.4.4 to /etc/resolv.conf

2017-03-07 22:28:20,936 DEBG 'start-script' stdout output:
[info] Adding 37.235.1.177 to /etc/resolv.conf

2017-03-07 22:28:20,940 DEBG 'start-script' stdout output:
[info] Adding 192.168.0.0/24 as route via docker eth0

2017-03-07 22:28:20,941 DEBG 'start-script' stdout output:
[info] ip route defined as follows...
--------------------

2017-03-07 22:28:20,941 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-03-07 22:28:20,941 DEBG 'start-script' stdout output:
--------------------

2017-03-07 22:28:20,945 DEBG 'start-script' stdout output:
[info] iptable_mangle support detected, adding fwmark for tables

2017-03-07 22:28:20,965 DEBG 'start-script' stdout output:
[info] iptables defined as follows...
--------------------

2017-03-07 22:28:20,966 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 8112 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
-A INPUT -s 192.168.0.0/24 -i eth0 -p tcp -m tcp --dport 58846 -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 8112 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
-A OUTPUT -d 192.168.0.0/24 -o eth0 -p tcp -m tcp --sport 58846 -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-03-07 22:28:20,966 DEBG 'start-script' stdout output:
--------------------

2017-03-07 22:28:20,966 DEBG 'start-script' stdout output:
[info] Starting OpenVPN...

2017-03-07 22:28:20,974 DEBG 'start-script' stdout output:
[info] OpenVPN started

2017-03-07 22:28:23,036 DEBG 'deluge-script' stdout output:
[info] Deluge not running
[info] Deluge listening interface IP 0.0.0.0 and VPN provider IP 10.43.10.6 different, marking for reconfigure

2017-03-07 22:28:29,789 DEBG 'deluge-script' stdout output:
[info] Attempting to start Deluge...

2017-03-07 22:28:30,351 DEBG 'deluge-script' stdout output:
[info] Deluge listening interface currently defined as 0.0.0.0
[info] Deluge listening interface will be changed to 10.43.10.6
[info] Saving changes to Deluge config file /config/core.conf...

2017-03-07 22:28:30,603 DEBG 'deluge-script' stderr output:
/usr/lib/python2.7/site-packages/deluge/_libtorrent.py:59: RuntimeWarning: to-Python converter for boost::shared_ptr<libtorrent::alert> already registered; second conversion method ignored.
import libtorrent as lt

2017-03-07 22:28:30,749 DEBG 'deluge-web-script' stdout output:
[info] Starting Deluge webui...

2017-03-07 22:28:30,977 DEBG 'deluge-script' stdout output:
Setting random_port to False..
Configuration value successfully updated.

2017-03-07 22:28:31,238 DEBG 'deluge-script' stdout output:
Setting listen_ports to (55923, 55923)..
Configuration value successfully updated.

2017-03-07 22:28:31,257 DEBG 'deluge-script' stdout output:
[info] Deluge started

 

 

you've chopped off the really useful bit at the start of this log :-(, but from the above it looks like its a successful start, my guess would be that you have incorrectly set the folders and thus deluge cannot write to disk, please can you post a screenshot of the deluge webui showing preferences/downloads screen.

Link to comment
5 hours ago, binhex said:

 

you've chopped off the really useful bit at the start of this log :-(, but from the above it looks like its a successful start, my guess would be that you have incorrectly set the folders and thus deluge cannot write to disk, please can you post a screenshot of the deluge webui showing preferences/downloads screen.

 Attached are pictures of the configuration. Thanks!

config.PNG

downloads.PNG

Link to comment
2 minutes ago, binhex said:

@dultcers yep as suspected its a path issue, change all references to "Downloads" to "data" in the deluge ui, you dont have a volume mapping of "/Downloads".

 

note - the path is case sensitive so make sure its lowercase "data"

That was it! Maybe that was too simple... lol. Thanks binhex!

Edited by dultcers
Link to comment
40 minutes ago, cloud1771 said:

So I am just setting this up for the first time and only getting one error and not sure if it is working or not.

The error is:

   Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: config (2.4.0)

I included the log file.

Thanks in advance for any help.

supervisord.log

 

no that isnt a successful start, im pretty confident the issue is with the name of the ovpn config file, its currently

 

Texas, Houstan-udp.ovpn

please remove the comma, if possible remove the space too and use a hyphen, so "texas-houston-udp.ovpn" would be a better filename.

Link to comment
On 04/03/2017 at 7:28 AM, remati said:

Does this docker version of deluge allow us to specify the file permissions chmod of the downloaded torrents?


Sent from my iPad using Tapatalk

 

This is now possible, by default the umask is 000, if you want to change this then please create an environment variable with a key name of "UMASK" and the 3 digit umask of the value you want.

Link to comment
6 hours ago, dultcers said:

That was it! Maybe that was too simple... lol. Thanks binhex!

 

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

Link to comment

So, after yesterdays update to both SickRage and Deluge, SickRage is no longer able to connect to Deluge.  Both are using binhex's version of the containers.  Anyone else seeing "2017-03-08 15:53:18 Thread-26 :: [41d7d9d] Request failed: No JSON object could be decoded" when SickRage tries to send a torrent over to Deluge since the update?  Was hoping the Deluge container update today would have fixed the issue, but no luck. I've already tried destroying the dockers and then rebuilding them from template.  Haven't gone the full nuclear option yet and blown away all dockers, docker.img file, and rebuild, but I think this is more of an API issue between programs and not the dockers themselves.  Let me know if it's the software or the dockers, or my stuff is just borked. Thanks!

Edited by chesh
Link to comment
3 hours ago, cloud1771 said:

Thanks, no error this time!

But just want to make sure its working if you don't mind. here is a new logfile

supervisord.log

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/*

 

Link to comment
 
This is now possible, by default the umask is 000, if you want to change this then please create an environment variable with a key name of "UMASK" and the 3 digit umask of the value you want.


Thanks for implementing this. I seem to be having some trouble with it though. I set the umask to 777 with the puid of 99 and the pgid of 100 (the defaults) but when adding torrent files to deluge it fails. Any suggestions on what I should change?


Sent from my iPad using Tapatalk Pro
Link to comment
13 hours ago, cloud1771 said:

Thanks, no error this time!

But just want to make sure its working if you don't mind. here is a new logfile

supervisord.log

 

That looks ok to me, tbh if you can view the webui then you have a tunnel running, you will of course now have to figure out how your vpn provider handles port forwarding :-).

 

if you want a bit more reassurance click on link in sig to vpn docker faq and look at DelugeVPN Docker FAQ Q3.

Link to comment
4 hours ago, remati said:

 


Thanks for implementing this. I seem to be having some trouble with it though. I set the umask to 777 with the puid of 99 and the pgid of 100 (the defaults) but when adding torrent files to deluge it fails. Any suggestions on what I should change?


Sent from my iPad using Tapatalk Pro

 

 

a umask of 777 means you are removing all permissions for newly created files, im assuming what you really want to do is the reverse of this right and set rwx for user and group, if so then thats the default value (000). 

 

But i dont think this is your issue, you mention you cant add torrent files to deluge, how exactly does it fail?, screenshot would be good, also supervisord.log file.

Link to comment
15 hours ago, chesh said:

So, after yesterdays update to both SickRage and Deluge, SickRage is no longer able to connect to Deluge.  Both are using binhex's version of the containers.  Anyone else seeing "2017-03-08 15:53:18 Thread-26 :: [41d7d9d] Request failed: No JSON object could be decoded" when SickRage tries to send a torrent over to Deluge since the update?  Was hoping the Deluge container update today would have fixed the issue, but no luck. I've already tried destroying the dockers and then rebuilding them from template.  Haven't gone the full nuclear option yet and blown away all dockers, docker.img file, and rebuild, but I think this is more of an API issue between programs and not the dockers themselves.  Let me know if it's the software or the dockers, or my stuff is just borked. Thanks!

 

I'm seeing something similar when attempting to access deluge webui

 

2017-03-09 17:39:43,751 DEBG 'deluge-web-script' stderr output:
[ERROR ] 17:39:43 json_api:285 Invalid JSON request content-type: application/x-www-form-urlencoded; charset=UTF-8

Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/deluge/ui/web/json_api.py", line 307, in render
d = self._on_json_request(request)
File "/usr/lib/python2.7/site-packages/deluge/ui/web/json_api.py", line 267, in _on_json_request
raise JSONException(message)
JSONException: Invalid JSON request content-type: application/x-www-form-urlencoded; charset=UTF-8

2017-03-09 17:39:57,827 DEBG 'deluge-web-script' stderr output:
[ERROR ] 17:39:57 json_api:285 Invalid JSON request content-type: application/json-rpc

Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/deluge/ui/web/json_api.py", line 307, in render
d = self._on_json_request(request)
File "/usr/lib/python2.7/site-packages/deluge/ui/web/json_api.py", line 267, in _on_json_request
raise JSONException(message)
JSONException: Invalid JSON request content-type: application/json-rpc

privoxy and other access seems to work fine

Link to comment
17 hours ago, chesh said:

So, after yesterdays update to both SickRage and Deluge, SickRage is no longer able to connect to Deluge.  Both are using binhex's version of the containers.  Anyone else seeing "2017-03-08 15:53:18 Thread-26 :: [41d7d9d] Request failed: No JSON object could be decoded" when SickRage tries to send a torrent over to Deluge since the update?  Was hoping the Deluge container update today would have fixed the issue, but no luck. I've already tried destroying the dockers and then rebuilding them from template.  Haven't gone the full nuclear option yet and blown away all dockers, docker.img file, and rebuild, but I think this is more of an API issue between programs and not the dockers themselves.  Let me know if it's the software or the dockers, or my stuff is just borked. Thanks!

I have been getting similar errors in Radarr (linuxserver's container) since the latest delugevpn update:

Unable to connect to Deluge, please check your settings: Unable to connect to Deluge, please check your settings    
HttpClient    HTTP Error - Res: [POST] http://192.168.1.10:8112/json: 500.InternalServerError

And in the docker logs of deluge I have many of these errors

[ERROR ] 12:24:38 json_api:285 Invalid JSON request content-type: application/json-rpc 

I have Sonarr (binhex container) setup with the exact same settings for Deluge and it works fine. Everything was working ok before the update.

 

I am also having issues with the extractor and labels plugins since the update. The extractor settings are no longer available, and I cannot re-enable it in the plugins menu. For the labels plugin, I can see the old labels I have added before, but I cannot add labels to any torrents. It also does not seem to stick when I enable it in settings.

Edited by kroovy
Link to comment

Hi @daemon9th @chesh @kroovy the reason why you are getting the failure to connect from external apps is because Deluge have fixed a security hole in their webui in release 1.3.14 (latest stable), unfortunately that means that all the other developers for apps that link to deluge need to update their code, i would imagine the app devs will catch up with this change quite quickly, but if you just cant wait then there is a hack detailed in the post below:-

 

http://forum.deluge-torrent.org/viewtopic.php?f=7&t=54428

Link to comment
2017-03-08 12:00:32,759 DEBG 'deluge-web-script' stderr output:
[ERROR ] 12:00:32 pluginmanagerbase:146 Unable to instantiate plugin!

2017-03-08 12:00:32,761 DEBG 'deluge-web-script' stderr output:
[ERROR ] 12:00:32 pluginmanagerbase:147 Can't extract file(s) to egg cache

The following error occurred while trying to extract file(s) to the Python egg
cache:

[Errno 13] Permission denied: '/home/nobody/.cache/Python-Eggs/Label-0.2-py2.7.egg-tmp'

The Python egg cache directory is currently set to:

/home/nobody/.cache/Python-Eggs

Perhaps your account does not have write access to this directory? You can
change the cache directory by setting the PYTHON_EGG_CACHE environment
variable to point to an accessible directory.

Since the last update I've been noticing this showing up in the logs. Do I need to do anything about this? As far as I can tell it seems to be working. I did try changing the directory but regardless of where it is something doesn't seem to have permissions.

Edited by Leondre
Link to comment

This was fixed in Sonarr on Mar 7, 2017:

 

2.0.0.4645 - Mar 7 2017 Installed

Fixed Deluge 1.3.14 API support due to changed json-rpc checks. (hotfix)
Fixed DownloadStation client stuck in infinite loop in some cases.
Fixed DownloadStation client failing if non-bt/nzb downloads exist.
Fixed NZBGet delete:scan treated as failure
Link to comment
On 06/03/2017 at 0:09 AM, BakedPizza said:

To get this container to execute in Docker on the latest Synology version (DSM 6.1-15047 Update 1):

  1. The --cap-add=NET_ADMIN parameter isn't supported by the Docker GUI. Without it iptables won't play nice. Instead select 'Execute container using high privilege' under the General settings of the container.
  2. Make sure that mandatory kernel modules are loaded. We got two options (A & B):
    A. This won't survive a reboot. SSH as an user in the administrators group to your Synology NAS and run the following commands:
    
    sudo insmod /lib/modules/tun.ko
    sudo insmod /lib/modules/iptable_mangle.ko

    B. This will recover the loading during the boot. Create a new 'Triggered Task' from the DSM 'Control Panel' -> 'Task Scheduler'. Select user 'root', event 'Boot-up' and check 'Enabled'. As script enter:
    
    insmod /lib/modules/tun.ko
    insmod /lib/modules/iptable_mangle.ko

     

  3. Done.
@binhex:
Could you please consider adding an option to shutdown the container with a non-zero status if these modules are not loaded (if possible)? Currently the container appears to be running, but Deluge will not be loaded because of these missing modules. It took me some time to figure out why I couldn't reach Deluge.
 
Also, Synology Docker contains and option (in the GUI) to auto restart the container on unexpected shutdown (non-zero exit status). I think it will append --restart failure to the docker command. If you add this shutdown we will always have enough time to make sure the loading of the required modules is done during the boot-up (using the Task Scheduler).
 
Thank you so much for the container. :) The most used 3rd packages source for our Synology NAS systems (SynoCommunity) is currently incompatible with the latest version of the operation system (DSM 6+) and it looks like it will be the case for a long time. So containers like these are essential for us.

 

 

@BakedPizza That's great, thanks a lot for that. My only issue now is that apparmor seems to be blocking something to do with nginx.

 

/usr/bin/nginx: error while loading shared libraries: libdl.so.2: cannot open shared object file: Permission denied

 

I did disable apparmor temporarily and it worked, so If I can fix that I'm good to go!

Edited by Hansel
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.