My docker container has no internet

Question

I had it working allright but now it stopped. I tried the following commands with no avail:

docker run -dns 8.8.8.8 base ping google.com

docker run base ping google.com

sysctl -w net.ipv4.ip_forward=1 - both on the host and on the container

All I get is unknown host google.com. Docker version 0.7.0

Any ideas?

P.S. ufw disabled as well

Answer 1

Fixed by following this advice (as the root user):

[...] can you try to reset everything?

pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
systemctl restart docker

It will force docker to recreate the bridge and reinit all the network rules

https://github.com/dotcloud/docker/issues/866#issuecomment-19218300

Seems the interface was 'hung' somehow.

Update for more recent versions of docker:

on more usual 2025 hosts (debian, arch)

(stop the daemon, equivalent to pkill)
# systemctl stop docker.socket (or docker.service)
(remove the firewall rules docker added, equivalent to iptables. Note: if you know how to use wildcards with nft, fix here)
# nft delete chain ip6 nat DOCKER
# nft delete chain ip6 filter FORWARD
# nft delete chain ip6 filter DOCKER-USER
# nft delete chain ip6 filter DOCKER
# nft delete chain ip6 filter DOCKER-ISOLATION-STAGE-1
# nft delete chain ip6 filter DOCKER-ISOLATION-STAGE-2
# nft delete chain ip nat DOCKER
# nft delete chain ip filter FORWARD
# nft delete chain ip filter DOCKER-USER
# nft delete chain ip filter DOCKER
# nft delete chain ip filter DOCKER-ISOLATION-STAGE-1
# nft delete chain ip filter DOCKER-ISOLATION-STAGE-2
(bring down docker virtual network interface. same as before with ifconfig or)
# ip link set docker0 down
(remove the interface)
# ip link del docker0
# systemctl daemon-reload && systemctl restart docker.socket (or docker.service)

For more networking details see https://unix.stackexchange.com/questions/657545/nftables-whitelisting-docker

Answer 2

Tried all answers, none worked for me.

After trying everything else I could find, this did the trick:

sudo reboot

Answer 3

The presence of NOTRACK rules in raw may have an effect

-A PREROUTING -p tcp -j NOTRACK 
-A OUTPUT -p tcp -j NOTRACK

If they are present, it is worth removing or adjusting them

Answer 4

In my case it was MTU. Spent almost 2 days after it. the network mtu of "eth0" (network of the host, can be "eno1" as well depending on your host) was set to 1280 and the mtu of "docker0" (docker network) was set to 1400.

Run the following command to find out the mtu of each network on your system

nmcli dev show 

"nmcli" is the command line network manager on ubuntu. This will show something like this

GENERAL.DEVICE:                         docker0
GENERAL.TYPE:                           bridge
GENERAL.HWADDR:                         02:42:87:65:3D:1B
GENERAL.MTU:                            1400
GENERAL.STATE:                          10 (unmanaged)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
IP4.ADDRESS[1]:                         172.17.0.1/16
IP4.GATEWAY:                            --
IP4.ROUTE[1]:                           dst = 172.17.0.0/16, nh = 0.0.0.0, mt = 0
IP6.GATEWAY:                            --

GENERAL.DEVICE:                         eno1
GENERAL.TYPE:                           ethernet
GENERAL.HWADDR:                         54:9F:35:00:16:2C
GENERAL.MTU:                            1280
GENERAL.STATE:                          10 (unmanaged)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
WIRED-PROPERTIES.CARRIER:               on
IP4.ADDRESS[1]:                         192.168.10.125/24
IP4.GATEWAY:                            192.168.10.1
IP4.ROUTE[1]:                           dst = 192.168.10.0/24, nh = 0.0.0.0, mt = 100
IP4.ROUTE[2]:                           dst = 192.168.10.1/32, nh = 0.0.0.0, mt = 100
IP4.ROUTE[3]:                           dst = 0.0.0.0/0, nh = 192.168.10.1, mt = 100
IP4.ROUTE[4]:                           dst = 8.8.8.8/32, nh = 192.168.10.1, mt = 100
IP4.ROUTE[5]:                           dst = 8.8.4.4/32, nh = 192.168.10.1, mt = 100
IP6.ADDRESS[1]:                         fe80::569f:35ff:fe00:162c/64
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = fe80::/64, nh = ::, mt = 256

