I had a similar issue, I tried many suggested solutions, but my issue was gone after I rebooted my VM.

Here's how I solved it:

Start the docker container for the application in an interactive mode, in my case it an nginx container :

docker run -i -t nginx:latest /bin/bash

Run the command below to grant read permission to the others role for the resolv.conf file:

chmod o+r /etc/resolv.conf

Note: If you are having this issue on your host machine (Ubuntu Linux OS) and not for the Docker containers, then run the same command adding sudo to it in the host machine terminal:

sudo chmod o+r /etc/resolv.conf

Endeavour to exit your bash interactive terminal once you run this:

exit

And then open a new bash interactive terminal and run the commands again:

apt-get update
apt-get install nano
export TERM=xterm

Everything should work fine now.

Reference to this on Digital Ocean: Apt error: Temporary failure resolving 'deb.debian.org'

That's all.

I easily resolved it via:

- docker exec -it nginx bash (Go inside container)
- ping google.com (if not working)
- exit (Exit from container)
- sudo service docker restart

Please also confirms /etc/sysctl.conf

- net.ipv4.ip_forward = 1

sudo sysctl -p /etc/sysctl.conf

If you have VPN running, stop it and try again. It solved for me!

I simply restarted docker and this worked for me.

sudo service docker restart or sudo /etc/init.d/docker restart

Prior to bumping into this issue, docker was working fine. If you never had docker working in the first place, you probably have a different issue.

Under Debian, as root, I've ran:

/etc/init.d/docker restart

This solved the issue for me.

Then build and run the container again.

Perhaps the network on the VM is not communicating with the default network created by docker during the build (bridge), so try "host" network :

docker build --network host -t [image_name]

I had the same problem and in my case it was file access control.

I uses extended acls on the docker root folder and did not realize it, because they where inherited from the folder above (stupid idea to test docker in a "scratch" directory where permissions are set via extended acls).

This lead to the situation that "/etc/resolv.conf" had setting "640" inside the running docker container with a "+" marking the extended acls. But the image did not have extended acls installed and could not handle it.

The weird thing was that, as far as I can see, all other network tools worked (e.g. ping) but only apt could no access the DNS resolver.

After removing the extended acls from the docker root and setting the usual acls, everything worked inside the running container.

Similar to the answer of "Promise Prestion", but solved permanently for new containers, too.

Coming here from some docker cross compiling headache:

While forking some repo I manually downloaded its root folder containing confd stuff and added it just like the original maintainer did.

ADD root /

after this I was not able to apt update anymore.

I found that the permission of my root named folder was wrong. stat -f "%OLp" root revealed it is 700, but must be 755 to work.

Specifying a DNS server for docker containers helped me.

Create a /etc/docker/daemon.json file with this content:

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

and restart the docker service:

sudo service docker restart

src: https://docs.docker.com/engine/install/linux-postinstall/#specify-dns-servers-for-docker

Similar issue, under debian. Root cause was a bad DOCKER-USER rule in iptables chain

Those rules have been haded

iptables -I DOCKER-USER -i eno1 -j DROP
iptables -I DOCKER-USER -s 90.62.xxx.xx/32 -i eno1 -j ACCEPT

so removing temporarily following rule fix the point

iptables -D DOCKER-USER -i eno1 -j DROP