This week we received an interesting support request, and i thought i might be useful to share..
The user was stating that on their docker deployment, Portainer was unable to connect to /var/run/docker.sock regardless of correctly configuring the CLI command.
First thing we checked was the SELINUX status, as if this is enabled, containers cannot attach to the socket. Using the command "getenforce" will tell you if its enabled or not. "disabled" or "permissive" as a response is good for us.. "enforcing" (which means blocking access) is bad. Regardless, this user had SElinux disabled, so this wasnt the issue.
I then took a look at the docker service status using the systemctl status docker command, and noticed that the service was using a startup command of /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containterd.sock -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock. Normally what you would see (in Docker 18.09.0) for the service start is /usr/bin/dockerd -H unix:///var/run/docker.sock, or (in Docker 18.03.x) docker-containerd --config //var/run/docker/containerd/containerd.toml
I did a "docker version", and noticed his was using Docker 18.09.5.
I edited his docker.service file in /lib/systemd/system and changed his ExecStart to /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containterd.sock and then restarted Docker service (after doing a daemon-reload command).
Hey presto, i could now run Portainer and attach to the Docker Socket.
It seems Docker have changed their ExecStart options/format in latest version of Docker, so you need to be exceptionally careful when following guides from the internet (in this case, the user was following a guide on exposing his daemon over TCP, hence him making the changes to his docker.service file).
Clearly in 18.09.5, docker is transparently remapping /run/containerd/containerd.sock to /var/run/docker.sock, so there is no need to add that manually when editing the docker.service file.
Anyway, this users problem was solved.