The rule is that the mtu of docker network should be lower than the host network. I set docker0 mtu to 1200 and it started working.

in /etc/docker/daemon.json

{
    "dns":["8.8.8.8","8.8.4.4"],
    "mtu": 1200
}

I also added dns configuration in it just for a failsafe.

Answer 5

If you're running Docker rootless and facing this issue, during its installation, iptables may not be configured properly, mainly because of using --skip-iptables option when Docker complained about iptables:

[ERROR] Missing system requirements. Run the following commands to
[ERROR] install the requirements and run this tool again.
[ERROR] Alternatively iptables checks can be disabled with --skip-iptables .

########## BEGIN ##########
sudo sh -eux <<EOF
# Load ip_tables module
modprobe ip_tables
EOF
########## END ##########

Let's check if this is the issue: is ip_tables kernel module loaded?

sudo modprobe ip_tables

If there is no output, this answer might not help you (you could try anyway). Otherwise, the output's something like this:

modprobe: FATAL: Module ip_tables not found in directory /lib/modules/5.18.9-200.fc36.x86_64

Let's fix it!

First, uninstall Docker rootless (no need to stop the service via systemctl, the script handles that):

dockerd-rootless-setuptool.sh uninstall --skip-iptables

Ensure iptables package is installed, although it's shipped by default by major distributions.

Now, make ip_tables module visible to modprobe and install it (thanks to this):

sudo depmod
sudo modprobe ip_tables

Now, re-install Docker rootless:

dockerd-rootless-setuptool.sh install

If it doesn't bother about iptables, you're done and problem should be fixed. Don't forget to enable the service (i.e. systemctl enable --user --now docker)!

Answer 6

I just solve that problem, my container $container didn't have internet connection but it wasn't nothing to do with DNS because not even ping 8.8.8.8 was working. For a unknown reason the traffic of the container wasn't forwarding to my physical gateway so it wasn't out of my host/PC. So, I just add a masquerade rule for NAT:

1. Get virtual container bridge name:

network_name=$(docker inspect --format '{{ range $key, $value := .NetworkSettings.Networks }}{{ $key }}{{ end }}' $container)
etwork_id=$(docker network inspect -f {{.Id}} $network_name)
bridge_name="br-${network_id:0:12}"

2. Obtain IP network address of the virtual bridge:

IP=$(ip addr show $bridge_name | grep 'inet ' | awk '{print $2}')   

3. Masquerade all outgoing traffic from the $IP subnet:

sudo iptables -t nat -A POSTROUTING ! -o $bridge_name -s $IP -j MASQUERADE

4. Check it:

user@host:~$ docker exec -u 0 -it $container /bin/bash 
root@772bc683889a:/var/www/html# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=9.50 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=4.98 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.979/8.850/12.070/2.931 m

Answer 7

I encountered this issue, it turned out to be the Docker + iptables conflict when the networking was set to host. The host could be using the newer nftables whereas Docker could still be using the iptables-legacy. This GitHub issue issues to explain the problem. Additionally, our setup was Docker-in-Docker where the container inside the container had no internet.

Verify if you have this issue

Run the following commands in your container to verify if this is the case:

ping google.com  # Should fail since your container will have no internet
iptables -L
iptables-legacy -L 

If the Docker rules are not present in iptables -L command output, then the conflict exists and we need to solve it.

Solutions

Using update-alternatives to switch to iptables-legacy which would also be available in your distribution: https://wiki.debian.org/iptables#Current_status

Be sure to restart Docker after changing to iptables-legacy for this work,

update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

Alternative tips

1. If you are having this problem while building a Docker-in-Docker container then an easy workaround is to build using --network=host.

2. Bash solution to solve the conflict: https://github.com/garutilorenzo/iptables-docker if nothing works. Haven't tried, let me know if this worked for you.

Answer 8

As we know, the default bridge is built on a different docker0 interface and its IP is different from the main IP of the system.

To access the Internet, after reaching the gateway related to docker0, the packet must follow the path from the main gateway of the system, but this packet transfer is not possible because in the Arch operating system has a package that installed along with Docker that controls the connections, the name of this package is nftables.

To solve the problem I did this (You can have better settings for nftables):

1- First, I ran sudo vim /etc/nftables.conf and opened the configuration file

2- In the section below, I changed the chain forward and allow access for docker0 interface (thanks to @Lenar Hoyt).

