HowTo: Autorun "spreed-webrtc-server" step-by-step

Howto autorun “spreed-webrtc-server” step-by-step


As I become struggling by trying to follow instructions like “ just need to write a simple systemd unit around it...” I realized that I am still a linux beginner, having some lack on deeper understanding of basic linux behaviour. Therefore I thought it might be helpful to write a step-by-step guide about enabling a systemd unit to autorun the spreed-webrtc-server at startup in the background. This addresses all users that aren’t measurable more experienced in linux than me :slight_smile:.


  • As I am using a current raspbian on raspberrypi for my server, this guide requires systemd to be available and used for init scripts.
  • Furthermore I assume you got the spreed server installed and running by downloading it manually from github following the nextcloud guide.
  • Struktur AG itself gives some further instructions here.
  • @SyS0p3r provides some nice step-by-step guide here in the forum on how to setup the whole debian-related system from the beginning.
  • At last I assume that you downloaded and setup the spreed server inside the /opt directory and are finally able to start and use it there:

$ cd /opt
$ wget
$ unzip
$ cd spreed-webrtc-master
$ ./spreed-webrtc-server


All credits go to @leon, as he provided the official Spreed WebRTC systemd script here and futher instructions about how to get it running. Thanks for your patience again :relaxed:!


The following steps will enable a most simple systemd unit for the spreed server without much flourish, to keep the effort as low as possible.

  1. At first we need to create a system user spreed:www-data, that will be used to start the spreed server later by the systemd unit:

$ adduser --quiet --system --ingroup “www-data” --home “/opt/spreed-webrtc-master” --no-create-home --disabled-login “spreed” 2>/dev/null || true

  1. We will create a log file and chown it to our new user to be able to write it:

$ touch /var/log/spreed.log
$ chown spreed:www-data /var/log/spreed.log

  1. We will now make the whole spreed server directory executable to the user.
    It might be possible to just make a few files executable, but at least the two binaries in server root and /bin, as well as the folders itself are not enough.

$ chmod -R 755 /opt/spreed-webrtc-master

  1. For whatever reason we need to define the server root directory in its configuration file, otherwise the service will fail:

$ nano /opt/spreed-webrtc-server/server.conf


root = /opt/spreed-webrtc-master

  1. Finally we will create the systemd unit itself and enable it to establish the service:

$ nano /etc/systemd/system/spreed.service

Description=Spreed WebRTC server

ExecStart=/opt/spreed-webrtc-master/bin/spreed-webrtc-server -c /opt/spreed-webrtc-master/server.conf -l /var/log/spreed.log


//save it
$ systemctl enable spreed.service
$ service spreed start

  1. (optional) If you use “logrotate” you could add an entry for the new “spreed.log”. Here you’ll find some more information about the possible directives. Adjust them as needed:

$ nano /etc/logrotate.d/spreed

/var/log/spreed.log {
rotate 5

  1. (optional) We could move some variables of the service file into an environment file to be accessible system wide:

$ nano /etc/default/spreed

# Defaults for spreed-webrtc initscripts

//save it

$ nano /etc/systemd/system/spreed.service

Description=Spreed WebRTC server

ExecStart=/opt/spreed-webrtc-master/bin/spreed-webrtc-server -c ${WEBRTC_CONF} -l ${WEBRTC_LOG}


You should be able to check /var/log/spreed.log after this to see if the server is up as expected. If something failed at an earlier stage of the service startup, you should see further information on /var/log/syslog.
Congratulations: Your spreedme app should be able to access the server as before from out the nextcloud web interface :thumbsup:.

Open questions

  1. As mentioned above: It might be possible to make just a few files of the server directory executable by everybody. But actually I don’t see any risk by chmod -R 755 the whole directory instead. Correct me if I am wrong.

Further information, questions, advices and criticism is highly appreciated and will be taken into account for tuning this guide.

Best regards,


  1. Removed unused variables from environment file.
  2. Added optional logrotate entry.
  3. Added necessary “root” directive to the spreed server configuration file.
  4. Made the environment file an optional step and use touch to create empty log file (thanks to @Therion7777) .

Thank you for the guide, I use it on my raspberry pi. Did you get around to checking which files need to be made executable in step 3?

Also I made a script to automate the install. It is part of a bigger project to make a complete, fast and secure set of install scripts for owncloud on raspbian. You can find it here, but as the rest is not finished you will need to replace some stuff to make it work.

Actually I thought just the two binaries spreed-webrtc-server and bin\spreed-webrtc-server should be enough, but it does not work for me. I did not try further to make single files executable so far.

Step 4, the environment file, can be left out without pain. In step 6, the service file itself, you just need to comment out “EnvironmentFile=/etc/default/spreed” and fill the variables with the related values of the environment file:
ExecStart=/opt/spreed-webrtc-master/bin/spreed-webrtc-server -c /opt/spreed-webrtc-master/server.conf -l /var/log/spreed.log
If you do not configure some other software to read or edit this variables, the environment file has actually no use ;).

Would it help to chown spreed:www-data /opt/spreed-webrtc-master or is that dangerous?

# touch /var/log/spreed.log

1 Like

Ah didn’t know that command. This is present on moreless every Linux system? As I wrote, I am Linux beginner still :sweat_smile: Will try it later and replace nano for empty file creation :slight_smile:.

Yes, its part of GNU Coreutils :slight_smile:

You could do this, but it would give the spreed user, and with it the spreed app user, all permissions on the files, where my goal is to give it less by only making some of them executable and non writable ;).

My creativity and experience is not great enough to think of what one could do with write permissions on some webrtc server, but I guess it is never wrong to limit every web service user to just the really necessary permissions.