podman login works fine and authenticates but podman pull fails with dial tcp: lookup: Temporary failure in name resolution
#24790
Comments
github-actions
bot
added
remote
|
I have tested it by adding entry into hosts file of my MacOS, and this issue still persist |
|
I'm having a very similar issue. I'm trying to access a registry behind a VPN, and while output❯ podman login registry.private.some-domain.com --verbose
Username: <user>
Password:
Used: /Users/userhome/.config/containers/auth.json
Login Succeeded!
❯ podman login registry.private.some-domain.com --verbose
Authenticating with existing credentials for registry.private.some-domain.com
Existing credentials are valid. Already logged in to registry.private.some-domain.comeither output❯ podman pull registry.private.some-domain.com/path_to/image:master
Trying to pull registry.private.some-domain.com/path_to/image:master...
Error: initializing source docker://registry.private.some-domain.com/path_to/image:master: pinging container registry registry.private.some-domain.com: Get "https://registry.private.some-domain.com/v2/": dial tcp: lookup registry.private.some-domain.com: no such host❯ podman search registry.private.some-domain.com/
Error: 1 error occurred:
* couldn't search registry "registry.private.some-domain.com": pinging container registry registry.private.some-domain.com: Get "https://registry.private.some-domain.com/v2/": dial tcp: lookup registry.private.some-domain.com: no such hostNotice that in my case the error is not about "Temporary failure in name resolution", but directly "no such host", but otherwise the behavior seems equivalent. podman info outputI'm using macOS 15.2 and podman desktop 1.15.0 host:
arch: arm64
buildahVersion: 1.38.0
cgroupControllers:
- cpu
- io
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.1.12-2.fc40.aarch64
path: /usr/bin/conmon
version: 'conmon version 2.1.12, commit: '
cpuUtilization:
idlePercent: 99.67
systemPercent: 0.16
userPercent: 0.17
cpus: 6
databaseBackend: sqlite
distribution:
distribution: fedora
variant: coreos
version: "40"
eventLogger: journald
freeLocks: 2048
hostname: localhost.localdomain
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 1000000
uidmap:
- container_id: 0
host_id: 502
size: 1
- container_id: 1
host_id: 100000
size: 1000000
kernel: 6.11.3-200.fc40.aarch64
linkmode: dynamic
logDriver: journald
memFree: 1522900992
memTotal: 2042683392
networkBackend: netavark
networkBackendInfo:
backend: netavark
dns:
package: aardvark-dns-1.12.2-2.fc40.aarch64
path: /usr/libexec/podman/aardvark-dns
version: aardvark-dns 1.12.2
package: netavark-1.12.2-1.fc40.aarch64
path: /usr/libexec/podman/netavark
version: netavark 1.12.2
ociRuntime:
name: crun
package: crun-1.17-1.fc40.aarch64
path: /usr/bin/crun
version: |-
crun version 1.17
commit: 000fa0d4eeed8938301f3bcf8206405315bc1017
rundir: /run/user/502/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
os: linux
pasta:
executable: /usr/bin/pasta
package: passt-0^20240906.g6b38f07-1.fc40.aarch64
version: |
pasta 0^20240906.g6b38f07-1.fc40.aarch64-pasta
Copyright Red Hat
GNU General Public License, version 2 or later
<https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
remoteSocket:
exists: true
path: unix:///run/user/502/podman/podman.sock
rootlessNetworkCmd: pasta
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: true
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: true
serviceIsRemote: true
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.2.2-2.fc40.aarch64
version: |-
slirp4netns version 1.2.2
commit: 0ee2d87523e906518d34a6b423271e4826f71faf
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.5
swapFree: 0
swapTotal: 0
uptime: 0h 24m 30.00s
variant: v8
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
- ipvlan
volume:
- local
registries:
search:
- docker.io
store:
configFile: /var/home/core/.config/containers/storage.conf
containerStore:
number: 0
paused: 0
running: 0
stopped: 0
graphDriverName: overlay
graphOptions: {}
graphRoot: /var/home/core/.local/share/containers/storage
graphRootAllocated: 106769133568
graphRootUsed: 4700618752
graphStatus:
Backing Filesystem: xfs
Native Overlay Diff: "true"
Supports d_type: "true"
Supports shifting: "false"
Supports volatile: "true"
Using metacopy: "false"
imageCopyTmpDir: /var/tmp
imageStore:
number: 0
runRoot: /run/user/502/containers
transientStore: false
volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
APIVersion: 5.3.1
Built: 1732147200
BuiltTime: Thu Nov 21 01:00:00 2024
GitCommit: ""
GoVersion: go1.22.7
Os: linux
OsArch: linux/arm64
Version: 5.3.1To rule out any external issue, I tried uninstalling podman and testing it with rancher desktop, which works as expected in the same setup |
|
either docker pull or docker search fail with an error |
Yes, my bad 🙈 already fixed it in my comment |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue Description
When attempting to run the command
podman pull, the operation fails with adial tcp: lookup: Temporary failure in name resolutionerror, despite successful authentication usingpodman login. This issue persists even after verifying that the DNS cache is cleared and all required Docker credentials are correct.I am using Podman Desktop v1.14.2 on MacOS 15.1.1 [OS/Arch: darwin]
Steps to reproduce the issue
Observed Behavior:
The
podman logincommand completes successfully, indicating authentication with the Private Registry.The
podman pullcommand fails with an error message containing "Temporary failure in name resolution".Describe the results you received
Describe the results you expected
Expected Behavior:
The
podman pullcommand should successfully retrieve images from a registry without encountering any network-related errors if it was able to authenticate prior.FYI:
docker pullworks fine in the exact same scenariopodman info output
Podman in a container
No
Privileged Or Rootless
None
Upstream Latest Release
Yes
Additional environment details
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: