DSM 7.0 Synology packages to install LinuxServer.io applications (using the Docker worker)

[technorabilia]

It's a long story, but please bear with me...

For the convenience of those unfamiliar with Docker, I am planning to automatically generate Synology packages for all LinuxServer.io applications (that use Docker to run).

I already have Portainer templates and docker-compose files available for those applications, so I thought this would not be such a big deal. But for some reason, I can't get it right.

Below I describe the typical installation via docker-compose and the installation via a Synology package and the problems that arise.

Installing using docker-compose

The steps are:

• Pick a user (e.g. sonarr-docker)
• Create the volume host directories as that user
• Determine PUID and PGID from that user (more info here)
• Create a docker-compose file and set the environment variables PUID and PGID

This way you are guaranteed not to get any permission problems.

Installing using a package

Sample package here. This package is broken. For illustration only. Better not use it.

In DSM 7 the packages no longer run as root user, but as a regular user (and non admin group). This is configured in the privilege file.

Packages can obtain system resources even in lower privilege identity. In DSM 7 the "Docker worker" was added where a Docker resource file is transformed to docker-compose format to create/start and stop/remove services.

In the resource file you can add volumes, ports, environment variables just like in a docker-compose file. If I understand correctly the resource file is "locked" so it is not updatable by the package installation process.

I think there are two options to set the PUID and PGID and create the volume host directories

1. Use the user from the privilege file (in this case sonarr-docker)
2. Use a different user (e.g. docker-user)

I tend to choose option 2.

Problem 1

This means I have to set both PUID and PGID using the package installation wizard and set both PUID and PGID as environment variables in the resource file. But because the file is "locked" I cannot seem to find a way to do this.

Problem 2

Another problem is that the volume host directories are created as root user which may result in permission issues.

sysop@DS716:/volume1/docker/sonarr-docker$ ls -l
total 0
drwxrwxrwx+ 1 admin users 246 Jul 10 09:04 config
drwxrwxrwx+ 1 root  root    0 Jul 10 09:03 downloads
drwxrwxrwx+ 1 root  root    0 Jul 10 09:03 tv
sysop@DS716:/volume1/docker/sonarr-docker$

Because the package runs as a regular user, it is not possible to chown the directories.

I get the feeling that Synology did not think things through. Or maybe I'm missing the obvious?

Any thoughts, ideas anyone? Thanks.

Screenshots

 

[technorabilia]

Ad 1

Maybe the safest and most logical way to process the environment variables (set here) is to use them in the resource file and let the Synology package installer itself substitute the variables. Or set the variables when the docker-compose file is used (explicitly set/export the variables or using a .env file).

"environment": [{
        "env_var": "PUID",
        "env_value": "${WIZARD_PUID}"
      }, {
        "env_var": "PGID",
        "env_value": "${WIZARD_PGID}"
      }],

Just like when the variables are available in e.g. the preinst file.

I am going to propose this solution to Synology.

What do you think?

 

[technorabilia]

In case someone ends up here with a similar problem, it is currently not possible to make changes to the resource file and resulting compose file. Which basically makes the Docker worker unusable at this point.

Synology is working on a solution. To be continued.

 

[one-eyed-king]

I hope Synology will iron out the impediments that prevent your solution to work. Its a brilliant idea!

The .env approach is the easiest, while rending the compose-file on the fly and passing it as --file - in combination with --project-name might be more flexible (especialy if a template engine with support for conditional blocks is used).