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: