Running DVR as non-admin user on Synology DSM

I’m new to Synology, myself, so I don’t have an authoritative answer. A first round of Googling didn’t turn up anything so far.

I don’t see a way to run packages from Package Center if I log in as a non-admin user, but it looks like there’s a separate http user group (available by default) for running web servers for hosting websites. Those are exposed more as services in DSM rather than normal apps, though.

I have, however, seen discussions where other users run their processes as role accounts. It just seems like this may not be a common enough use case for DSM to expose in its UI.

1 Like

Okay I can do some research too and see what the DSM developer docs say about it.

According to this discussion on the Synology forum, the third-party package Subsonic creates a user during installation that can be assigned permissions in DSM. (The relevant reply is towards the middle.)

https://forum.synology.com/enu/viewtopic.php?f=190&t=99339&p=471395&hilit=Run+package+as+user#p471395

1 Like

I found some more examples of how to do this in the documentation.

I agree this is worth having and plan to update the SPK so a separate user is used by default. Should have some time early next week.

Very cool. Thanks for looking into this!

Hello again- I wanted to ask if this was available yet in the latest package. Thanks!

Not yet. I’m going to order a Synology this week so I can figure this out.

I ran into an issue yesterday that highlighted one of the drawbacks to running as a root user:

The disk on which Channels DVR was installed (/volume1) crashed last week, but I was able to copy all of my recordings over to a new drive (/volume4) and reinstalled the Channels DVR package there. I set the DVR location to “/volume4/dvr” and the server was able to restore all of my settings from one of the backups. Everything worked until yesterday, when I rebooted the NAS.

I’m not entirely sure why, but it seems that on startup, the Channels DVR server reverted to writing recordings to “/volume1” instead of “/volume4/dvr” (I confirmed this via the UI later). Since I had removed the crashed drive, the recordings ended up being written to a folder named “/volume1” in the system partition instead of the now-gone mount point “/volume1”. The system partition soon ran out of disk space and it became impossible to log into the NAS (that’s how I first realized something was amiss). Fortunately, I had SSH enabled so I eventually diagnosed the problem and fixed it.

Can you post (or email [email protected]) the log? Would like to figure out why the path changed from /volume1 to /volume4

Fixing the root usage is still on my todo. One issue I ran into is that access to the hardware transcoder is only available as root.

The log file in the UI starts after the reboot that caused the switch to happen. Is there a longer one on disk?

Yea the full Log is on disk. You can also access http://x:8089/log?n=1000 to see more of the log

I sent an email with the logs. There’s a gap between 11/15 and 11/29 that I can’t quite explain unless the entries were being written to the folder “/volume1” (which I deleted) and the old disk before I pulled it.

Hi @tmm1 - Just wondering if there was any update here? I'd like to change the Channels DVR user on my Synology. Not only for security as mentioned above, but also because you can allocate a maximum amount of space per user. This would allow me to create a Channels user with X gb of storage and will prevent the DVR directory from growing too large.

I just switched to a new Synology for my DVR, but see that it is still running as root and ignoring the quota I set for the drive. Based on the dates, I'm guessing this goal was abandoned, but I would love to see this fixed. Seems like running anything as root is not a great security practice.

If you were able to set a quota for a particular user and DVR ran as that user, your DVR would crash and fail whenever it hit the quota.

That is true, but it might at least prevent the DVR from using up the entire disk and making DSM entirely unusable! (I ran into that problem early on as well with the DVR server and there is a post somewhere about it.)

You could always use newer Synologys' ability to run Docker, and use the --user option to run the container as a restricted user. Couple this with a shared group to facilitate access to recordings outside of the container, and you've got a pretty flexible and partitioned scheme.

I vaguely remember when I was running Plex on my Synology.
I know it ran under the username 'plex' and if the NAS's CPU supported Intel Quick Sync it could do hardware transcoding.
I think it used VAAPI on my Synology.

I know the OP is quite old, but the same issue remains, so...

I, too, asked for this long ago. The Synology NAS is running Linux, so it shouldn't be too awfully difficult. You could probably do it, yourself, with a bit of experimentation.

The Linux package I briefly ran on our LAN server was the same: Installed and ran as "root." I fixed it myself. Near as I can tell, here's what I did:

  1. Installed package normally & ran it to check functionality
  2. Stopped the package
  3. Created "channels" user and groups
  4. Found all files and directories created by channels and changed their ownerships to channels:channels.
  5. Set all channels directories to "sgid channels"
  6. Set file access controls on all channels directories for good measure (see below)
  7. Altered the startup script to "setuid channels" and "setgid channels"

For steps 4 through 6:

Channels was installed in /opt. Since the /home filesystem had the most space, I put channel's data store in there. Then I ran...

#!/bin/sh

for eaBase in /opt /home
do
    cd /$eaBase || exit

    chmod ug+s channels

    # Set user & group owner perms and defaults
    find 'channels' ! -user channels |xargs -i chown channels {}
    find 'channels' ! -group channels |xargs -i chgrp channels {}

    find 'channels' -type d -print |while read pathName
    do
        echo "directory: $pathName"
        chmod 775 "$pathName"
        chmod g+s "$pathName"
        setfacl --set=user::rwx,group::rwx,other:r-x "$pathName"
        setfacl -m d:u::rwx,d:g::rwx,d:o:r-x,d:m:rwx "$pathName"
        setfacl -m d:u:myusername:rwx "$pathName"
    done
done

Restarted the channels daemon and it ran like a champ.

The "myusername" facl was to allow me to poke around in channels' files and directories as me, so I wouldn't have to do it as root (running as root is like driving without seatbelts) or su/sudo to channels:channels. Merely a convenience feature and entirely optional.

The bigger problem for Channels' developers is existing installs. It will be tricky correcting them w/o trashing them in the process.

Other things one maybe could do...

  1. Run Channels under Docker. (But Docker has its own issues, so I'm not certain that's a win.)
  2. Maybe could chroot Channels. (That's quite involved, though.)

A DSM7 compatible spk is available on https://getchannels.com/dvr-server/#synology

It no longer runs as root.

3 Likes