Syncthing update deletes syncthing user and has permissions issues

[cmangla]

Setup

Package Name: Syncthing
Package Version: 0.14.49-15

NAS Model: DS213
NAS Architecture: armv5tel
DSM version: DSM 6.2-23739 Update 2

Expected behavior

Package update should correctly deal with custom configurations.

Actual behavior

• The Synthing icon has disappeared from the Main Menu (top left button on main screen)
• In Package Centre > Syncthing, the URL shown has port 8384. This is the default Synthing port, but I've changed it to a different one. The running Syncthing process is using my specified port (not 8384). So the URL shown is incorrect. Port number should be read from the configuration file.
• The 'syncthing' user that existed before the update has been deleted. I would have preferred to keep that user even when it is not used by the package.
• Syncthing web interface displays an error message "xxx | error while traversing /volume1/syncthing/xxx/xxx: permission denied"

Steps to reproduce

1. Install the Syncthing update
2. Follow displayed instructions on setup for sc-syncthing
3. Fix the firewall settings in-case the settings for Syncthing are incorrect after update

Package log

/usr/local/syncthing/var/syncthing_install.log_

Tue Aug  7 14:17:11 IST 2018
===> Step preupgrade. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Tue Aug  7 14:17:28 IST 2018
===> Step preinst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Tue Aug  7 14:17:30 IST 2018
===> Step postinst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Installing service configuration /var/packages/syncthing/conf/syncthing.sc
Adding 'sc-syncthing' to 'sc-syncthing'
Group Name: [sc-syncthing]
Group Type: [AUTH_LOCAL]
Group ID:   [65538]
Group Members: 
0:[syncthing]
1:[xxx]
2:[sc-syncthing]
Invoke service_postinst
Granting 'sc-syncthing' unix ownership on /volume1/@appstore/syncthing/var
Tue Aug  7 14:17:36 IST 2018
===> Step postupgrade. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Granting 'sc-syncthing' unix ownership on /volume1/@appstore/syncthing/var

/usr/local/syncthing/var/syncthing.log_

Starting syncthing command /volume1/@appstore/syncthing/bin/syncthing -home=/volume1/@appstore/syncthing/var

[BenjV]

These are all changes due to the fact that the SynoCommunity made the packages suited for DSM 6 in a new framework.

DSM 6 packages are running as a hidden user and permissions have to be granted via the groups sc-media and/or sc-download.
See the wiki for more information.
https://github.com/SynoCommunity/spksrc/wiki/Permission-Management

Port changes are not supported by DSM, so you have to use the port that is configured during the package installation.

Disappearing icons are mostly due to the fact that only for the admin a icon is placed by default on the desktop, for all other users you must first give permissions via the privileges wizard in the control panel.
Please read the help on your Nas for this kind of information.

On a more personal note:
I tried to use syncthing for a while when BittorrentSync (now called Resillio) went commercial and is a very crappy build peace of software which also uses enormous amount of resource from your Nas.
You could do much better to use the tools provided by Synology like "Drive" and 'Cloud Sync".

[Techwolf12]

After upgrading syncthing didn't seem to start, so I went to look for the cause:

