In the /etc/group I found:
syncthing:x:104555:syncthing.net
syncthing.net: x:132086:
So in reality there is a group, but not visible in DSM. But to have visible would be good.
I changed the ID of the syncthing group from 104555 to 65540 in the /etc/group, so that this group is visible in the Synology DSM.
I choose 65540 because this value was free. Now rights can easily be assigned to this group in the DSM in the DSM GUI.
For info: The Usergroup of SynoCommunity have the ID 65550.
Is that from a previous version of the SC Syncthing package, before they adopted the sc-syncthing username?
No, sc-syncthing is from SynoCommunity package and syncthing is from Kastelo package.
Possible, I don’t know when the sc- prefix was adopted. I never installed the Kastelo version on any of the two boxes though, so it must come from the SynoCommunity package.
Since I started using Syncthing from SC, I have had “sc-syncthing” in the user groups. I’ve been using this version since its inception.
I also tested on a directory whether the “syncthing” group belongs to the Kastelo package by revoking the rights from the internal system user “syncthing.net”. The peer to this directory then stopped red coloured. Then I activated the “syncthing” user group for this directory and the peer continued to work without any problems. This makes it clear to me that the “syncthing” user group is part of the Kastelo package.
In order to clear up any inconsistencies, it might be good to give the user group of the Kastelo package also the name “syncthing.net”.
Please do not. I’d rather push for SC to use the generic “syncthing” group name for the user visible stuff as well. Assigning two different groups for permissions management among two packages of the same software is the opposite of compatibility.
I think the SC package creates both groups for some reason, one internal and one for the user. That is quite inconsistent, so I will try to clear it up within SynoCommunity. The v1.4.0 release will warrant a new SPK anyway, so that would be a good occasion and we still have some time to approach compatibility from both sides.
1 Like
Why you think that? And why we have the same in the Kastelo package?
Because I´m also running the Resilio package on my servers, there is also a internal system user “rslsync”, but is not in use for any folders. This software doesnt need any activation of permissions or something like that. The availability of “rslsync” seems to make no sense.
Is possible to have also RCs as SPK packages in the future?
Potentially, at some point, if there is demand.
In my opinion, the various SPK packages for Synology on Linux are causing a mess, which I have now changed. There is one user and one group for the Kastelo and SynoCommunity packages.
Please note the conflict between assignment 114670:104555 for user “sc-syncthing” and 104555 in the group “syncthing” with relation to “syncthing.net” (!)
Installed condition
users (/etc/passwd):
sc-syncthing:x:114670:104555::/var/packages/syncthing/target:/sbin/nologin
syncthing.net:x:132086:132086::/var/packages/syncthing.net/target:/sbin/nologin
groups (/etc/group):
sc-syncthing:x:65550:sc-syncthing (will not modify)
syncthing:x:104555:syncthing.net
Modified condition
users (/etc/passwd):
sc-syncthing:x:114670:65550::/var/packages/syncthing/target:/sbin/nologin
syncthing.net:x:65540:65540::/var/packages/syncthing.net/target:/sbin/nologin
groups (/etc/group):
sc-syncthing:x:65550:sc-syncthing
syncthing.net:x:65540:syncthing.net
This means that all groups and users are also visible in Synology DSM, no longer cumbersome system users. And above all, there are clear assignments.
Today I got for one of my Synology with a Kastelo installation a update to Syncthing v1.3.4-1. Is for that a changelog available?
Our releases are announced on this forum. I am not sure if -1 suffix is ours, I suspect not. Even if it is, it’s most likely just a rebuild of 1.3.4.
There are differences in
/etc/group (change in group things - clear for me)
/etc/passwd (change in user things - clear for me)
/var/packages/syncthing.net/INFO (DSM min. version added)
etc. …
and in the package center it looks now
now is 1.3.4.1 was before 1.3.4.
Right, so it’s a re-release or 1.3.4, with just syno stuff shuffled around like discussed in this thread most likely.
I noticed, that with v1.4.0 there are modifications in the Kastelo installation regarding user and group files. So please be coordinated between the Kastelo and SynoComm. installations:
Groups:
sc-syncthing:x:65550:sc-syncthing
syncthing:x:65606:syncthing.net
syncthing.net:x:132086:
Users:
sc-syncthing:x:114670:65550::/var/packages/syncthing/target:/sbin/nologin
syncthing.net:x:132086:132086::/var/packages/syncthing.net/target:/sbin/nologin
The Kastelo entrances are the orginal one, so SynoComm can not have the same group name “syncthing” as in the orginal installation with ID 104555. So I think that SynoComm needs a review of that before of a update from v1.2.2 to v1.4.x.
I don’t think there is anyone here from the syno community here, so it’s best if you take this to their forums.
Maybe he is the support for that.
Nothing about the groups or users changed in the 1.4.0 package. However, uids and gids are assigned by the system. You may have changed them manually, but Synology isn’t a normal Linux system - /etc/passwd and /etc/group aren’t the master files for users and your changes there are likely to not persist.
Regardless, it’s perfectly fine that both packages use the syncthing group. That’s the intention.
Thats right, the changes are from v1.3.4 to v1.3.4.1