Hello, I have a problem after updating from Debian Bookworm to Debian Trixie. I had several containers running under Bookworm, including Portainer. However, after the update to debian trixie, I no longer have access to docker.sock, which means Portainer cannot access docker.sock to manage the other running containers. Of course, I passed docker.host to Portainer -v /var/run/docker.host:/var/run/docker.host. Now, when I try to add the Docker environment to Portainer via the socket, I get the error message âPermission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Head âhttp://%2Fvar%2Frun%2Fdocker.sock/_pingâ: dial unix /var/run/docker.sock: socket: permission denied.â
The permissions for the docker.host file are 660.
Do you have any idea what the problem could be?
Looks like the process inside the Portainer container runs with a UID:GID that doesnât match the UID:GID of the owner of the docker.sock pseudo-file.
You can check the owner usingstat /var/run/docker.sock or ls -ln /var/run/docker.sock.
You can check the uid of the portainer process using ps auxn | grep portainer on the host.
The docker.sockshould be owned by uid 0, the portainer container process should be executed by uid 0.
The output from ls -ln /var/run/docker.sock
srw-rw-rw- 1 0 997 0 Aug 29 21:40 /var/run/docker.sock
ps auxn | grep portainer
100000 93276 0.0 0.0 1295128 30848 ? Ssl Aug29 0:07 /portainer
0 799144 0.0 0.1 1322528 40752 ? Ssl 09:29 0:01 /portainer
0 1126611 0.0 0.0 6528 1844 pts/0 S+ 12:41 0:00 grep portainer
I canât find anything wrong at first glance.
The socket is owned by uid 0 and group id 997.
Gathering from the two listed processes, it looks like you are running two Portainer containers.
While this runs as uid 0, this one should have no issues:
This one runs as uid 100000 and is probably the one having the problem:
this is a proxmox host and the second portainer instance is a running lxc container with portainer.
i have stopped the lxc container and now the ps auxn output.
0 1229556 0.2 0.1 1322272 41632 ? Ssl 13:42 0:00 /portainer 0 1232953 0.0 0.0 6528 1804 pts/0 S+ 13:45 0:00 grep portainer
Ah, okay. So the pseud-file owner and user executing the Portainer process inside the container are both root. Thus, unix file permissions should be okay.
I recommend checking whether ACL, SeLinux or AppArmor are used on your system.
Okay, thanks for now. The strange thing is that everything still worked under Bookworm. Iâm stuck for now.
Here is the output from docker info
Security Options:
apparmor
seccomp
I even completely uninstalled Docker and reinstalled it. Unfortunately, without success.
What else could I do?
Did you make sure the docker repository points to trixie as well?
I run a Proxmox cluster in my homelab, but donât run anything other than lxc containers and kvm vms on those hosts.
I have no idea whether the pve9 upgrade also modifies 3rd party repos in /etc/apt/sources.list.d/. If the repos is still pointing to bookworm, you should switch it to trixie and install docker-ce again.
Other than that: no idea.
all sources are pointed to trixie.
It might be a simple typo, but I noticed you referred to docker.host multiple times even though the error message contains docker.sock. Was it really a typo in your post, or did you accidentally change anything after the upgrade to mount the wrong files?
I assume a typo, but I want to fully rule it out.
I would also try this:
ls -iln /var/run/docker.sock
docker exec portainer ls -iln /var/run/docker.sock
You should get the same output twice. This is mine:
1092 srw-rw---- 1 0 988 0 Aug 27 00:39 /var/run/docker.sock
1092 srw-rw---- 1 0 988 0 Aug 26 22:39 /var/run/docker.sock
The âdockerâ group on my system got GID 988. Iâm not sure if that matters and if it should always be the same. But you can also see that on my system the socket has different permissions and I did not change anything.
You mentioned (quoted above) that the docker socket file has â660â, but this is not what your terminal output says.
This is 666. That means everyone should be able to read and write it, not just When for example an SSH key is accessible by evryone, ssh wouldnât even allow to use it. I can imagine a policy that doesnât allow to use the docker socket either. Or the mounted and the original socket is not the same. The two ls commands would reveal that as -i shows the inode numbers. If the two outputs are not the same, the files are not the same.
Unfortunately if I remember correctly, the new portainer has no ls command inside. So if it doesnât help, we will need to find another way to check it.
Update:
You can try this command for the container
ls -iln $(docker inspect portainer --format '{{.GraphDriver.Data.MergedDir}}')/var/run/docker.sock
Change the container name to whatever your container name is.
Sorry for the typo it was of course /var/run/docker.sock.
I have also checked the permissions.
ls -iln /var/run/docker.sock
3403 srw-rw---- 1 0 997 0 Aug 31 08:47 /var/run/docker.sock
and here is the output from the docker inspect
ls -iln $(docker inspect portainer --format '{{.GraphDriver.Data.MergedDir}}')/var/run/docker.sock
152445 -rw-râr-- 1 0 0 0 Aug 31 09:38 /var/lib/docker/overlay2/9ec18ec2d6f1691e00d924a167d79b4e3c4b403108478da187a24425d1dcafbd/merged/var/run/docker.sock
The permissions from the container look different than on the host.
How can that be?
Looks like you are connecting to a Docker daemon which doesnât see the original host. I remember some users were surprised when after installing the OS, the snap based Docker was automatically installed. I donât remember what OS it was. You can still test if you have snap installed
snap list docker
On debian based Linux, the following commands can give us some idea and recognize incorrectly installed Docker:
docker info
docker version
Review the output before sharing and remove confidential data if any appears (public IP for example)
dpkg -l 'docker*' | grep '^ii'
snap list docker
When you share the outputs, please, use code blocks instead of quotes. So use three backticks: before and after the code snippet
```
code
```
Okay here are the outputs.
snap list docker
-bash: snap: command not found
docker info
Client: Docker Engine - Community
Version: 28.3.3
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.26.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.39.1
Path: /usr/libexec/docker/cli-plugins/docker-compose
model: Docker Model Runner (EXPERIMENTAL) (Docker Inc.)
Version: v0.1.36
Path: /usr/libexec/docker/cli-plugins/docker-model
Server:
Containers: 15
Running: 11
Paused: 0
Stopped: 4
Images: 26
Server Version: 28.3.3
Storage Driver: overlay2
Backing Filesystem: zfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
runc version: v1.2.5-0-g59923ef
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.14.11-1-pve
Operating System: Debian GNU/Linux 13 (trixie)
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 30.77GiB
Name: pve
ID: 550efd9e-f169-4c32-b127-1b920aaf245b
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
::1/128
127.0.0.0/8
Live Restore Enabled: false
docker version
Client: Docker Engine - Community
Version: 28.3.3
API version: 1.51
Go version: go1.24.5
Git commit: 980b856
Built: Fri Jul 25 11:34:13 2025
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 28.3.3
API version: 1.51 (minimum version 1.24)
Go version: go1.24.5
Git commit: bea959c
Built: Fri Jul 25 11:34:13 2025
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.27
GitCommit: 05044ec0a9a75232cad458027ca83437aae3f4da
runc:
Version: 1.2.5
GitCommit: v1.2.5-0-g59923ef
docker-init:
Version: 0.19.0
GitCommit: de40ad0
dpkg -l 'docker*' | grep '^ii'
ii docker-buildx-plugin 0.26.1-1~debian.13~trixie amd64 Docker Buildx cli plugin.
ii docker-ce 5:28.3.3-1~debian.13~trixie amd64 Docker: the open-source application container engine
ii docker-ce-cli 5:28.3.3-1~debian.13~trixie amd64 Docker CLI: the open-source application container engine
ii docker-ce-rootless-extras 5:28.3.3-1~debian.13~trixie amd64 Rootless support for Docker.
ii docker-compose-plugin 2.39.1-1~debian.13~trixie amd64 Docker Compose (V2) plugin for the Docker CLI.
ii docker-model-plugin 0.1.36-1~debian.13~trixie amd64 Docker Model Runner plugin for the Docker CLI.
The release seems to be the right one and there is no snap installed. Letâs continue some debugging. Please, run the following command:
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock busybox ls -iln /var/run/docker.sock
It should get the same output as you got for the portainer container
We can also check other Docker-related files:
ls -iln /var/run/ | grep docker
docker run --rm -v /var/run/:/var/run/ busybox ls -iln /var/run/ | grep docker
1216 drwx------ 8 0 0 180 Aug 27 00:39 docker
1217 -rw-r--r-- 1 0 0 3 Aug 27 00:39 docker.pid
1092 srw-rw---- 1 0 988 0 Aug 27 00:39 docker.sock
Or test if the daemon is really the same daemon that you see on the host:
pidof dockerd
docker run -it --pid host busybox pidof dockerd
You should get the same number or numbers as process IDs of the Docker daemon(s). Since I have two Docker daeomns, including a rootless Docker, I got two numbers
2081 936
2081 936
I will think about other tests if these donât help.
There is a way to determine the inode and the owner userid of the docker.sock used by portainer.
docker run -ti --rm --volumes-from portainer alpine ls -lni /var/run/docker.sock
It will start an alpine container, and re-use the volumes and binds that the portainer container uses.This assumes that the actual name of the container is portainer. If itâs not, just replace portainer with the actual name.
Just to clarify for @netsrot : This solution is a great alternative to the âdocker inspect + lsâ command and it would work also with the containerd image store. docker inspect doesnât seem to show any GraphDriver section in the json output when the containerd image store is used..
Can you check if the container sees the hostâs docker GID as a supplemental group.
Use this command on host :
getent group docker
Then run Portainer with that GID:
docker run -d \
--name portainer \
--group-add 998 \
-v /var/run/docker.sock:/var/run/docker.sock \
-v portainer_data:/data \
portainer/portainer-ce
Create this Yaml
services:
portainer:
image: portainer/portainer-ce
group_add: ["998"] # <- host docker GID
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- portainer_data:/data
Then verify inside the container
docker exec -it portainer id
Morning, I just continued testing with your commands.
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock busybox ls -iln /var/run/docker.sock
3403 srw-rw---- 1 0 997 0 Aug 31 06:47 /var/run/docker.sock
root@pve:~# ls -iln /var/run/ | grep docker
3406 drwx------ 7 0 0 160 Aug 31 08:47 docker
3407 -rw-r--r-- 1 0 0 4 Aug 31 08:47 docker.pid
3403 srw-rw---- 1 0 997 0 Aug 31 08:47 docker.sock
root@pve:~# pidof dockerd
84128 81879 4907
root@pve:~# docker run -it --pid host busybox pidof dockerd
84128 81879 4907
root@pve:~# docker run -ti --rm --volumes-from portainer alpine ls -lni /var/run/docker.sock
3403 srw-rw---- 1 0 997 0 Aug 31 06:47 /var/run/docker.sock
I have also start portainer with the added docker group 997, but i don´t have the permission for docker.sock.
how do you have 3 docker daemons?