Synology DSM 7.0 support

January 12, 2021 in bliss by Dan Gravell

bliss is running in DSM 7.0!

Synology are currently in the midst of a beta programme for the new version of their NAS operating system: DiskStation Manager 7.0.

DSM is the operating system that powers Synology NASes. It provides all the NAS services that are essential for adminstering a NAS, plus a platform that allows developers to create packages to further extend the functionality of the device.

Aside from the benefits to the users of Synology NASes that this version brings, there are a number of changes to how Synology packages work in this version of DSM.

DSM 7.0 is now shipping and we've introduced our own Synology package repository to download the DSM 7.0 version.

I'll leave the instructions/thoughts below for anyone else integrating with DSM 7.0 who might find them useful.

So, bliss is working. Technically. What I mean by that is:

I can create a new .SPK file for DSM 7.0.
Given a few pre-requisites (see below) bliss installs and runs as before.

Current pre-requisites

There are changes in DSM 7.0 which means a little more work from the installer.

Separate SPKs

An .SPK is the file that encompasses a Synology package. You can install .SPKs in two ways: by downloading them and manually installing them, or via a Package source (some call it a repository).

It’s a new requirement that the metadata embedded in an .SPK file has to be different between the pre-DSM 7.0 and DSM 7.0 versions. This means there will now be two versions of the .SPK.

This is a bit of a pain, so I’d like to introduce a Package source soon, or be featured on the official Synology Package Center. Either approach would avoid having to choose a version. Discussions are ongoing about that.

Permissions

Perhaps the biggest change in DSM 7.0 for package developers are new constraints on permissions. Before, packages often ran as root which is a superuser capable of doing anything on the NAS. Now, the package gets its own user. In our case, bliss.

What this means is that, by default, bliss doesn’t have read or write access to the Music share. This must be added via Control Panel > Shared Folder > music. Click Edit > Permissions and then change the Local users dropdown to System internal user. Find bliss and check Read/Write.

I’m hoping Synology provide a one-click “do you give permission for this app to change your music files”-style challenge…

Java

At this time, there’s no official Java package in the DSM 7.0 Package Center.

During my testing I used rednoah’s excellent java-installer to select the correct JVM. If Synology don’t provide an official package, we’ll have to do something similar.

Licences

Currently, licence information is stored in a space of storage for the user. As the user is changing from root to bliss this means licence information will be lost.

Unfortunately this means existing licences will have to be re-installed.

Technical changes

I’ve left this to last because fewer people will be interested in this. But just in case this does help other package developers, here’s a list of the stuff I had to change…

The first thing is that unless you have a Synology device capable of running Virtual Machine Manager you’re going to have to get a new device or stop supporting DSM 6.x, because you can’t downgrade from DSM 7.0 back to DSM 6.x again.

Added `os_min_ver` to `INFO`

This is a requirement for DSM 7.0:

os_min_ver="7.0-40000"

Check your temporary directories

Before, I was using the system wide temporary folder for storing some temporary files: /volume1/@tmp (volume1 changes to whatever the volume is called, which might be different on multiple drive machines).

Now, temporary folders are assigned to packages in the following manner: /volume1/@apptemp/bliss. Usefully there’s a symbolic link from the package folder to this temporary folder, so now this can be accessed in install/run scripts as: ${PKG_FOLDER}/tmp.

Don’t assume root!

It’s bad, I know, but I’d assumed /root was where I could store some user-specific files. I’ve changed that to ${HOME}.

New permissions model means unreadable/unwriteable folders

Before, I assumed I could just read/write the music share. Instead, the user must now grant permissions manually.

Something that might come in handy - you can edit these permissions on the command line with the synoshare command:

synoshare --setuser music RW + bliss

That gives bliss RW (read/write) permissions on the music folder. This can’t be run in an install script, it appears to just be ignored.

Hope that helps!