Can't access container webui in bridge mode, only host mode

General Discussions General
1

I’m using docker-compose UI on omv7.
docker-ce 5:27.0.3-1~debian.12~bookworm
docker-compose-plugin 2.28.1-1~debian.12~bookworm

I installed plex from dockerhub,(https://hub.docker.com/r/linuxserver/plex) and it runs no problem. It is by default configured to run in host mode. I can access the webui etc. without any problems.

Then I tried installing qbittorrent (https://hub.docker.com/r/linuxserver/qbittorrent) and it by default runs on the default docker bridge network. I am completely unable to access the webui. I created a user bridge (only giving it a name and letting docket give it a subnet etc) and again I was unable to access it via webui. When I threw my hands up and put qbittorrent into host mode - viola I can access it.

Here are both the default bridge and user defined bridge inspects…

root@omv:~# docker inspect bridge
[
    {
        "Name": "bridge",
        "Id": "aa3a6b37fe01161180a6be10b7cff7cf4a08aa284422664602b8e36cb1faf60f",
        "Created": "2024-07-18T20:49:29.072176834-05:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "40d3bcb43ecfabfa21bf20a71cea28e38e18d8fdea395ad0e083e8dd8b9db6ef": {
                "Name": "qbittorrent",
                "EndpointID": "53dff696157f96eb57210e80c5a91eb35c12b4e4059156f2fd22bfdbcbdd2c1e",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

root@omv:~# docker inspect my-net
[
    {
        "Name": "my-net",
        "Id": "14f5e64c3df5816a9a817c9f83b95252a5a26cbeba9ce87b2d77f1ef4d802435",
        "Created": "2024-07-19T13:37:00.310192499-05:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "e4ad8a5eb94258d73a0a3aea4e015dcc29ad6a3155c82d4f0a7128d6c868463d": {
                "Name": "qbittorrent",
                "EndpointID": "a617f6acd73159c223ad350bfb86d113b099f9982dcf243a47b6d60b68af3549",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }
]

What is going on where I cannot access webui in bridge mode but can in host mode?

Also from the host machine, I cannot ping or curl the ip assigned to the qbittorrent container in bridge network.

Much thanks inadvance for help figuring this out!

2

it appears to be an abysmally difficult network problem I am unable to solve but here’s what I attempted today:

First, my network adapters:

root@omv:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:1e:06:49:05:46 brd ff:ff:ff:ff:ff:ff
3: br-14f5e64c3df5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
    link/ether 02:42:f0:b6:e0:fb brd ff:ff:ff:ff:ff:ff
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
    link/ether 02:42:1e:da:26:c4 brd ff:ff:ff:ff:ff:ff
6: veth21d8c5a@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 9a:0b:06:a5:2e:cb brd ff:ff:ff:ff:ff:ff link-netnsid 0

Now an attempt to reset networking and try pinging the container.

root@omv:~# sudo iptables -F INPUT
root@omv:~# sudo iptables -F OUTPUT
root@omv:~# sudo iptables -P INPUT ACCEPT
root@omv:~# sudo iptables -P OUTPUT ACCEPT
root@omv:~# sudo systemctl restart systemd-networkd
root@omv:~# ping 172.18.0.2
PING 172.18.0.2 (172.18.0.2): 56 data bytes
36 bytes from ae19.cr8-dal3.ip4.gtt.net (65.175.1.41): Destination Net Unreachable

PING 192.168.50.134 (192.168.50.134): 56 data bytes
64 bytes from 192.168.50.134: icmp_seq=0 ttl=128 time=3.056 ms

For some bizarre reason, trying to ping the container attempts to resolve to the internet as if the container is invisible to my system? Then I pinged a machine on the local network and that works as expected. I can ping anything and everything except docker containers?!

I’m in way over my knowledge level. I would really appreciate help.

Thank you

3

I reset network adapter using omv-firstaid, deleted and reinstalled adapter within omv without applying in between. Stopped containers, deleted bridge network, cleared docker cache, reinstalled docker from gui, recreated bridge network and re-started qbittorrent.

I can now ping the bridge network but the container says host is unreachable. I feel like I’m closer but still missing the final thing to make the container reachable.

4

When you use host mode, there is no network isolation. If you run without, you need to open the ports: to be able to connect from outside of Docker network.

5

I am using the docker hub linux.io qbittorrent image with the ports in the docker compose file from here:

https://hub.docker.com/r/linuxserver/qbittorrent

6

That’s just an image, but there are a hundred ways to start it. You need to share more info, like your compose file.

7

Using the default image and only changing the paths (to use qbittorrent_default bridge network):

---
services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - WEBUI_PORT=8080
      - TORRENTING_PORT=6881
    volumes:
      - ./config:/config
      - /srv/dev-disk-by-uuid-30ff5511-3b43-41cb-bd13-381d590402c5/downloads:/downloads
    ports:
      - 8080:8080
      - 6881:6881
      - 6881:6881/udp
    restart: unless-stopped

Using custom bridge network:

---
networks:
  my-net:
    external: true
services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    networks:
      my-net:
    environment:
      - PUID=1001
      - PGID=100
      - TZ=America/Chicago
      - WEBUI_PORT=8080
      - TORRENTING_PORT=6881
    volumes:
      - ./config:/config
      - /srv/dev-disk-by-uuid-30ff5511-3b43-41cb-bd13-381d590402c5/downloads:/downloads
    ports:
      - 8080:8080
      - 6881:6881
      - 6881:6881/udp
    restart: unless-stopped

host mode (the only one where I can both ping the container & access its webgui):

---
services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: host
    environment:
      - PUID=1001
      - PGID=100
      - TZ=America/Chicago
      - WEBUI_PORT=8080
      - TORRENTING_PORT=6881
    volumes:
      - ./config:/config
      - /srv/dev-disk-by-uuid-30ff5511-3b43-41cb-bd13-381d590402c5/downloads:/downloads
    ports:
      - 8080:8080
      - 6881:6881
      - 6881:6881/udp
    restart: unless-stopped

default docker0 bridge:

---
services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: bridge
    environment:
      - PUID=1001
      - PGID=100
      - TZ=America/Chicago
      - WEBUI_PORT=8080
      - TORRENTING_PORT=6881
    volumes:
      - ./config:/config
      - /srv/dev-disk-by-uuid-30ff5511-3b43-41cb-bd13-381d590402c5/downloads:/downloads
    ports:
      - 8080:8080
      - 6881:6881
      - 6881:6881/udp
    restart: unless-stopped

In host mode the result is obvious and works. In the bridge modes, when I inspect the network I can see (for example) the bridge network at 172.17.0.1 (for docker0) and can ping it but cannot ping the container at 172.17.0.2.

I just discovered by entering into the container via docker exec -t -i qbittorrent /bin/bash, i cannot ping out to the internet, or my router, or even the host ip that docker is running on or even the bridge network that the container is running in (172.17.0.1) yikes. The container has no networking ability. What causes this and how do I make a permanent fix?

8

Have you actually tried to identify whether this is a problem of the image, or your docker installation?

  1. test: access nginx through published port on user defined bridge → curl http://localhost:8080
---
services:
  test_userdefined_bridge:
    image: nginx:latest
    ports:
      - 8080:80
  1. test: access nginx through bound host port → curl http://localhost:80
---
services:
  test_host:
    image: nginx:latest
    network_mode: host
  1. test: access nginx through published port on default bridge → curl http://localhost:8080
---
services:
  test_default_bridge:
    image: nginx:latest
    network_mode: bridge
    ports:
      - 8080:80

I expect all three variants to work like a charm.
If I am right, then you need to wait until someone who actually uses qbittorennt comes around, or you raise an issue in their github repo’s issue board.

9

Thanks for chiming in! Here’s the results:

  1. just hangs until I ctrl-c
  2. can’t run as I have OMV installed on the system which runs on ngnix at port 80
  3. root@omv:~# curl: (56) Recv failure: Connection reset by peer

I have been searching online like crazy and discovered this:

docker exec -t -i qbittorrent /bin/bash

cat /etc/resolv.conf

# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

nameserver 1.0.0.1
nameserver 192.168.50.1
search .

It says docker generates this from my system however my /etc/resolv.conf contains (removed comment lines):

main /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search .

Note: 192.168.50.1 as seen in the container resolv.conf is actually the address of my router.

Can this be what is killing me? How is docker coming up with addresses that are not in my systemwide settings?

10

If neither the first, nor the third command worked for you, then indeed something must be wrong.

I wrote about the ip you see here: Various problems, but I think it relates to either DNS or Docker sock being inaccessible - #4 by meyay

Please share the output of docker info.

11

Ok here’s the output:

Client: Docker Engine - Community
 Version:    27.0.3
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.15.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.28.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 3
 Server Version: 27.0.3
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 2bf793ef6dc9a18e00cb12efb64355c2c9d5eb41
 runc version: v1.1.13-0-g58aa920
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.6.40-current-meson64
 Operating System: Armbian_community 24.8.0-trunk.369 bookworm
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 3.693GiB
 Name: omv
 ID: 9b234c68-026d-46ff-995c-66ed86d3f7a3
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
12

Thank you for sharing the output. There is nothing unusual: latest docker-ce with overlay2 storage driver on an aarch64 architecture cpu.

Maybe the problem with unreachable published ports is related to nftables? See: https://github.com/moby/moby/issues/46147#issuecomment-1662846289

13

I did a complete reinstall of Armbian and openmediavault (NAS with ngix interface) with the docker plugins and finally got to where the resolv.conf matches up but still weird behavior ensues (e.g. can’t access webgui, or ping container. container can resolve dns to google but not actually reach it? container can ping itself and 127.0.0.11 but cannot ping its own bridge network omg).

docker exec -t -i qbittorrent /bin/bash
root@9b19b78338c4:/# cat /etc/resolv.conf

nameserver 127.0.0.11
search .
options edns0 trust-ad ndots:0


root@omv:~# cat /etc/resolv.conf

main /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search .

I was hoping a scratch install would fix it. would nftables still be a possible cause with this resolv.conf having been fixed?

14

by the way, when I enter the container I can now curl http://localhost:8080 and pull the html
of course from outside of the container I cannot :frowning:

15

I’m also stuck with the same issue with docker installed part of OMV7 on Armbian OS (24.11) powered arm64 hardware. Did you find any solution for this issue @fscii ?