Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can. 
I have spent several weeks debugging this and intentionally excluded the common causes (DNS, firewall, Pi-hole, VPN, Docker DNS, bridge networking).
Are you using the latest AIO image?
Yes.
Image:
ghcr.io/nextcloud-releases/all-in-one:latest
Created:
2026-06-26T08:34:24Z
Digest:
sha256:e7abd7c7f4f28ec63971e92fdcb03d361a85cd3e7d83cd50d19c375cad623614
Host system
Hardware:
- Raspberry Pi 4 (8 GB)
OS:
- Debian GNU/Linux 13 (Trixie)
Kernel:
- 6.18.34+rpt-rpi-v8
Docker:
- Docker Engine Community 29.6.1
- Compose v5.3.0
Storage:
- overlayfs
- Docker Root Dir: /var/lib/docker
Problem
The AIO mastercontainer immediately exits with
curl: (6) Could not resolve host: ghcr.io
Could not reach https://ghcr.io.
Most likely is something blocking access to it.
The strange part
Everything else can resolve and reach ghcr.io.
Host:
ping ghcr.io
works.
Host:
curl -I https://ghcr.io
works.
Container:
docker run --rm alpine nslookup ghcr.io
works.
Container:
docker run --rm alpine sh -c "apk add --no-cache curl >/dev/null && curl -I https://ghcr.io"
works.
Even the SAME AIO image works:
docker run --rm
--entrypoint /bin/bash
ghcr.io/nextcloud-releases/all-in-one:latest
-c "curl -I https://ghcr.io/v2/"
returns HTTP/2 405 successfully.
So the image itself clearly has working DNS/network access.
Docker DNS
daemon.json
{
"dns": [
"8.8.8.8",
"1.1.1.1"
]
}
Host resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1
Docker network
bridge network exists normally.
iptables looks normal.
No custom firewall.
No Pi-hole.
No proxy.
No VPN inside Docker.
Tailscale was stopped during testing.
Container
Entrypoint:
/start.sh
CMD:
null
NetworkMode:
bridge
What looks inconsistent
Inside /start.sh the following check exists:
if ! curl --no-progress-meter https://ghcr.io/v2/ >/dev/null; then
This curl reports
curl: (6) Could not resolve host: ghcr.io
However running exactly the same curl manually from the same image succeeds.
So it appears the startup environment behaves differently from a normal shell started from the image.
Question
Is this a known issue with
- Docker Engine 29.6.x
- Debian 13 (Trixie)
- Raspberry Pi arm64
or is there another reason why curl inside /start.sh cannot resolve ghcr.io while the exact same image can?