crazy-max / docker-rtorrent-rutorrent

rTorrent and ruTorrent Docker image
MIT License
483 stars 107 forks source link

Unable to use dockers `--network` option without errors #184

Closed martinjuhasz closed 1 year ago

martinjuhasz commented 2 years ago

Support guidelines

I've found a bug and checked that ...

Description

I want to use this docker container behind anothers containers network. Therefore i use dockers --network=container:othercontainer when running crazymax/rtorrent-rutorrent.

Expected behaviour

Everything should still work fine even if no ports are exposed or the container itself runs inside another containers network.

Actual behaviour

I'm unable to access the webinterface since rtorrent seems to be unable to bind the needed ports (see logs). Obviously, with --network option i do not expose any ports and i'm not running anthing on 8000 either (althouth that shoudn't matter on the host). If i remove the option, everything works fine.

Steps to reproduce

docker run --network=container:somecontainer crazymax/rtorrent-rutorrent

Docker info

Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 42
  Running: 31
  Paused: 0
  Stopped: 11
 Images: 58
 Server Version: 20.10.14
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3df54a852345ae127d1fa3092b95168e4a88e2f8
 runc version: v1.0.3-0-gf46b6ba2
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.15.46-Unraid
 Operating System: Slackware 15.0 x86_64
 OSType: linux
 Architecture: x86_64
 CPUs: 24
 Total Memory: 31.4GiB
 Name: Winston
 ID: VGZM:MTOE:LAON:MNVZ:RW2T:WHQJ:D4UC:KJEL:RNU6:JXAX:JX6E:N4VL
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

Version

No docker compose

Linux Winston 5.15.46-Unraid #1 SMP Fri Jun 10 11:08:41 PDT 2022 x86_64 Intel(R) Xeon(R) CPU X5675 @ 3.07GHz GenuineIntel GNU/Linux

Docker compose

no docker compose

Container logs

2022/09/09 23:47:12 [notice] 584#584: try again to bind() after 500ms 2022/09/09 23:47:12 [emerg] 584#584: bind() to 0.0.0.0:8000 failed (98: Address in use) nginx: [emerg] bind() to 0.0.0.0:8000 failed (98: Address in use)

Additional info

No response

Kuchiru commented 1 year ago

Running into the same situation, wondering if there is some workaround for this?

martinjuhasz commented 1 year ago

@Kuchiru not for me, i switched to qbit

Kuchiru commented 1 year ago

@Kuchiru not for me, i switched to qbit

I thought this might be resolvable with a firewall container though i have yet to try.

amwalters commented 1 year ago

I was having this issue but managed to get it working and am now running via a gluetun docker vpn network.

If you are placing this behind gluetun, the gluetun container by default has its http control server on port 8000. You need to either change your XMLRPC port, or change the gluetun control server port or you get the above error. For some reason, I could not get the XMLRPC port to change with this container. It was still using port 8000 in the /etc/nginx/conf.d/rpc.conf file despite setting XMLRPC_PORT to another.

I solved it by moving the gluetun http control server to a different port.