sc-syncthing@Groot:~$ /var/packages/syncthing/scripts/start-stop-status
/var/packages/syncthing/scripts/service-setup: line 6: [: : integer expression expected

Line number 6:

if [ -n "${SYNOPKG_DSM_VERSION_MAJOR}" -a "${SYNOPKG_DSM_VERSION_MAJOR}" -lt 6 ]; then EFF_USER="${SYNOUSER_PREFIX}${USER}"; else EFF_USER="${PRIV_PREFIX}${USER}"; fi

It seems something in this isn't correct. This is the case for two Synology servers with this package installed.
My workaround was replacing the line with (as user svc-syncthing doesn't exist):

EFF_USER="sc-syncthing"

Then, I managed to get this error and the home path was incorrect:

root@Groot:/var/packages/syncthing/target/bin# /var/packages/syncthing/scripts/start-stop-status start
/var/packages/syncthing/scripts/start-stop-status: line 43: start-stop-daemon: command not found
Starting  ...
/var/packages/syncthing/scripts/start-stop-status: line 27: start-stop-daemon: command not found

Which was fixed by adding this line at the top of /var/packages/syncthing/scripts/service-setup:

PATH=$PATH:/var/packages/syncthing/target/bin
SYNOPKG_PKGDEST=/var/packages/syncthing/target
export SYNOPKG_PKGDEST

Yep, you guessed it, onto the next issue:

[monitor] 09:18:07 INFO: Starting syncthing
[start] 09:18:07 INFO: Generating ECDSA key and certificate for syncthing...
[start] 09:18:07 FATAL: save cert: open /var/packages/syncthing/target/var/cert.pem: permission denied
[monitor] 09:18:07 INFO: Syncthing exited: exit status 1

No permissions at all? More files seem to have this.
---------- 1 sc-syncthing syncthing 615 Mar 19 09:22 /var/packages/syncthing/target/var/cert.pem
Anyways, as root, run: chmod -R ug+rw /var/packages/syncthing/target/var

[CQYFP] 09:25:22 FATAL: Error opening database: open /var/packages/syncthing/target/var/index-v0.14.0.db/LOCK: permission denied (is another instance of Syncthing running?)

I don't seem to be able to setup the permissions correctly for this...
Any help would be appreciated!

[ymartin59]

For command line start / stop / status, it is now required to use Synology tool or else set few documented environment variables: https://github.com/SynoCommunity/spksrc/wiki/Frequently-Asked-Questions#how-to-query-package-status-or-start-from-command-line

Our framework and packages are far complex enough to also support custom service port. Desktop icon is generated with default service port as documented in https://github.com/SynoCommunity/spksrc/wiki/SynoCommunity-Used-Ports

I have no idea what happened to "var" content which is supposed to be properly handled at upgrade.

I propose you check there is no "syncthing" process running before removing /var/packages/syncthing/target/var/index-v0.14.0.db/LOCK file and start again with synopkg start syncthing.

Please report log file content then. In case you upgraded from DSM 4.x, it is important to migrate Shared Folder with "Windows ACL" support - see https://github.com/SynoCommunity/spksrc/wiki/Permission-Management for details.

[cmangla]

Before the update, the icon from the Main Menu and the link from package centre worked fine with my custom service port (I think, I have no means of confirming this). The icon has now entirely disappeared.

[Techwolf12]

I manually removed the lock file and started the package with synopkg:

root@Groot:~# synopkg start syncthing
package syncthing start successfully
root@Groot:~# synopkg status syncthing
syncthing package is started
(Waiting for about 10 seconds)
root@Groot:~# synopkg status syncthing
syncthing package is stopped
Status: [3]

Same error

[CQYFP] 15:46:34 FATAL: Error opening database: open /var/packages/syncthing/target/var/index-v0.14.0.db/LOCK: permission denied (is another instance of Syncthing running?)
[monitor] 15:46:34 INFO: Syncthing exited: exit status 1

File doesn't exist:

root@Groot:~# ls -l /var/packages/syncthing/target/var/index-v0.14.0.db/LOCK
ls: cannot access /var/packages/syncthing/target/var/index-v0.14.0.db/LOCK: No such file or directory

As the sc-syncthing user, I can't access this folder:

sc-syncthing@Groot:~/var$ ls -ld index-v0.14.0.db
drw-rw---- 1 sc-syncthing syncthing 45584 Aug 10 09:26 index-v0.14.0.db
sc-syncthing@Groot:~/var$ cd index-v0.14.0.db/
-sh: cd: index-v0.14.0.db/: Permission denied

[BenjV]

@cmangla
As @ymartin59 already said, custom ports are not supported due to new demands of DSM 6.
Default port will be set at package installation and changing them in the application software will not will not function any more.

@Techwolf12
Starting script from the commandline will not function, the scripts rely on availability of environment variables which are not available without using the package center.
Changes are great that you end up with half an installation that cannot be uninstalled anymore, so please don't do it.

Don't mess with the user, the DSM 6 packages are running as an hidden user and cannot be used for setting permissions.
Read the wiki for permission problems.
https://github.com/SynoCommunity/spksrc/wiki/Permission-Management

[cmangla]

@BenjV The custom port was working perfectly fine in DSM 6 before the Syncthing package update. Even now, I am using a custom port, which still works. I just need to manually add that to the firewall. The previous package added an icon to my Main Menu, which I could simply click to open the Syncthing interface in a new tab, with my alternative port. I think that worked out of the box, but it is possible I hacked it in a long time ago and forgot about it.

[BenjV]

The icons and the firewall setting are set during package installation and cannot be changed.
The package center simply has no functionality to support that.

Of course you can hack into the system and change things, but the point is that with a next upgrade of DSM you have a good change that things are not working anymore.
And when you do an upgrade of a package you get this kind of problems, so please don't do it.

And changing the port is completely useless, what use would it have?
The only thing you can accomplish that you use a port that is in use by another application, which will create problems.

[Techwolf12]

@BenjV The problem is that the package already didn't work after upgrading, if was working I wouldn't be messing with it.
I manually ran it from the sc-syncthing user, the one with the right permissions. I cannot convert a system folder to Windows ACL from the interface as you don't get that option.

I've manually created a user, gave permissions to the folder in appstore via a chown, ran the program via Task scheduler and it works. If someone finds out what the issue with the package is, I would love to hear it.

[BenjV]

If you don't get that option then it is already supporting ACL's
And messing with the user is not the solution.
As I said before manually running a package does not work.
DSM 6 does not allow you to set permissions via its user, only via groups as you can read in the wiki.

In stead of giving all kind of information what happens when you try to start it manually, you should post the log files from a normal installation/start of the package.

Just now I installed syncting and started it without any problem.
You probably have configured folders and files that do not have the correct group permission.
Correct that and try angain.

[Techwolf12]

root@Groot:/volume1/@appstore/syncthing# cat var/syncthing_install.log
Thu Aug  9 20:59:08 CEST 2018
===> Step preupgrade. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Thu Aug  9 21:02:03 CEST 2018
===> Step preinst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Thu Aug  9 21:02:04 CEST 2018
===> Step postinst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Installing service configuration /var/packages/syncthing/conf/syncthing.sc
Adding 'sc-syncthing' to 'sc-syncthing'
Group Name: [sc-syncthing]
Group Type: [AUTH_LOCAL]
Group ID:   [65540]
Group Members:
0:[syncthing]
1:[sc-syncthing]
Invoke service_postinst
Granting 'sc-syncthing' unix ownership on /volume1/@appstore/syncthing/var
Thu Aug  9 21:02:05 CEST 2018
===> Step postupgrade. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Granting 'sc-syncthing' unix ownership on /volume1/@appstore/syncthing/var

Here is the install log, as we can see from "Granting 'sc-syncthing' unix ownership on /volume1/@appstore/syncthing/var", the script tries unix permissions instead of ACL. Which is correct. The issue is NOT with the shared folders and their permissions.

Manually running works, running via the package doesn't.

If you don't get that option then it is already supporting ACL's

Or the folder isn't supposed to use ACL, as it is a system folder. Not accessible from the web-interface.

In stead of giving all kind of information what happens when you try to start it manually, you should post the log files from a normal installation/start of the package.

See the install log above and the other logs in my previous comments which might contain valuable info for the developers.

Just now I installed syncting and started it without any problem.

Fresh install? This was an existing install that was upgraded. I believe the issue is in the user change.

[BenjV]

/volume1/@appstore/syncthing/var is the installation folder for the software and there just linux permissions are used.

If you have a problem with an upgrade then the shared folders you are using don't have the correct permissions.
Please correct that as described in the wiki.
Not only ACL has to be activated for the share, but also the group "sc-scynthing" has to be given read/write permissions on that folder(s).

If there are existing folder(s), subfolder(s) and file(s) you have to grant the group "sc-syncthing" read/write permissions via FileStation to those.
Subfolders and files inherit the permission from the parent folder but if they are already existing you have to correct that.

[Techwolf12]

/volume1/@appstore/syncthing/var is the installation folder for the software and there just linux permissions are used.

Exactly, this is where the issue is at, not the shared folders. I was modifying the permissions of this folder to get it working.

[BenjV]

Not possible because the install script set the permission correct for those folders during the upgrade.
Most likely you messed it up yourself by tring to do things manual.

I advise you to uninstall synthing and do a fresh install to be sure you did not mess up more.

On a personal note, syncthing uses far to much resources to my opinion, the standard tools from Synology do a much better job than syncthing.

[Techwolf12]

I advise you to uninstall synthing and do a fresh install to be sure you did not mess up more.

Reinstalling is a fix yes, however the package needs to be fixed so an upgrade would just work (#3058). The package upgrade messed itself up.

Not possible because the install script set the permission correct for those folders during the upgrade.
Most likely you messed it up yourself by tring to do things manual.

Nope, sorry, it didn't. Which is why I started to fix this manually.

I'm thinking you are not getting this issue at all, so let's clear the discussion for the developers so they can fix the upgrade script :)

[BenjV]

I understand perfectly what you are saying but your conclusion is simply wrong.

When the package center does an upgrade it saves certain (config) files to a temp directory and then removes the complete installation.
Then a clean install is performed and the saved files are put back in place.
So there is no difference between an normal install and an upgrade as far as the application permission to its folder is concerned.

[ymartin59]

@Techwolf12 The reason of file permissions mess is that you have run /var/packages/syncthing/scripts/start-stop-status start as root whereas it is now designed to be run as non privileged service account provided by DSM 6 framework.

Conclusion: I have to improve script to fail if invoked as root when not expected