Rourke

Is there any way this qBittorrent container can talk to other containers in the same network by hostname/container name?

I've setup an 'external program' in the qBittorrent settings from which I do a curl command to another PHP container in the same docker network. However unlike other containers I'm not able to resolve the PHP container's hostname to the IP address. For example I'm doing curl "http://nginx/qbit/index.php", but it can't resolve. Anyone knows what I can change to reach other containers by hostname?

You could go into the container with sudo docker exec -it qbittorrent /bin/bash (or /bin/sh) and check why you can't read or write to your download volume. Usually there is something out of the ordinary.

Sure! I'm using the PUID and PGID environment variables so that all files created from this qBittorrent are from my user (user and group ID 1000). This way I can easily browse, move or even edit files through my server (host) without going into the container itself. However I've mounted the volume ~/downloads:/downloads which was still a folder owned by root on my host. So basically I did a id command on my host, saw user and group id 1000, did sudo chown -R 1000:1000 ~/downloads, restarted the container and it could read and write to my /downloads folder.

I seem to have fixed my issue. I totally forgot about permissions. The download folder wasn't set to the right owner. A simple sudo chown -R user:user ~/downloads fixed it. If anyone runs into problems like this and you don't know where to start, it helps to check the qBittorrent logs (not printed by docker logs). The qBittorrent logs can be found in the config folder: /qBittorrent/data/logs/qbittorrent.log. Thanks Binhex for your wonderful containers!

I seem to have this problem where I cannot connect to peers. I made a video to easily show what happens: qBittorrent_peers_issue.mp4 I'm using PIA and here are the logs: https://pastebin.com/gTyE4AcZ. My machine is directly accessible through the internet so my LAN_NETWORK is set to 110.111.112.113/32, where this is of course an example IP. I checked the documentation and I think Q6 is about this. So I checked the whole answer, but only the first point is relevant: Incoming port not defined correctly. This seems the most likely cause, although the logs seem to say ports are open. If I check qBittorrent connection tab I see it's using port 22968. Docker tells me the following ports are opened: 0.0.0.0:6881->6881/tcp, 0.0.0.0:6881->6881/udp, 8080/tcp, 0.0.0.0:8118->8118/tcp. Port is open. See edit below. So I have no idea what's causing this. My docker-compose.yml looks like this: qbit: image: binhex/arch-qbittorrentvpn:latest container_name: qbit restart: always networks: - proxy cap_add: - NET_ADMIN ports: - 6881:6881 - 6881:6881/udp # - 8080:8080 - 8118:8118 volumes: - /etc/localtime:/etc/localtime:ro - ./qbittorrent:/config - /home/user/downloads/:/downloads environment: - VPN_ENABLED=yes - VPN_USER=$VPN_USERNAME - VPN_PASS=$VPN_PASSWORD - VPN_PROV=pia - STRICT_PORT_FORWARD=yes - ENABLE_PRIVOXY=no - LAN_NETWORK=110.111.112.113/32 - 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 #- ADDITIONAL_PORTS=1234 - DEBUG=false - WEBUI_PORT=8080 - UMASK=000 - PUID=$PUID - PGID=$PGID labels: - "traefik.enable=true" # HTTP Routers - "traefik.http.routers.qbittorrent-rtr.entrypoints=https" - "traefik.http.routers.qbittorrent-rtr.rule=Host(`qbit.$DOMAINNAME`)" - "traefik.http.routers.qbittorrent-rtr.tls=true" # Middlewares - "traefik.http.routers.qbittorrent-rtr.middlewares=chain-authelia-auth@file" # HTTP Services - "traefik.http.routers.qbittorrent-rtr.service=qbittorrent-svc" - "traefik.http.services.qbittorrent-svc.loadbalancer.server.port=8080" I cannot download anything right now, so please help me out! Edit: The port is open apparently! So that cannot be the issue:

I'll definitely give that a try. Sounds interesting.

That is very unfortunate to hear, but a small price to pay for the privacy it offers in return. Thank you for answering my questions!

That explains a lot. So redirecting from a different port wouldn't work either? Lets say "9724:58846"? Or would this also cause IP leakage? In that case I guess an SSH tunnel would solve it? Through the Thin client I can configure plugins which can't be configured through the WebUI. Also in my experience the WebUI isn't stable when I get to high download speeds (15-20 MB/s) or when I have 30-40 torrents running (mostly just passive seeding, not downloading). I reckon the Thin client will give me more stability.

Yeah I am. Although I'm running it on Ubuntu Server 16.04.

Interesting fact I think: when I try to check if port 58846 is open through this tool it says it's not open. But it says any other of my forwarded ports are open.

I tried all of these: admin@<IP>:58846 admin@<domain>:58846 remote@<IP>:58846 remote@<domain>:58846 No luck. It's just that I don't know where to start troubleshooting this.

