Systemd user cannot get user group’s ability

dockergroupsystemdusers

I added a non-root user in docker group, and an other service run as this non-root user connect to docker daemon. but the service can not work.
I do a test example for this :

root@# systemctl start docker.service 
root@# gpasswd -a tiger docker

create a systemd service in tiger:

[Service]
ExecStart=/home/tiger/connectdocker
Restart=always
StartLimitInterval=0
Delegate=true
KillMode=process
[Install]
WantedBy=default.target

the /home/tiger/connectdocker like this:

docker run -itd busybox 2> connectdocker.log

start this service:

tiger@# systemctl --user enable connectdocker.service
tiger@# systemctl --user start connectdocker.service

and the result:

Thu Jul 21 00:59:15 CST 2016
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

but I can connect to docker.sock with tiger :

tiger@# docker run -itd busybox
997e99f959cfd5500319935ec17677775da9d367d203a11efef8b42161c3ee64

for prove that, I change the /var/run/docker.sock group from docker to tiger, and the connectdocker service can connect to docker daemon.

change /var/run/docker.sock:

ls -l /run/docker.sock
srw-rw---- 1 root docker 0 Jul 21 00:33 /run/docker.sock

to:

ls -l /run/docker.sock
srw-rw---- 1 root tiger 0 Jul 21 00:33 /run/docker.sock

Best Answer

You should use the User= directive in your systemd service.

User=, Group=

Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group name, or numeric ID as argument. For system services (services run by the system service manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of systemd --user), the default is "root", but User= may be used to specify a different user. For user services of any other user, switching user identity is not permitted, hence the only valid setting is the same user the user's service manager is running as. If no group is set, the default group of the user is used. This setting does not affect commands whose command line is prefixed with "+".

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#User=

I would also recommend moving your script from a home directory to a standard path, like /usr/local/bin or something of the like.

You should also ensure the ordering of your connectdocker.service by giving it the After=docker.service and Requires=docker.service. As it is written the connectdocker.service is probably trying to start around the same time as the docker.service, and you'd need to wait for docker.service to be up before you can connect to it.

Requires=

Configures requirement dependencies on other units. If this unit gets activated, the units listed here will be activated as well. If one of the other units gets deactivated or its activation fails, this unit will be deactivated. This option may be specified more than once or multiple space-separated units may be specified in one option in which case requirement dependencies for all listed names will be created. Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated. Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services.

Note that this dependency type does not imply that the other unit always has to be in active state when this unit is running. Specifically: failing condition checks (such as ConditionPathExists=, ConditionPathExists=, … — see below) do not cause the start job of a unit with a Requires= dependency on it to fail. Also, some unit types may deactivate on their own (for example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not propagated to units having a Requires= dependency. Use the BindsTo= dependency type together with After= to ensure that a unit may never be in active state without a specific other unit also in active state (see below).

Note that dependencies of this type may also be configured outside of the unit configuration file by adding a symlink to a .requires/ directory accompanying the unit file. For details, see above.

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires=

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=

Related Question