#53686 Docker daemon inside chroot destroys hotspot routing on host and name resolution inside chroot

Description

Running the Docker daemon inside chroot destroys hotspot routing on host and name resolution inside chroot, and possibly other things. E.g. if there was a networkmanager hotspot active outside the chroot, it will nuke the routing of that hotspot somehow, and name resolution inside the chroot will no longer work despite /etc/resolv.conf being unchanged. Outside, name resolution remains available for some reason.

Before you ask "why on earth run the entire docker daemon inside a chroot", there are some in my opinion good use cases for this niche scenario, e.g. disk encryption.

(Regarding the use cse: booting up an unencrypted systen then setting up a chroot on an encrypted partition, is a good way to be able to boot up for remote password unlock while then ensuring all services will only operate on an encrypted disk, despite the original system disk being unencrypted.)

Reproduce

Set up chroot folder with the usual --bind mounts for /dev, /dev/pts, /proc, sys, and make sure to add mount -t cgroup2 none /your-chroot-base-folder/sys/fs/cgroup
Activate chroot
Before starting the docker service, do a test for name resolution inside the chroot, e.g. ping example.com. At this point, it should work fine. If it doesn't, fix your /etc/resolv.conf first.
Inside the chroot, use service docker start
Now try to do something like ping example.com. You should get host resolution errors.

Expected behavior

At least assuming no special setup like a hotspot outside the chroot, basic name resolution should stay operational even when I'm inside a chroot. That the daemon manages to blow this up is quite fascinating to me.

docker version

Client:
 Version:           29.8.0
 API version:       1.56
 Go version:        go1.27.1
 Git commit:        88096ef00576baf72a9cb45caa45c0544c40e0a7
 Built:             Sat Sep  5 19:42:59 2026
 OS/Arch:           linux/amd64
 Context:           default
failed to connect to the docker API at unix:///var/run/docker.sock; check if the path is correct and if the daemon is running: dial unix /var/run/docker.sock: connect: no such file or directory

docker info

Client:
 Version:    29.8.0
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.37.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.5.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
failed to connect to the docker API at unix:///var/run/docker.sock; check if the path is correct and if the daemon is running: dial unix /var/run/docker.sock: connect: no such file or directory

Additional Info

No response