cli
                                
                                 cli copied to clipboard
                                
                                    cli copied to clipboard
                            
                            
                            
                        ERROR: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:35711->[::1]:53: read: connection refused
hi, I installed docker on Android and sudo docker version works fine and shows Client and Server available. but any kind of command , such as hello-world, pull, push, build, etc returns me this error. this is my command sudo docker build -t img1 . ERROR: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:35711->[::1]:53: read: connection refused
i am working on Android and do not have systemd, systemctl to start restart service, i used dockerd to start daemon and it started with no error i am not sure if there is any firewall proxy on android, how can i evaluate it? please help me i really need it
looks like it's trying to connect to IPv6 localhost for DNS resolution.
note that Android is currently not a supported platform for Docker (at least very much untested).
Does it work if you configure the host to use (e.g.) 8.8.8.8 as primary DNS server (not sure how it's configured in your environment, on linux it would usually be done through /etc/resolv.conf
Hello again, tried to set DNS on android, by sudo setprop dns1 8.8.8.8 and sudo setprop dns1 8.8.4.4 . and getprop also returns correctly. but still have connection refuse problem. there is not /etc/resolv.conf on android9 !!! no idea how to solve this problem , i have limited time, please help me. thanks
I took this screen shot after setting my DNS, any Idea guys??

I'm having the same issue on openSUSE Leap 15.2, but only on the first attempt to pull an image after boot. my /etc/resolv.conf is fine, configured by DHCP.
What happens here is the docker daemon trying to contact ::1 as nameserver, via IPv6, and totally ignores what is actually configured in /etc/resolv.conf... why?
Interesting detail:
after the first fail the issue "repairs itself" - after waiting for ...maybe a minute or so the next attempt to pull an image works. But if I try again right after the first fail, it fails again. On the other hand, it does not matter how long the system has been up - the first pull fails, the next one fails if tried too soon afte the fail, then it works until reboot.
Someone please explain o.0
have you set nameserver 8.8.8.8 nameserver 8.8.4.4 in your /etc/resolv.conf?
i already said that my /etc/resolv.conf is fine - everyting else and their dog is perfectly able to resolve hostnames. You do realize that with the settings that you suggest the system will be unable to resolve hostnames for local adresses?
Anyway, I found something: the systems here that show this problem all run NetworkManager for the network, the ones that dont have static (manually) configured network. So .. I changed the start of the docker unit file to include "NetworkManager-wait-online.service" in the "After=" line, and nof the problem doesn't happen anymore. Seems that when dockerd is "normally" started, networkmanager isn't up yet so docker can'T find the DNS in /etc/resolv.conf, and just assumes ::1 instead. But on the second try it uses what's in resolv.conf by then, which is the properly configured dns.
Just saw this on aarch64, Debian Buster. This is a wreck.
had the same error and kept re-running the command docker-compose up db which attempts to pull the mariadb container. I didnt change a thing and the 5th try succeeded.
re-trying N times, each time it works.
Now I tried to set the nameserver 8.8.8.8
Same problem on Arch Linux. Rerunning the command helps, usually it succeeds with the 2nd or 3rd try.
Same problem on Arch Linux. Rerunning the command helps, usually it succeeds with the 2nd or 3rd try.
Hi, what command helps did you use?, I have the same error in Arch linux
It usually happens to me when I'm pulling an image using docker-compose pull. I just rerun the command again and again until it works by itself.
having same issue just uninstalled pihole and set my pi to use google dns and Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: read udp 127.0.0.1:40185->127.0.0.1:53: read: connection refused error
Having some kind of the same, and I am able to resolve the address, just docker cannot:
error: Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: dial tcp 192.168.65.1:3128: connect: network is unreachable
I am on a Mac mini M1 with the latest OS and Docker installed. Resetting Docker to factory defaults resolve the problem but enabling the new virtualization framework produces the error again.
I have found a solution for snapcraft installation of docker (sudo snap install docker), tested on Archlinux.
sudo snap disable docker
sudo snap enable docker
If it still doesn't work for you, see if upgrading to the edge branch can help.
sudo snap refresh docker --edge # Don't do this in the production environment
@muuvmuuv 's fix worked for me as well.
Weird.. MX Linux, same issue. Retry 3 minutes later with no changes, works fine.
It was the same for me on Windows 8.1 with 'timeout' at the end. I changed DNS to Google's and it worked. 8.8.8.8 8.8.4.4
I am getting this same error. I have tried pretty much everything in this post. Any ideas would be super helpful.
I'm having an issue when I run our make local command that none of the other developers on my team are having. I'm on a Mac M1 machine. One other dev is also on an M1 and our setup works fine for him. This is happening on multiple repositories. So I'm assuming I have a global setting messed up somehow.
Here is the error I am getting that I don't fully understand...
=> ERROR [dealers_app internal] load metadata for docker.io/library/golang:alpine                                                      0.1s
 => CANCELED [dealers_nginx internal] load metadata for docker.io/library/nginx:1.15.2-alpine                                           0.0s
------
 > [dealers_app internal] load metadata for docker.io/library/golang:alpine:
failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to create LLB definition: failed to authorize: rpc error: code = Unknown desc = failed to fetch anonymous token: Get "https://auth.docker.io/token?scope=repository%3Alibrary%2Fgolang%3Apull&service=registry.docker.io": dial tcp: lookup auth.docker.io on [::1]:53: read udp [::1]:61456->[::1]:53: read: connection refused
make: *** [app] Error 17
Stuff that I have tried.
- 
- docker logout then docker login
 
- 
- Changed dns to 8.8.8.8 in the docker dameon
 
- 
- Changed my mac's dns entries to 8.8.8.8
 
- 
- Uninstalled and reinstalled Docker
 
- 
- Reverted docker to 4.0.1 which is what the other M1 dev is using
 
- 
- Turned off buildkit in the docker dameon "features": { buildkit: false}
 
- 
- I had dnsmasq running in brew services. Have completely removed dnsmasq now.
 
- 
- Have confirmed I'm not behind a proxy
 
- 
- There is no firewall
 
- 
- Running docker compose up -d instead of make local produces the same error
 
- 
- docker pull golang:alpine works as expected
 
- 
- export DOCKER_BUILDKIT=0 and export COMPOSE_DOCKER_CLI_BUILD=0 did not help
 
- 
- If I navigate directly to this url in a browser, I get a token... https://auth.docker.io/token?scope=repository%3Alibrary%2Fgolang%3Apull&service=registry.docker.io
 
Any thoughts would be great!
docker-compose.yml
version: "3.3"
services:
  dealers-app:
    container_name: ${APP_NAME}_app
    image: ${APP_NAME}_app
    build:
      context: .
      dockerfile: docker/app.local.Dockerfile
    environment:
      VIRTUAL_HOST: ${APP_NAME}-app
      HTTPS_METHOD: noredirect
    env_file:
      - .env
    ports:
      - 80
    expose:
      - ${APP_PORT}
    volumes:
      - .:/go/src/app
      - ${GOPATH}/pkg/mod:/go/pkg/mod
  dealers-nginx:
    container_name: ${APP_NAME}_nginx
    image: ${APP_NAME}_nginx
    build:
      context: .
      dockerfile: docker/nginx/nginx.Dockerfile
    environment:
      VIRTUAL_HOST: ${APP_NAME}.test
      HSTS: "off"
      HTTPS_METHOD: noredirect
      APP_DOMAIN: ${APP_NAME} ${APP_NAME}.test
      APP_HOST: ${APP_NAME}-app
      APP_PORT: ${APP_PORT}
networks:
  default:
    external:
      name: development
Makefile
PROJECT_NAME := dealers
.DEFAULT := help
.PHONY: local down reset app all-reset nginx nginx-reset
help:
    @echo '# Dev Targets'
    @echo
    @echo '    local            build the application containers/services locally'
    @echo '    down             tear down the application containers/services locally'
    @echo '    reset            rebuild the application container and restart the service'
    @echo
    @echo '    all-reset        reset the application containers/services'
    @echo '    app              build the application container'
    @echo '    nginx            build the nginx container'
    @echo '    nginx-reset      rebuild the nginx container and restart the service'
    @echo
    @echo '    help             show this help message'
    @echo
local: app nginx
    docker compose up -d --force-recreate \
    && docker compose logs -f
down:
    docker compose down -v
all-reset: down local
reset: app
    docker compose up -d --force-recreate ${PROJECT_NAME}-app \
    && docker compose logs -f
app:
    docker compose build ${PROJECT_NAME}-app
nginx:
    docker compose build ${PROJECT_NAME}-nginx
nginx-reset: nginx
    docker compose up -d --force-recreate ${PROJECT_NAME}-nginx
Dockerfile
FROM golang:alpine as build
RUN apk add --no-cache git
ENV GOPRIVATE gitlab.com/companynameishere-software-development
RUN go install github.com/githubnemo/CompileDaemon@latest \
    && chmod +x /go/bin/CompileDaemon
WORKDIR /go/src/app
ADD ../.netrc /root/.netrc
ENTRYPOINT CompileDaemon --build="go build -o main"
Am currently experiencing the same issue on 64 bit x86 Void Linux
i already said that my /etc/resolv.conf is fine - everyting else and their dog is perfectly able to resolve hostnames. You do realize that with the settings that you suggest the system will be unable to resolve hostnames for local adresses?
Anyway, I found something: the systems here that show this problem all run NetworkManager for the network, the ones that dont have static (manually) configured network. So .. I changed the start of the docker unit file to include "NetworkManager-wait-online.service" in the "After=" line, and nof the problem doesn't happen anymore. Seems that when dockerd is "normally" started, networkmanager isn't up yet so docker can'T find the DNS in /etc/resolv.conf, and just assumes ::1 instead. But on the second try it uses what's in resolv.conf by then, which is the properly configured dns.
This happened to me while trying to install Home Assistant on Debian 11.2
Docker tried to make network calls before network interface is ready, causing the install script to fail.
Solution: run "systemctl cat docker.service" , and it will tell you where the docker service file is located. edit /lib/systemd/system/docker.service with your favorite text editor append "NetworkManager-wait-online.service" to line 4, that line should start with the word "After=" run "systemctl daemon-reload" to update your changes to the service file.
I have found a solution for snapcraft installation of docker (
sudo snap install docker), tested on Archlinux.sudo snap disable docker sudo snap enable docker
Manjaro Linux here. Thanks a lot! Only your solution helped me.
For me, it was because I forgot to symlink /etc/resolv.conf; however the problem was specific to my particular set-up: https://wiki.archlinux.org/title/Systemd-resolved . I hadn't had any DNS issues up to this point, so it took me a while to figure it out.
I am using an LXC Container in Proxmox with Docker running on it. Confirmed that when adding: nameserver 8.8.8.8 nameserver 8.8.4.4 to /etc/resolv.conf the issue is resolved.
Cheers.
It was the same for me on Windows 8.1 with 'timeout' at the end. I changed DNS to Google's and it worked. 8.8.8.8 8.8.4.4
i am on windows 11 with this error , any one please help

i already said that my /etc/resolv.conf is fine - everyting else and their dog is perfectly able to resolve hostnames. You do realize that with the settings that you suggest the system will be unable to resolve hostnames for local adresses? Anyway, I found something: the systems here that show this problem all run NetworkManager for the network, the ones that dont have static (manually) configured network. So .. I changed the start of the docker unit file to include "NetworkManager-wait-online.service" in the "After=" line, and nof the problem doesn't happen anymore. Seems that when dockerd is "normally" started, networkmanager isn't up yet so docker can'T find the DNS in /etc/resolv.conf, and just assumes ::1 instead. But on the second try it uses what's in resolv.conf by then, which is the properly configured dns.
This happened to me while trying to install Home Assistant on Debian 11.2
Docker tried to make network calls before network interface is ready, causing the install script to fail.
Solution: run "systemctl cat docker.service" , and it will tell you where the docker service file is located. edit /lib/systemd/system/docker.service with your favorite text editor append "NetworkManager-wait-online.service" to line 4, that line should start with the word "After=" run "systemctl daemon-reload" to update your changes to the service file.
You're a genius! This is the definite solution for Debian. Worked on Debian 10 and 11.
Solution: run "systemctl cat docker.service" , and it will tell you where the docker service file is located. edit /lib/systemd/system/docker.service with your favorite text editor append "NetworkManager-wait-online.service" to line 4, that line should start with the word "After=" run "systemctl daemon-reload" to update your changes to the service file.
This solved it for me, was getting this error in KinD and simply had to recreate to get it to reflect the changes.
This is an old issue. I will resolve it since a solution is described above.
The solution described above sounds to me like a workaround and not like a solution.
The issue seems like docker is somehow caching the DNS resolution information when it starts and does not refresh it later when a command is run. The workaround described above will solve the problem that docker apparently caches the DNS resolution info when it is not even there yet because no network is connected yet. But I strongly suspect that the underlying issue will still cause errors when for example the DNS resolution information changes while docker is running, for example when connecting to a new network.