I tried a couple of things here, but still no luck on this. Does it work for other people?

A shameless bump. Can someone point me in the right direction?

I still can't connect to deluge with the Thin client. I've searched and searched, but I don't know what I'm doing wrong. Can someone help me out? Firstly I followed this part of the official website. I added a new user (remote) to the /config/auth file: I checked if I could connect with it through deluge-console and if allow_remote is actually enabled: I also checked if the right port (58846) is open, and it is: But it's still not able to connect:

I want to connect to the Deluge GTK thin client but I'm not successful so far. I've setup deluge with a PIA VPN and I'm using a nginx reversed proxy to access the web UI. This works well but I need to configure some plugins which can only be configured through the thin client. My server is directly exposed to the internet and has a unique IP-address. For the purpose of this post I'll use the example 28.154.211.15. My docker compose file looks like this: deluge: image: binhex/arch-delugevpn container_name: deluge restart: on-failure cap_add: - NET_ADMIN ports: - "58846:58846" - "58946:58946" environment: - PUID=1000 - PGID=1000 - VPN_ENABLED=yes - VPN_USER=${VPN_USERNAME} - VPN_PASS=${VPN_PASSWORD} - VPN_REMOTE=nl.privateinternetaccess.com - VPN_PORT=1198 - VPN_PROTOCOL=udp - VPN_DEVICE_TYPE=tun - VPN_PROV=pia - STRONG_CERTS=no - ENABLE_PRIVOXY=no - STRICT_PORT_FORWARD=yes - LAN_NETWORK=28.154.211.15/32 - NAME_SERVERS=8.8.8.8,8.8.4.4 - DEBUG=false - UMASK=000 volumes: - /etc/localtime:/etc/localtime:ro - ${CONFIG_FOLDER}/Deluge:/config - ${MOUNT_POINT}/downloads:/data I can't connect to 28.154.211.15:58846 in the thin client. Is there something I've setup wrong? Should I setup nginx to let through all traffic? How would I do this?

Ah I got that wrong then. My bad. I've enabled Use Random Ports again, and it seems to go on expected speeds. The upload speed is Kib/s by the way: I just ran it through Google and got this result: I'll test it for a while to see if everything's alright now. Thanks for your help!

Thank you for your reply! I checked it thoroughly and it's still slow. Incoming port not defined correctly I added STRICT_PORT_FORWARD=yes to my docker-compose.yml. My server is specically located in east Germany so I changed to the Swiss VPN. Upload rate set too high/unlimited I did a speedtest to a speedtest.net server located in the same city as my server, and the upload is 264 Mbit/s. So I've set the upload speed in Deluge Web to 190000 Kib/s, which is about 195 Mbit/s, which again is 3/4 of the max upload, as instructed. Not sure if this is practically still too high? Rate limit overhead enabled (deluge specific) Allready unticked VPN endpoint has low bandwidth I changed from Switzerland to the Netherlands because they have more servers/bandwidth. Slightly faster, but still slow. Highly fragmented disk I have new enterprise HDD's, so shouldn't be a problem. Name Resolution not working I've set NAME_SERVERS=8.8.8.8,8.8.4.4 (Google) already. This is what my docker-compose.yml looks like. I've disabled Use Random Ports for incoming and outgoing and set a range manually in Deluge Web. That's why I added them to the ports sections of docker-compose.yml.

I'm using this on Ubuntu 16.04 server, and notice my torrents are downloading much slower compared to my home PC. The server is in Germany, and has a 1 Gbit/s down and up connection. My VPN (PIA) is set to the same country. When I start torrents it downloads it with a few MB/s. At home I have a 100 Mbit/s down and 30 Mbit/s upload connection. When I start the same torrents there it reaches the maximum download speed almost instantaniously, which is about 12 MB/s. I opened up the Deluge ports in the firewall of my server. The server hard drives are fine and can handle great speeds. What is holding it down?

Honestly I don't know, but other docker containers like sonarr or Plex run just fine. This is interesting. My server is stored in a data center and I'm running it headless. Running your curl command returns the Deluge Web UI HTML which suggests it's indeed something purely connectivity inbound. However just like other containers the ports should be open: Name Command State Ports ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- deluge /usr/bin/tini -- /bin/bash ... Up 0.0.0.0:44690->44690/tcp, 0.0.0.0:58846->58846/tcp, 0.0.0.0:58946->58946/tcp, 58946/udp, 0.0.0.0:8112->8112/tcp, 0.0.0.0:8118->8118/tcp jackett /init Up 0.0.0.0:9117->9117/tcp ombi /init Up 0.0.0.0:3579->3579/tcp plex /init Up 0.0.0.0:1900->1900/udp, 0.0.0.0:3005->3005/tcp, 0.0.0.0:32400->32400/tcp, 0.0.0.0:32410->32410/udp, 0.0.0.0:32412->32412/udp, 0.0.0.0:32413->32413/udp, 0.0.0.0:32414->32414/udp, 0.0.0.0:32469->32469/tcp, 0.0.0.0:8324->8324/tcp plexpy /init Up 0.0.0.0:8181->8181/tcp radarr /init Up 0.0.0.0:7878->7878/tcp sonarr /init Up 0.0.0.0:8989->8989/tcp