chain forward {
    type filter hook forward priority filter
    policy drop
    
    ct state { established, related } accept
    ct state invalid drop
    iif docker0 accept
  }

3- In the last step, we execute these two commands

sudo systemctl restart nftables
sudo systemctl restart docker

Answer 9

For me iwas facing the same issue as user of redhat/centos/fedora using podman

firewall-cmd --zone=public --add-masquerade
firewall-cmd --permanent --zone=public --add-masquerade

for more firewalld and podman (or docker) – no internet in the container and could not resolve host

Answer 10

The only thing that works on my computer (which 8.8.8.8 didn't work)

1. find out the dns used in your local machine:

$ netstat -ntpl | grep :53
tcp        0      0 10.194.128.1:53         0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      -
tcp        0      0 192.168.122.1:53        0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.2.1:53            0.0.0.0:*               LISTEN      -

2. modify your docker config sudo vim /etc/docker/daemon.json based on the information above on your own computer

{
  "dns": ["192.168.122.1","10.194.128.1"]
}

3. restart docker

sudo ip link delete docker0
sudo systemctl restart docker

Answer 11

In my case, for some unknown reason, docker was configured (by someone else) to not generate the iptables rules containers need for networking. The docker container could only ping the host, nothing else. Most answers here did not help; recreating the bridge nor restarting the service changed anything.

But then, by pure chance, I found the following:

$ cat /etc/docker/daemon.json
{"iptables": false}

I deleted the file /etc/docker/daemon.json and restarted the daemon (default is to create the iptables rules). This solved the networking problem.

Below, the iptables rules before the fix:

$ iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Now, the iptables rules after the fix:

$ iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  0.0.0.0/0            0.0.0.0/0
DOCKER-ISOLATION-STAGE-1  all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (2 references)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            172.17.0.2           tcp dpt:8443

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination
DOCKER-ISOLATION-STAGE-2  all  --  0.0.0.0/0            0.0.0.0/0
DOCKER-ISOLATION-STAGE-2  all  --  0.0.0.0/0            0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination
DROP       all  --  0.0.0.0/0            0.0.0.0/0
DROP       all  --  0.0.0.0/0            0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-USER (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Answer 12

it help me:

sudo ip link delete docker0
sudo systemctl stop docker.socket
sudo systemctl stop docker.service

sudo systemctl start docker.socket
sudo systemctl start docker.service

NOTE: after this, interface docker0 must have ip adress smth like that:

inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

Answer 13

I am on Arch Linux and after trying all the above answers I realized that I had a firewall enabled in my machine, nftables, and disabling it did the trick. I did :

sudo systemctl disable nftables
sudo systemctl stop nftables
sudo reboot

My network cards:

➜  ~ ip link
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: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
    link/ether 68:f7:28:84:e7:fe brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether d0:7e:35:d2:42:6d brd ff:ff:ff:ff:ff:ff
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:43:3f:ff:94 brd ff:ff:ff:ff:ff:ff
5: br-c51881f83e32: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:ae:34:49:c3 brd ff:ff:ff:ff:ff:ff
6: br-c5b2a1d25a86: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:72:d3:6f:4d brd ff:ff:ff:ff:ff:ff
8: veth56f42a2@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether 8e:70:36:10:4e:83 brd ff:ff:ff:ff:ff:ff link-netnsid 0

and my firewal configuration, /etc/nftables.conf, which I now disabled and will futurely try to improve so I can have the docker0 network card rules setup correctly:

#!/usr/bin/nft -f
# vim:set ts=2 sw=2 et:

# IPv4/IPv6 Simple & Safe firewall ruleset.
# More examples in /usr/share/nftables/ and /usr/share/doc/nftables/examples/.

table inet filter
delete table inet filter
table inet filter {
  chain input {
    type filter hook input priority filter
    policy drop

    ct state invalid drop comment "early drop of invalid connections"
    ct state {established, related} accept comment "allow tracked connections"
    iifname lo accept comment "allow from loopback"
    ip protocol icmp accept comment "allow icmp"
    meta l4proto ipv6-icmp accept comment "allow icmp v6"
    #tcp dport ssh accept comment "allow sshd"
    pkttype host limit rate 5/second counter reject with icmpx type admin-prohibited
    counter
  }
  chain forward {
    type filter hook forward priority filter
    policy drop
  }

Answer 14

After struggling for hours I finally solved my problem

The issue was of linux using old version of libseccomp2

Get signing keys to verify the new packages, otherwise they will not install

rpi ~$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138

Add the Buster backport repository to apt sources.list

rpi ~$ echo 'deb http://httpredir.debian.org/debian buster-backports main contrib non-free' | sudo tee -a /etc/apt/sources.list.d/debian-backports.list

rpi ~$ sudo apt update
rpi ~$ sudo apt install libseccomp2 -t buster-backports

After this try

rpi ~$ docker run -it --rm alpine:3.15.0
(alpine shell)# apk update

apk update will fetch and hence your are connected to internet

I was using

Linux raspberrypi 5.10.63-v7l+ #1496 SMP Wed Dec 1 15:58:56 GMT 2021 armv7l GNU/Linux

you may check using uname -a

Answer 15

The intended way to restart docker is not to do it manually but use the service or systemctl command:

service docker restart

or

systemctl restart docker

Answer 16

I've tried most answers in here, but the only thing that worked was re-creating the network:

$ docker network rm the-network
$ docker network create --driver=bridge the-network

I also needed to re-create the docker container that used it:

$ sudo docker create --name the-name --network the-network

Then it started with internet access.

Answer 17

Other answers have stated that the docker0 interface (bridge) can be the source of the problem. On Ubuntu 20.04 I observed that the interface was missing its IP address (to be checked with ip addr show dev docker0). Restarting Docker alone did not help. I had to delete the bridge interface manually.

sudo ip link delete docker0
sudo systemctl restart docker

Answer 18

There are lot of good answer already. I faced similar problem in my orange pi pc running armbian recently. Docker container was blocked to internet. This command solve the problem in my case. So I like to share it

docker run --security-opt seccomp=unconfined imageName

Answer 19

Sharing a simple and working solution for posterity. When we run a docker container without explicitly mentioning the --network flag, it connects to its default bridge network which prohibits connecting to the outside world. To resolve this issue, we have to create our own bridge network(user-defined bridge) and have to explicitly mention it with the docker run command.

docker network create --driver bridge mynetwork
docker run -it --network mynetwork image:version

Answer 20

On centos 8, My problem was that I did not install & start iptables before starting docker service. Make sure iptables service is up and running before you start docker service.

Answer 21

for me, using centos 7.4, it was not issue of /etc/resolve.conf, iptables, iptables nat rules nor docker itself. The issue is the host missing the package bridge-utils which docker require to build the bridge using command brctl. yum install -y bridge-utils and restart docker, solve the problem.

Answer 22

for me, my problem was because of iptables-services was not installed, this worked for me (CentOS):

sudo yum install iptables-services
sudo service docker restart

Answer 23

I've had a similar problem for the last few days. For me the cause was a combination of systemd, docker and my hosting provider. I'm running up-to-date CentOS (7.7.1908).

My hosting provider automatically generates a config file for systemd-networkd. Starting with systemd 219 which is the current version for CentOS 7, systemd-networkd took control of network-related sysctl parameters. Docker seems to be incompatible with this version and will reset the IP-Forwarding flags everytime a container is launched.

My solution was to add IPForward=true in the [Network]-section of my provider-generated config file. This file might be in several places, most likely in /etc/systemd/network.

The process is also described in the official docker docs: https://docs.docker.com/v17.09/engine/installation/linux/linux-postinstall/#ip-forwarding-problems

Answer 24

I also encountered such an issue while trying to set up a project using Docker-Compose on Ubuntu.

The Docker had no access to internet at all, when I tried to ping any IP address or nslookup some URL - it failed all the time.

I tried all the possible solutions with DNS resolution described above to no avail.

I spent the whole day trying to find out what the heck is going on, and finally found out that the cause of all the trouble was the antivirus, in particular it's firewall which for some reason blocked Docker from getting the IP address and port.

When I disabled it - everything worked fine.

So, if you have an antivirus installed and nothing helps fix the issue - the problem could be the firewall of the antivirus.

Answer 25

For Ubuntu 19.04 using openconnect 8.3 for VPN, I had to symlink /etc/resolve.conf to the one in systemd (opposite of answerby wisbucky )

sudo ln -sf /etc/resolv.conf /run/systemd/resolve/resolv.conf

Steps to debug

1. Connect to Company VPN
2. Look for correct VPN settings in either /etc/resolv.conf or /run/systemd/resolve/resolv.conf
3. Whichever has the correct DNS settings, we'll symlink that to the other file ( Hint: Place one with correct settings on the left of assignment )

Docker version: Docker version 19.03.0-rc2, build f97efcc

Answer 26

I do not know what I am doing but that worked for me :

OTHER_BRIDGE=br-xxxxx # this is the other random docker bridge (`ip addr` to find)    
service docker stop

ip link set dev $OTHER_BRIDGE down
ip link set dev docker0 down
ip link delete $OTHER_BRIDGE type bridge
ip link delete docker0 type bridge
service docker start && service docker stop

iptables -t nat -A POSTROUTING ! -o docker0 -s 172.17.0.0/16 -j MASQUERADE
iptables -t nat -A POSTROUTING ! -o docker0 -s 172.18.0.0/16 -j MASQUERADE

service docker start

Answer 27

I was stumped when this happened randomly for me for one of my containers, while the other containers were fine. The container was attached to at least one non-internal network, so there was nothing wrong with the Compose definition. Restarting the VM / docker daemon did not help. It was also not a DNS issue because the container could not even ping an external IP. What solved it for me was to recreate the docker network(s). In my case, docker-compose down && docker-compose up worked.

Compose

This forces the recreation of all networks of all the containers:

docker-compose down && docker-compose up

Swarm mode

I suppose you just remove and recreate the service, which recreates the service's network(s):

docker service rm some-service

docker service create ...

If the container's network(s) are external

Simply remove and recreate the external networks of that service:

docker network rm some-external-network

docker network create some-external-network

Answer 28

Just adding this here in case someone runs into this issue within a virtualbox container running docker. I reconfigured the virtualbox network to bridged instead of nat, and the problem went away.

Answer 29

First thing to check is run cat /etc/resolv.conf in the docker container. If it has an invalid DNS server, such as nameserver 127.0.x.x, then the container will not be able to resolve the domain names into ip addresses, so ping google.com will fail.

Second thing to check is run cat /etc/resolv.conf on the host machine. Docker basically copies the host's /etc/resolv.conf to the container everytime a container is started. So if the host's /etc/resolv.conf is wrong, then so will the docker container.

If you have found that the host's /etc/resolv.conf is wrong, then you have 2 options:

1. Hardcode the DNS server in daemon.json. This is easy, but not ideal if you expect the DNS server to change.

2. Fix the hosts's /etc/resolv.conf. This is a little trickier, but it is generated dynamically, and you are not hardcoding the DNS server.

---

1. Hardcode DNS server in docker daemon.json

• Edit /etc/docker/daemon.json

  {
      "dns": ["10.1.2.3", "8.8.8.8"]
  }
  

• Restart the docker daemon for those changes to take effect:
  sudo systemctl restart docker

• Now when you run/start a container, docker will populate /etc/resolv.conf with the values from daemon.json.

---

2. Fix the hosts's /etc/resolv.conf

A. Ubuntu 16.04 and earlier

• For Ubuntu 16.04 and earlier, /etc/resolv.conf was dynamically generated by NetworkManager.

• Comment out the line dns=dnsmasq (with a #) in /etc/NetworkManager/NetworkManager.conf

• Restart the NetworkManager to regenerate /etc/resolv.conf :
  sudo systemctl restart network-manager

• Verify on the host: cat /etc/resolv.conf

B. Ubuntu 18.04 and later

• Ubuntu 18.04 changed to use systemd-resolved to generate /etc/resolv.conf. Now by default it uses a local DNS cache 127.0.0.53. That will not work inside a container, so Docker will default to Google's 8.8.8.8 DNS server, which may break for people behind a firewall.

• /etc/resolv.conf is actually a symlink (ls -l /etc/resolv.conf) which points to /run/systemd/resolve/stub-resolv.conf (127.0.0.53) by default in Ubuntu 18.04.

• Just change the symlink to point to /run/systemd/resolve/resolv.conf, which lists the real DNS servers:
  sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

• Verify on the host: cat /etc/resolv.conf

Now you should have a valid /etc/resolv.conf on the host for docker to copy into the containers.

Answer 30

I had the problem on Ubuntu 18.04. However the problem was with the DNS. I was in a corporate network that has its own DNS server and block other DNS servers. This is to block some websites (porn, torrents, ... so on )

To resolve your problem

1. find your DNS on host machine

2. use --dns your_dns as suggested by @jobin

   docker run --dns your_dns -it --name cowsay --hostname cowsay debian bash