Permission error with Docker's /var/run/docker.sock and Traefik in container

Incus is version 6.0.0-1ubuntu0.1 provided by the Ubuntu 24.04 LTS repos.

I am getting a permission error about accessing /var/run/docker.sock from trying to implement the basic Traefik example found here Traefik Docker TLS Challenge Documentation - Traefik.

As far as I can tell the permission error is entirely contained in the container and does not have to do with the actual networking of Traefik. root seems to be the owner of /var/run/docker.sock. Adding root to the docker group didn’t change anything nor did chmod 777 /var/run/docker.sock - which is why I am thinking it must be a container issue of some sort?

The error is as follows:

ERR Failed to retrieve information of the docker client and server host error="permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get \"http://%2Fvar%2Frun%2Fdocker.sock/v1.24/version\": dial unix /var/run/docker.sock: socket: permission denied" providerName=docker

Code I am using to create the LXC container and docker container inside that:

sudo mkdir /server
sudo chown -R ubuntu:ubuntu /server

sudo incus profile create docker
sudo incus profile set docker security.nesting=true

sudo incus launch images:debian/12/cloud whoogle --profile docker --config limits.cpu=1 --config limits.memory=400MiB --storage default --network incusbr0
sudo incus exec whoogle -- bash  -c "sudo apt install -y nano"
sudo incus exec whoogle -- bash -c "sudo apt install -y ca-certificates curl"
sudo incus exec whoogle -- bash -c "sudo install -m 0755 -d /etc/apt/keyrings"
sudo incus exec whoogle -- bash -c "sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc"
sudo incus exec whoogle -- bash -c "sudo chmod a+r /etc/apt/keyrings/docker.asc"
sudo incus exec whoogle -- bash -c 'echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null'
sudo incus exec whoogle -- bash -c "sudo apt update"
sudo incus exec whoogle -- bash -c "sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin"

mkdir /server/whoogle
mkdir /server/whoogle/letsencrypt
sudo incus config device add whoogle config disk source=/server/whoogle path=/server/whoogle shift=true
nano /server/whoogle/docker-compose.yml # paste in from https://doc.traefik.io/traefik/user-guides/docker-compose/acme-tls/ , edit domain
sudo incus exec whoogle -- bash -c "docker compose -f /server/whoogle/docker-compose.yml up -d"

Are you seeing any relevant DENIED entries in dmesg?

Yes! dmesg didn’t work in the container or docker container, but in the host - which is probably where you meant - it does give

audit: type=1400 audit(1727226653.614:1829): apparmor="DENIED" operation="create" class="net" info="failed type and protocol match" error=-13 namespace="root//incus-whoogle_<var-lib-incus>" profile="docker-default" pid=40712 comm="traefik" family="unix" sock_type="stream" protocol=0 requested="create" denied="create" addr=none

The closest thing I could find is this forum AppArmor causing application inside LXD container to crash - #5 by wc-ubuntu - Support - Ubuntu Community Hub for old LXD, but it references snap locations and may not be relevant to Incus.

And are you familiar with steps to bypass this issue? I wasn’t able to find anything actionable even with the new terms to search with.

So this shows a docker-default apparmor profile inside of the container is what’s breaking thing.
That’s a bit odd, but anyway, you may be able to either modify that profile in /etc/apparmor.d inside of the container, or maybe just unload it?

Thank you for identifying the key issue, I couldn’t figure out what was the important part to center on!

I couldn’t find an apparmor profile docker-default in the container or host. Since the host OS is ubuntu 24.04 I tried switching to ubuntu/24.04/cloud and what do you know, it worked! No docker-default profile in either container or host, but something must be figuring it out. Thanks again!