I tried http://<host ip>:8112 and http://<host ip>:8118. I do have to notice that it's a dedicated server directly exposed to the internet. For this reason I changed the IP address in the log. Not sure if that makes any difference.

Alright, did that and here it is: supervisord.log

By running ifconfig tun0 and seeing it return tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> lsmod: root@dedi-par-79211:/# lsmod Module Size Used by xt_mark 16384 4 iptable_mangle 16384 2 veth 16384 0 xt_nat 16384 67 xt_tcpudp 16384 129 ipt_MASQUERADE 16384 21 nf_nat_masquerade_ipv4 16384 1 ipt_MASQUERADE xfrm_user 32768 1 xfrm_algo 16384 1 xfrm_user iptable_nat 16384 13 nf_conntrack_ipv4 16384 3 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 nf_nat_ipv4 16384 1 iptable_nat xt_addrtype 16384 2 iptable_filter 16384 3 ip_tables 24576 3 iptable_filter,iptable_mangle,iptable_nat xt_conntrack 16384 2 x_tables 36864 9 xt_mark,ip_tables,xt_tcpudp,ipt_MASQUERADE,xt_conntrack,xt_nat,iptable_filter,iptable_mangle,xt_addrtype nf_nat 24576 3 nf_nat_ipv4,xt_nat,nf_nat_masquerade_ipv4 nf_conntrack 106496 5 nf_nat,nf_nat_ipv4,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4 br_netfilter 24576 0 bridge 126976 1 br_netfilter stp 16384 1 bridge llc 16384 2 stp,bridge aufs 217088 1336 ipmi_ssif 24576 0 gpio_ich 16384 0 intel_powerclamp 16384 0 coretemp 16384 0 kvm_intel 172032 0 kvm 544768 1 kvm_intel irqbypass 16384 1 kvm crct10dif_pclmul 16384 0 crc32_pclmul 16384 0 ghash_clmulni_intel 16384 0 aesni_intel 167936 0 aes_x86_64 20480 1 aesni_intel lrw 16384 1 aesni_intel gf128mul 16384 1 lrw glue_helper 16384 1 aesni_intel ablk_helper 16384 1 aesni_intel cryptd 20480 3 ghash_clmulni_intel,aesni_intel,ablk_helper joydev 20480 0 input_leds 16384 0 serio_raw 16384 0 lpc_ich 24576 0 i2c_ismt 20480 0 shpchp 36864 0 ipmi_si 57344 0 8250_fintek 16384 0 ipmi_msghandler 49152 2 ipmi_ssif,ipmi_si mac_hid 16384 0 autofs4 40960 2 hid_generic 16384 0 usbhid 49152 0 hid 118784 2 hid_generic,usbhid ast 61440 1 ttm 94208 1 ast drm_kms_helper 155648 1 ast syscopyarea 16384 1 drm_kms_helper sysfillrect 16384 1 drm_kms_helper igb 196608 0 sysimgblt 16384 1 drm_kms_helper fb_sys_fops 16384 1 drm_kms_helper dca 16384 1 igb drm 364544 4 ast,ttm,drm_kms_helper ptp 20480 1 igb pps_core 20480 1 ptp pata_acpi 16384 0 i2c_algo_bit 16384 2 ast,igb fjes 28672 0 lsmod in the container: root@dedi-par-79211:/# docker exec -it deluge lsmod Module Size Used by xt_mark 16384 4 iptable_mangle 16384 2 veth 16384 0 xt_nat 16384 67 xt_tcpudp 16384 129 ipt_MASQUERADE 16384 21 nf_nat_masquerade_ipv4 16384 1 ipt_MASQUERADE xfrm_user 32768 1 xfrm_algo 16384 1 xfrm_user iptable_nat 16384 13 nf_conntrack_ipv4 16384 3 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 nf_nat_ipv4 16384 1 iptable_nat xt_addrtype 16384 2 iptable_filter 16384 3 ip_tables 24576 3 iptable_filter,iptable_mangle,iptable_nat xt_conntrack 16384 2 x_tables 36864 9 xt_mark,ip_tables,xt_tcpudp,ipt_MASQUERADE,xt_conntrack,xt_nat,iptable_filter,iptable_mangle,xt_addrtype nf_nat 24576 3 nf_nat_ipv4,xt_nat,nf_nat_masquerade_ipv4 nf_conntrack 106496 5 nf_nat,nf_nat_ipv4,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4 br_netfilter 24576 0 bridge 126976 1 br_netfilter stp 16384 1 bridge llc 16384 2 stp,bridge aufs 217088 1342 ipmi_ssif 24576 0 gpio_ich 16384 0 intel_powerclamp 16384 0 coretemp 16384 0 kvm_intel 172032 0 kvm 544768 1 kvm_intel irqbypass 16384 1 kvm crct10dif_pclmul 16384 0 crc32_pclmul 16384 0 ghash_clmulni_intel 16384 0 aesni_intel 167936 0 aes_x86_64 20480 1 aesni_intel lrw 16384 1 aesni_intel gf128mul 16384 1 lrw glue_helper 16384 1 aesni_intel ablk_helper 16384 1 aesni_intel cryptd 20480 3 ghash_clmulni_intel,aesni_intel,ablk_helper joydev 20480 0 input_leds 16384 0 serio_raw 16384 0 lpc_ich 24576 0 i2c_ismt 20480 0 shpchp 36864 0 ipmi_si 57344 0 8250_fintek 16384 0 ipmi_msghandler 49152 2 ipmi_ssif,ipmi_si mac_hid 16384 0 autofs4 40960 2 hid_generic 16384 0 usbhid 49152 0 hid 118784 2 hid_generic,usbhid ast 61440 1 ttm 94208 1 ast drm_kms_helper 155648 1 ast syscopyarea 16384 1 drm_kms_helper sysfillrect 16384 1 drm_kms_helper igb 196608 0 sysimgblt 16384 1 drm_kms_helper fb_sys_fops 16384 1 drm_kms_helper dca 16384 1 igb drm 364544 4 ast,ttm,drm_kms_helper ptp 20480 1 igb pps_core 20480 1 ptp pata_acpi 16384 0 i2c_algo_bit 16384 2 ast,igb fjes 28672 0 I might be stating the obvious, but I'm in no way an expert on linux networking. I've been trying to figure this out for a week, also by looking into tun/tap modules. But not getting anywhere so far. If it's not something related to your docker images (which I know is likely) I just hope anyone can point me in the right direction.

