Docker Community Forums

Share and learn in the Docker community.

Bridge connection not working

Hello,

Recently I discovered that there is no network connection inside my docker container. When I issue command

docker run -it --rm ubuntu:latest bash

and than apt update, the system cannot download updates of Ubuntu repositories.

The only way to make it connect to the internet is use the option

–net=host

while the default (or ) --net=brigde is not working. I use docker-related software which relies on the bridge.

Could you help me to resolve this issue?

Please find the outputs of related commands below:

Output of uname -a:

Linux sabayon.local 5.1.0-sabayon #1 SMP Fri Jun 21 21:04:45 UTC 2019 x86_64 Intel® Core™ i7-4500U CPU @ 1.80GHz GenuineIntel GNU/Linux

Output of docker info:

Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 4
Server Version: 18.09.5
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: bb71b10fd8f58240ca47fbb579b9d1028eea7c84
runc version: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
init version: fec3683b971d9c3ef73f284f176672c44b448662
Security Options:
seccomp
Profile: default
Kernel Version: 5.0.0-sabayon
Operating System: Sabayon/Linux
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.67GiB
Name: sabayon.local
ID: OMZA:X4ME:Z7MR:4GES:H5WR:ECXM:TZAG:4RQ3:A7LY:HASG:AXWZ:57A7
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

Output of docker network inspect bridge
[
{
“Name”: “bridge”,
“Id”: “7d11cbdf0fded75326e58e6b488279c87e832003f2a7d200cddc32631a5bf4b4”,
“Created”: “2019-06-29T00:06:13.632725228+02: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”: {
“fc961e0e574395dea0bff6ab94410fb77c3e89a72e12599b26d5f92e55b05e1d”: {
“Name”: “alidock-1000”,
“EndpointID”: “5827a6ce7ab57f5ff88bd3d55c133404dc20e895acbad900062dedac97cf29e8”,
“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”: {}
}
]

1 Like

Same problem, Centos. Firewall and Selinux disabled.

No internet connection in bridge mode, internet works only with option –net=host

Find any solution?

When you no longer need a bridge connection, select one or all the participating network adapters, and select Remove from Bridge. At this point, the bridge adapter should disappear from Network Connections, but if it doesn’t, simply reboot your computer. … Right-click the network adapter and select Properties.

Hello, I use the bridge connection with my applications.

I needed a quick solution of the problem so I resolved it by reinstalling the whole system.

The system was too old and probably there was some collision between the network interfaces.

In my case it was centos7 and systemd network and disabled ip forwarding in my network interface

Solve it adding

IPForward=ipv4

To /etc/systemd/network/XX-eth0.network

Hi…In the event that we attempt to interface with the setup worker on localhost, the customer will sidestep systems administration and endeavor to associate with the worker utilizing an attachment record in the nearby filesystem. In any case, this doesn’t work when MariaDB is running inside a holder in light of the fact that the worker’s filesystem is detached from the host. The customer can’t get to the attachment record which is inside the holder, so it neglects to interface.

In this way associations with the setup worker must be made utilizing TCP, in any event, when the customer is running on a similar machine as the worker holder.

judging by gerriheft’s response, one could think that we finaly have a second lewish95 now… or a rew account for the “let me google this for you” bot.

The response is completly unrelated…