Snapclient build and install from source permission issue

[gramtech]

After building and installing snapclient the service would not start.

Running
systemctl status snapclient.service

produced the following error

pi@Media:~ $ systemctl status snapclient.service
● snapclient.service - Snapcast client
   Loaded: loaded (/lib/systemd/system/snapclient.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2020-11-24 12:09:06 GMT; 1min 27s ago
     Docs: man:snapclient(1)
  Process: 447 ExecStart=/usr/bin/snapclient --logsink=system $SNAPCLIENT_OPTS (code=exited, status=216/GROUP)
 Main PID: 447 (code=exited, status=216/GROUP)

Nov 24 12:09:06 KidsRoomMedia systemd[1]: snapclient.service: Service RestartSec=100ms expired, scheduling restart.
Nov 24 12:09:06 KidsRoomMedia systemd[1]: snapclient.service: Scheduled restart job, restart counter is at 5.
Nov 24 12:09:06 KidsRoomMedia systemd[1]: Stopped Snapcast client.
Nov 24 12:09:06 KidsRoomMedia systemd[1]: snapclient.service: Start request repeated too quickly.
Nov 24 12:09:06 KidsRoomMedia systemd[1]: snapclient.service: Failed with result 'exit-code'.
Nov 24 12:09:06 KidsRoomMedia systemd[1]: Failed to start Snapcast client.

After a bit of googling and the tip with error being realted to GROUP I checked the local permissions and found this

Running
cat /etc/password | grep snap
returned
snapclient:x:998:29::/home/snapclient:/bin/bash

Note the group id of 29 as referenced later.

importantly running
cat /etc/group | grep snap
returned nothing

Note that in the script that starts the process it specified a user and group of snapclient

cat /etc/systemd/system/multi-user.target.wants/snapclient.service
returns

[Unit]
Description=Snapcast client
Documentation=man:snapclient(1)
Wants=avahi-daemon.service
After=network-online.target time-sync.target sound.target avahi-daemon.service

[Service]
EnvironmentFile=-/etc/default/snapclient
ExecStart=/usr/bin/snapclient --logsink=system $SNAPCLIENT_OPTS
User=snapclient
Group=snapclient
Restart=on-failure

[Install]
WantedBy=multi-user.target

I solved the problem by adding the following, not sure if the first command was necessary but the rest solved the problem

sudo usermod -a -G audo snapclient
The above is because the snapclient user was added to the audio group ( part of the install - not by me).
According to /etc/passwd the snapclient user had group 29 (which is the audio group) but was not in the group file as the listed user under audo group - does that make sense?
If it helps, this is the before and after the of that entry in the group file
Before
audio:x:29:pi,shairport-sync
After
audio:x:29:pi,shairport-sync,snapclient

OK, so I then ran these which is what ultimately solved the issue:

sudo groupadd snapclient
and
sudo usermod -a -G snapclient snapclient

I then started the service and it worked.

So raising here as I am not sure why it ended up in this state but maybe something needs to change in the build / install process or maybe it just helps others who have found the same issue resolve it manually.

Environment details

• OS: Raspbian
• Snapcast version - git cloned source yesterday (23 Nov 2020)

[badaix]

Did you use make or cmake?

[gramtech]

I used make

I followed
https://github.com/badaix/snapcast/blob/master/doc/build.md#build-snapclient
which is pretty straight forward apart from the dependancy on boost.

The actually command I ran to build and install was:
cd ~/snapcast/client
make ADD_CFLAGS="-I/home/pi/boost_1_74_0"
sudo make install

[badaix]

I just checked and the Snapclient install target will simply execute

adduser:
	@if ! getent passwd snapclient >/dev/null; then \
		useradd --gid audio --system snapclient; \
	fi; \

while the server makes use of the debian snapserver.postinst script

adduser:
	sh ../debian/snapserver.postinst configure

A similar script exists for the client: snapclient.postinst:

#!/bin/sh

set -e

USERNAME=snapclient
HOMEDIR=/var/lib/snapclient

if [ "$1" = configure ]; then
  if ! getent passwd $USERNAME >/dev/null; then
    adduser --system --quiet --group --home $HOMEDIR --no-create-home --force-badname $USERNAME
    adduser $USERNAME audio
  fi

  if [ ! -d $HOMEDIR ]; then
    mkdir -m 0750 $HOMEDIR
    chown $USERNAME:$USERNAME $HOMEDIR
  fi
fi

Maybe calling this script from the client make install target would fix the issue. I will try this when I have a free slot.

[hp4]

I had the same problem some time ago with snapcast and also with pulseaudio. In my understanding of the Linux-Audio-concepts, everyone who wants access to the audio-system has to be member of the group "audio".

Therefore you have to decide how you want to integrate any software in the audio-system:

• pulseaudio strongly discourages system-mode, so the pulseaudio-server ist started during local user-login. Therefore the local users have to be members of the "audio"-group, if they want to play audio. This clearly is not useful e.g. in a headless RasPi-environment.

• if you want to run additional server-software like mpd or snapserver, you face the same problems, especially if they are relying on pulseaudio: you can run it in system-mode (user root) or in a user session after login, in which case the user has to be member of the "audio"-group.

• also for clients like snapclient you have both options: you can run them as system-service in a headless environment ( in which case they should run as root or as special user like "snapclient") or as user-service during login for any user (in which case the user should be member of the "audio"-group.)

So it might be difficult for the installation/make-script to cover all those aspects.

[badaix]

I was able to reproduce the issue on my Linux Mint desktop. Using the script fixes the problem. Commit d832d45