The tun module is there inside the container, and also outside the container, both up and running. I don't see what else needs to change. I made a temporary workaround with a nginx proxy in a seperate container: events { worker_connections 1024; } http { server { listen 8112; location / { proxy_pass http://deluge:8112; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # HTTP 1.1 support proxy_http_version 1.1; proxy_set_header Connection ""; } } }

I'm still trying to figure out why deluge is not running for me. Some errors I can't seem to solve: 2017-04-30 12:45:25,073 DEBG 'start-script' stdout output: [warn] 'tun' kernel module not available, you will not be able to establish a VPN tunnel [info] unRAID users: Please attempt to load the module by executing the following on your host:- '/sbin/modprobe tun' [info] Ubuntu users: Please attempt to load the module by executing the following on your host:- '/sbin/modprobe tun' [info] Synology users: Please attempt to load the module by executing the following on your host:- 'insmod /lib/modules/tun.ko' I'm on a Ubuntu server 16.04. Running /sbin/modprobe tun doesn't return anything. And I'm also getting this: 2017-04-30 12:45:32,556 DEBG 'deluge-script' stdout output: [info] Attempting to start Deluge... 2017-04-30 12:45:33,259 DEBG 'deluge-script' stdout output: [warn] Deluge config file /config/core.conf does not contain valid data, exiting Python script config_deluge.py... 2017-04-30 12:45:34,362 DEBG 'deluge-script' stderr output: Traceback (most recent call last): File "/usr/bin/deluged", line 11, in <module> load_entry_point('deluge==1.3.14', 'console_scripts', 'deluged')() File "/usr/lib/python2.7/site-packages/deluge/main.py", line 194, in start_daemon 2017-04-30 12:45:34,363 DEBG 'deluge-script' stderr output: deluge.log.setupLogger(level=options.loglevel, filename=options.logfile) File "/usr/lib/python2.7/site-packages/deluge/log.py", line 65, in setupLogger filemode=filemode File "/usr/lib/python2.7/logging/__init__.py", line 1547, in basicConfig hdlr = FileHandler(filename, mode) File "/usr/lib/python2.7/logging/__init__.py", line 913, in __init__ StreamHandler.__init__(self, self._open()) File "/usr/lib/python2.7/logging/__init__.py", line 943, in _open stream = open(self.baseFilename, self.mode) IOError: [Errno 13] Permission denied: '/config/deluged.log' See the attachment for logs: supervisord.log Edit: I did a clean install and the permission problems are gone. I also tried installing a tunnel in my server environment through openvpn with openvpn --mktun --dev tun0 followed by ifconfig tun0 up but I still can't access the WebGUI.