thestraycat 0 Posted February 13, 2020 Share Posted February 13, 2020 Does anyone else suffer from ballooning memory usage on this container? Eventually it bricks my server. I'm running: binhex/arch-delugevpn:2.0.3-2-01 Quote Link to post
casperse 13 Posted February 13, 2020 Share Posted February 13, 2020 Is there any "security" difference between the Binhex Deluge and the Binhex rTorrent? (Only one I can think of is the Space invader IP Block list in Deluge that isn't available in the rTorrent) But beside that its the same right Quote Link to post
binhex 780 Posted February 13, 2020 Author Share Posted February 13, 2020 28 minutes ago, casperse said: Is there any "security" difference between the Binhex Deluge and the Binhex rTorrent? security wise they are both as secure as each other, using the same shared image. 1 Quote Link to post
aLbOsOuLja 0 Posted February 15, 2020 Share Posted February 15, 2020 Is it safe to have docker running with high running privileges in the synology docker for DelugeVPN? Quote Link to post
vvolfpack 2 Posted February 16, 2020 Share Posted February 16, 2020 I had an error where Deluge was using the container disk image for my downloads, thus setting off warnings. Not sure what triggered this change, but when I tried to revert the location to usual <screenshot>, I got a command failed error: Error response from daemon: endpoint with name binhex-delugevpn already exists in network bridge.. Anything I'm missing? root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='binhex-delugevpn' --net='bridge' --privileged=true -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e 'VPN_ENABLED'='yes' -e 'VPN_USER'='REDACTED' -e 'VPN_PASS'='REDACTED' -e 'VPN_PROV'='pia' -e 'VPN_OPTIONS'='' -e 'STRICT_PORT_FORWARD'='yes' -e 'ENABLE_PRIVOXY'='yes' -e 'LAN_NETWORK'='192.168.86.0/24' -e 'NAME_SERVERS'='209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,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 'DEBUG'='false' -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -p '8112:8112/tcp' -p '58846:58846/tcp' -p '58946:58946/tcp' -p '58946:58946/udp' -p '8118:8118/tcp' -v '/mnt/user/Downloads/':'/data':'rw' -v '/mnt/user/appdata/binhex-delugevpn':'/config':'rw' 'binhex/arch-delugevpn' 13da363b92fbdc7dcf0b37d926e09828d3f6dd11f05cbf1677321a618df3abcf /usr/bin/docker: Error response from daemon: endpoint with name binhex-delugevpn already exists in network bridge. The command failed. Quote Link to post
binhex 780 Posted February 17, 2020 Author Share Posted February 17, 2020 On 2/16/2020 at 5:56 AM, vvolfpack said: I got a command failed error: Error response from daemon: endpoint with name binhex-delugevpn already exists in network bridge.. Anything I'm missing? it means you are trying to create a container with the same name as one that already exists, issue the following command on your host and you will no doubt see you already have a container named 'binhex-delugevpn':- docker ps -a so delete the old one if you want to create a new container with the same name. Quote Link to post
binhex 780 Posted February 17, 2020 Author Share Posted February 17, 2020 On 2/15/2020 at 11:32 PM, aLbOsOuLja said: Is it safe to have docker running with high running privileges in the synology docker for DelugeVPN? there are no known vulnerabilities that im aware of that use elevated privileges for this container on synology. Quote Link to post
vvolfpack 2 Posted February 17, 2020 Share Posted February 17, 2020 (edited) On 2/17/2020 at 3:22 AM, binhex said: issue the following command on your host and you will no doubt see you already have a container named 'binhex-delugevpn':- Running the command doesn't show 'binhex-delugevpn' as a container. However, I do see a folder for the container under appdata. Deleting this folder and reinstalling the docker also shows me the same 'command failed' error from before. Attaching my diagnostics file in case it's an error in the docker image itself since delugevpn downloaded items to its diskimage causing it to reach 100% storage. CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES dd408724d851 binhex/arch-jackett "/usr/bin/tini -- /b…" 37 hours ago Up 27 hours 0.0.0.0:9117->9117/tcp binhex-jackett 9be5e3a09bc8 binhex/arch-sickchill "/usr/bin/tini -- /b…" 37 hours ago Created binhex-sickchill 6b116441524c linuxserver/openvpn-as "/init" 38 hours ago Up 27 hours 0.0.0.0:943->943/tcp, 0.0.0.0:9443->9443/tcp, 0.0.0.0:1194->1194/udp openvpn-as dd876d1256e3 linuxserver/duckdns "/init" 3 days ago Up 27 hours duckdns 3aedc50e459c binhex/arch-plexpass "/usr/bin/tini -- /b…" 3 days ago Up 27 hours binhex-plexpass 9c7295b66cb6 binhex/arch-sonarr "/usr/bin/tini -- /b…" 6 days ago Exited (0) 3 days ago binhex-sonarr b1fdead365e7 binhex/arch-radarr "/usr/bin/tini -- /b…" 6 days ago Exited (0) 38 hours ago binhex-radarr 348ae87c462b binhex/arch-sabnzbd "/usr/bin/tini -- /b…" 9 days ago Up 27 hours 0.0.0.0:8080->8080/tcp, 0.0.0.0:8090->8090/tcp binhex-sabnzbd d64832469e44 binhex/arch-krusader "/usr/bin/tini -- /b…" 10 days ago Up 27 hours 5900/tcp, 0.0.0.0:6080->6080/tcp binhex-krusader vvolfbox-diagnostics-20200217-1058.zip Edit 1: After a reboot, the command passes successfully, but I'm unable to start the docker. After clicking "Start". It spins for a second and returns to "Stopped" state. Any help would be much appreciated! EDIT 2: Getting these syslogs from trying to start the application Feb 18 23:02:14 vvolfbox kernel: docker0: port 5(veth72bc119) entered blocking state Feb 18 23:02:14 vvolfbox kernel: docker0: port 5(veth72bc119) entered disabled state Feb 18 23:02:14 vvolfbox kernel: device veth72bc119 entered promiscuous mode Feb 18 23:02:14 vvolfbox kernel: IPv6: ADDRCONF(NETDEV_UP): veth72bc119: link is not ready Feb 18 23:02:14 vvolfbox kernel: docker0: port 5(veth72bc119) entered blocking state Feb 18 23:02:14 vvolfbox kernel: docker0: port 5(veth72bc119) entered forwarding state Feb 18 23:02:14 vvolfbox kernel: docker0: port 5(veth72bc119) entered disabled state Feb 18 23:02:14 vvolfbox kernel: eth0: renamed from veth7da683a Feb 18 23:02:14 vvolfbox kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth72bc119: link becomes ready Feb 18 23:02:14 vvolfbox kernel: docker0: port 5(veth72bc119) entered blocking state Feb 18 23:02:14 vvolfbox kernel: docker0: port 5(veth72bc119) entered forwarding state Feb 18 23:02:15 vvolfbox kernel: docker0: port 5(veth72bc119) entered disabled state Feb 18 23:02:15 vvolfbox kernel: veth7da683a: renamed from eth0 Feb 18 23:02:15 vvolfbox kernel: docker0: port 5(veth72bc119) entered disabled state Feb 18 23:02:15 vvolfbox kernel: device veth72bc119 left promiscuous mode Feb 18 23:02:15 vvolfbox kernel: docker0: port 5(veth72bc119) entered disabled state Any help would be much appreciated, @binhex! Edited February 19, 2020 by vvolfpack Updating with the latest information Quote Link to post
barajas.uriel 0 Posted February 17, 2020 Share Posted February 17, 2020 Is there an issue with PIA? I havent been able to download anything for 2 days. Connection times out. When I set it to not use VPN, I get super slow speeds and I am on Fiber. Quote Link to post
jonathanm 1163 Posted February 17, 2020 Share Posted February 17, 2020 18 minutes ago, barajas.uriel said: Is there an issue with PIA? I havent been able to download anything for 2 days. Connection times out. When I set it to not use VPN, I get super slow speeds and I am on Fiber. PIA has many different endpoints, try a different one on the port forward enabled list. Quote Link to post
barajas.uriel 0 Posted February 18, 2020 Share Posted February 18, 2020 14 hours ago, jonathanm said: PIA has many different endpoints, try a different one on the port forward enabled list. I have tried several, they start up, and then the connection times out. Public and private trackers. Quote Link to post
Gragorg 3 Posted February 19, 2020 Share Posted February 19, 2020 On 2/18/2020 at 9:27 AM, barajas.uriel said: I have tried several, they start up, and then the connection times out. Public and private trackers. Did you find a solution? Mine stopped downloading yesterday. I restarted the docker and now I can't even access the web UI. Quote Link to post
Gragorg 3 Posted February 19, 2020 Share Posted February 19, 2020 Ok so if I disable VPN it seems to work. I guess I will try another end point. Quote Link to post
a12vman 1 Posted February 20, 2020 Share Posted February 20, 2020 (edited) Update: My issue was network-related. I had enabled a 2nd NIC on my server. I disabled the 2nd NIC and rebooted the server -. All is well now. I think I will leave it alone before I create more problems. I have been sailing with Deluge for some time now without issue. I have VPN enabled in Deluge routing thru Toronto. I rebooted my unraid server today. I am not able to open the Deluge WEBUI without first disabling the VPN. What is the issue? This was working fine before I did the re-boot. I just get the "site cannot be reached" error. Using port 8112. Here is my log: 2020-02-19 20:39:33,304 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2020-02-19 20:39:33,305 INFO success: watchdog-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2020-02-19 20:39:33,425 DEBG 'start-script' stdout output: [info] Default route for container is 172.17.0.1 2020-02-19 20:39:33,431 DEBG 'start-script' stdout output: [info] Adding 209.222.18.222 to /etc/resolv.conf 2020-02-19 20:39:33,436 DEBG 'start-script' stdout output: [info] Adding 84.200.69.80 to /etc/resolv.conf 2020-02-19 20:39:33,442 DEBG 'start-script' stdout output: [info] Adding 37.235.1.174 to /etc/resolv.conf 2020-02-19 20:39:33,448 DEBG 'start-script' stdout output: [info] Adding 1.1.1.1 to /etc/resolv.conf 2020-02-19 20:39:33,454 DEBG 'start-script' stdout output: [info] Adding 209.222.18.218 to /etc/resolv.conf 2020-02-19 20:39:33,459 DEBG 'start-script' stdout output: [info] Adding 37.235.1.177 to /etc/resolv.conf 2020-02-19 20:39:33,465 DEBG 'start-script' stdout output: [info] Adding 84.200.70.40 to /etc/resolv.conf 2020-02-19 20:39:33,471 DEBG 'start-script' stdout output: [info] Adding 1.0.0.1 to /etc/resolv.conf 2020-02-19 20:41:33,599 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error 2020-02-19 20:43:33,724 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error 2020-02-19 20:45:38,847 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error 2020-02-19 20:47:43,970 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error 2020-02-19 20:49:49,092 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error 2020-02-19 20:51:54,221 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error Then I shut down the Docker and deleted the Config Files in OpenVPN. Copied the original certificates back and changed my end point from Toronto to France. Same results in the logfile. Also looking at my Unraid Log I am seeing the following : Feb 20 07:36:16 MediaTower kernel: docker0: port 4(veth9c959ce) entered blocking state Feb 20 07:36:16 MediaTower kernel: docker0: port 4(veth9c959ce) entered forwarding state Feb 20 07:36:16 MediaTower kernel: docker0: port 4(veth9c959ce) entered disabled state Feb 20 07:36:17 MediaTower kernel: eth0: renamed from vethde49b44 Feb 20 07:36:17 MediaTower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth9c959ce: link becomes ready Feb 20 07:36:17 MediaTower kernel: docker0: port 4(veth9c959ce) entered blocking state Feb 20 07:36:17 MediaTower kernel: docker0: port 4(veth9c959ce) entered forwarding state Feb 20 07:38:37 MediaTower kernel: docker0: port 4(veth9c959ce) entered disabled state Feb 20 07:38:37 MediaTower kernel: vethde49b44: renamed from eth0 Feb 20 07:38:37 MediaTower kernel: docker0: port 4(veth9c959ce) entered disabled state Feb 20 07:38:37 MediaTower kernel: device veth9c959ce left promiscuous mode Feb 20 07:38:37 MediaTower kernel: docker0: port 4(veth9c959ce) entered disabled state Feb 20 07:38:41 MediaTower kernel: docker0: port 4(veth55c0157) entered blocking state Feb 20 07:38:41 MediaTower kernel: docker0: port 4(veth55c0157) entered disabled state Feb 20 07:38:41 MediaTower kernel: device veth55c0157 entered promiscuous mode Feb 20 07:38:41 MediaTower kernel: IPv6: ADDRCONF(NETDEV_UP): veth55c0157: link is not ready Feb 20 07:38:41 MediaTower kernel: docker0: port 4(veth55c0157) entered blocking state Feb 20 07:38:41 MediaTower kernel: docker0: port 4(veth55c0157) entered forwarding state Feb 20 07:38:41 MediaTower kernel: docker0: port 4(veth55c0157) entered disabled state Feb 20 07:38:43 MediaTower kernel: eth0: renamed from veth37cc761 Feb 20 07:38:43 MediaTower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth55c0157: link becomes ready Feb 20 07:38:43 MediaTower kernel: docker0: port 4(veth55c0157) entered blocking state Feb 20 07:38:43 MediaTower kernel: docker0: port 4(veth55c0157) entered forwarding state Feb 20 07:57:51 MediaTower kernel: docker0: port 4(veth55c0157) entered disabled state Feb 20 07:57:51 MediaTower kernel: veth37cc761: renamed from eth0 Feb 20 07:57:52 MediaTower kernel: docker0: port 4(veth55c0157) entered disabled state Feb 20 07:57:52 MediaTower kernel: device veth55c0157 left promiscuous mode Feb 20 07:57:52 MediaTower kernel: docker0: port 4(veth55c0157) entered disabled state Feb 20 07:59:46 MediaTower kernel: docker0: port 4(vethc3f7b23) entered blocking state Feb 20 07:59:46 MediaTower kernel: docker0: port 4(vethc3f7b23) entered disabled state Feb 20 07:59:46 MediaTower kernel: device vethc3f7b23 entered promiscuous mode Feb 20 07:59:46 MediaTower kernel: IPv6: ADDRCONF(NETDEV_UP): vethc3f7b23: link is not ready Feb 20 07:59:46 MediaTower kernel: docker0: port 4(vethc3f7b23) entered blocking state Feb 20 07:59:46 MediaTower kernel: docker0: port 4(vethc3f7b23) entered forwarding state Feb 20 07:59:46 MediaTower kernel: docker0: port 4(vethc3f7b23) entered disabled state Feb 20 07:59:47 MediaTower kernel: eth0: renamed from veth3940a12 Feb 20 07:59:47 MediaTower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethc3f7b23: link becomes ready Feb 20 07:59:47 MediaTower kernel: docker0: port 4(vethc3f7b23) entered blocking state Feb 20 07:59:47 MediaTower kernel: docker0: port 4(vethc3f7b23) entered forwarding state Edited February 20, 2020 by a12vman Additional Information Quote Link to post
oskarax 0 Posted February 20, 2020 Share Posted February 20, 2020 Hi! New to Unraid but learning on the way and watching many Youtube guides. Ive just configured DelugeVPN and everything is working fine except for Privoxy. I just want to use Privoxy for my browsing but when i configure my network settings on my mac my internet connection goes down. I think im doing everything right but something is failing. In the log file for the Docker image it says 2020-02-20 20:21:16,883 DEBG 'watchdog-script' stdout output: [info] Privoxy process listening on port 8118 Any ideas on what may be wrong here? Quote Link to post
wgstarks 213 Posted February 20, 2020 Share Posted February 20, 2020 4 minutes ago, oskarax said: Hi! New to Unraid but learning on the way and watching many Youtube guides. Ive just configured DelugeVPN and everything is working fine except for Privoxy. I just want to use Privoxy for my browsing but when i configure my network settings on my mac my internet connection goes down. I think im doing everything right but something is failing. In the log file for the Docker image it says 2020-02-20 20:21:16,883 DEBG 'watchdog-script' stdout output: [info] Privoxy process listening on port 8118 Any ideas on what may be wrong here? Exactly what settings are you using on your Mac? Quote Link to post
oskarax 0 Posted February 20, 2020 Share Posted February 20, 2020 (edited) 3 minutes ago, wgstarks said: Exactly what settings are you using on your Mac? im using the webproxy HTTP and the secure webproxy HTTPS, filling in my host ip and portnumber 8118. When ive done that i have no internet access at all. Just fails to connect. Edited February 20, 2020 by oskarax typo Quote Link to post
wgstarks 213 Posted February 20, 2020 Share Posted February 20, 2020 Have you tried another browser? Quote Link to post
oskarax 0 Posted February 20, 2020 Share Posted February 20, 2020 4 minutes ago, wgstarks said: Have you tried another browser? Ive tried Safari, Chrome and Firefox. Exactly the same on all of them Just tries to connect but after a while fails... Quote Link to post
barajas.uriel 0 Posted February 20, 2020 Share Posted February 20, 2020 22 hours ago, Gragorg said: Did you find a solution? Mine stopped downloading yesterday. I restarted the docker and now I can't even access the web UI. No, I haven't. They connect and then they time out. Not really sure whats going on. I also tested rtorrrentVPN and the same thing happens. Or I can't even login to the webui. Quote Link to post
Xcelsior86 4 Posted February 21, 2020 Share Posted February 21, 2020 Having a similar issue myself. The last few days the proxy has been spotty. I have an internet connection without issue when using it on my PC, but the docker containers say they have no connection through the proxy. Using ExpressVPN. Quote Link to post
daemon9th 1 Posted February 21, 2020 Share Posted February 21, 2020 (edited) nevermind... my vpn supplier has apparently changed their own supplier, and all configs changed. All is fine again. Edited February 21, 2020 by daemon9th Quote Link to post
vecna 0 Posted February 22, 2020 Share Posted February 22, 2020 On 4/19/2019 at 5:19 PM, emteedubs said: Edit: Narrowed down the issue. For some reason, the error below only happens when running the container on the docker swarm overlay network. When I run it on a docker bridge network, things are fine now. I only wish more containers supported swarm properly. =( I hate to keep asking the same question. But this "write UDP: Operation not permitted (code=1)" error keeps coming back again. I was able to resolve it last time (maybe by luck) by flushing my IPtables on my Ubuntu 18.04 server. It worked for about a week and without me doing much other than maybe turning the containers off and on, it suddenly stopped working again with that error. This time I tried to flush the IPtables, reboot my router, but still no go. I installed a pia-openvpn docker container on the same server as delugevpn to test if it may be a server config issue. But with this other pia-openvpn container, it was able to connect to PIA without this UDP write error using the same credentials. Unfortunately there's nothing more in the log to help me test other ways to figure out the problem. Any thoughts from the experts here? What does that error code really mean? @emteedubs i know it's been nearly a year since you posted, but did you ever get this setup working with docker swarm? I'm stuck with the same issue, looking for some advise/direction. I don't feel comfortable with separate openvpn and deluge containers and I want @binhex container on the overlay network so my other services can communicate with it easily. Quote Link to post
MammothJerk 5 Posted February 22, 2020 Share Posted February 22, 2020 (edited) i hadn't done any changes for a long time then 2 days ago or so delugeVPN just completely stopped downloading/uploading anything. If i turn VPN off in the template it starts downloading/uploading instantly. and the weird thing is even when VPN is active and DelugeVPN is not downloading anything, the privoxy proxy still works for clients connected to it. My provider is Mullvad and it seems they had an update (to their desktop app from what it looks like) just around that time. that could be related somehow? Any ideas? attached the (hopefully) relevant log edit: Started a new container with the same settings and it works, so something mustve gotten screwed up within the config oh boy here i go troubleshootin again edit2: had to change incoming port for whatever reason... had been running fine for months and then just died, weird. Edited February 29, 2020 by MammothJerk Quote Link to post
raiditup 9 Posted February 23, 2020 Share Posted February 23, 2020 For those of you using PIA and have had their torrents stop working recently, I've found the beta version (2.0.0) of the ltConfig plugin doesn't work with Deluge 2.0.4 which is what the latest docker release is on. Like another user, I created a brand new docker container which allowed my torrents to start working again, but my speeds were slow. When I compiled and installed the ltConfig plugin in the new container, the torrents stopped working again. At this point if you want PIA working with full speeds, your only bet is to roll the docker container back to Deluge 2.0.3. You can do this by stopping the container and editing the repository setting to point to the last 2.0.3 release. The container will automatically rollback to the specified version. The repository should look like this, binhex/arch-delugevpn:2.0.3_23_g5f1eada3e-1-03 Quote Link to post
7959 posts in this topic Last Reply
Recommended Posts
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.