After reading about issues with upgrading to DSM7 with Synocommunity Synthing installed, I uninstalled the SynoCommunity Syncthing, did the upgrade and reinstalled Syncthing from SynoCommunity.
Before adding a replicated folder (which already existing on the Synology) I checked the permissions and the local group sc-syncthing__PKG_ has read/write permissions, but after adding I get the following displayed
Loading ignores: lstat /volume1/foldername/.stignore: permission denied
Failed to create folder marker: stat /volume1/foldername/.stfolder: permission denied
Error on folder “4kDuplicates” (4kDuplicates): stat /volume1/foldername/.stfolder: permission denied
After checking available permission in “File station” I saw that I coudl add sc-syncthing which is not a local “user” as does not apear in the user list, and is not able to be added to the sc-syncthing__PKG_ group.
It’s as if the sc-syncthing “not user account” needs to be added to the sc-syncthing__PKG_ group, but hasn’t been.
Is there a way around this, or do I need to add this permission via File station?
edit: the “not a user” looks like the below in File station
I think I may have found the solution, but would appreciate if somebody could confirm.
It appears that the sc-syncthing is a a “System Internal user” account that cannot be added to a group, and if I have understood correctly the sc-syncthing__PKG_ group is no longer used.
Can the sc-syncthing__PKG_ local group be deleted?
In order to be able to set up a clean installation, it would have been good to clean up /etc/passwd and /etc/group after the deinstallation under DSM 6. After the installation in the DSM 7 there is sc-syncthing as a group and as local system user, who can then also be selected regarding the folder permissions.
Users with the endings __PKG are usually namend, since there were already similar entries are stored before the installation, or if you had already installed the SynoCommunity or Kastelo or even both package. Such names surely looks a bit ugly, but is no problem for the normal using.
The IDs of the user and the group (UID and GID) are in areas that do not allow the DSM 6 and 7 to be used easily. The UID at least is setted in a way it can be used as a local system user. Unfortunately, this is cumbersome in the DSM because you have to edit each root directory separately, while with the DSM all relevant directory rights can be assigned to users or groups in an overview and very quickly.
In contrast, those who work a lot with users and groups via the console can use sc-syncthing as usual. In this respect, the group also has its authorization and may find useful ways.
I presume that as you mentioned the UID for the first paragraph, that you mean the group for the second paragraph, however as per my previous when deployed the group is empty.
By console, I presume that you mean in a SSH console session as opposed to use the DSM console, could you please confirm.
I presume that you also mean that I could SSH to the Synology and add the local system sc-syncthing user to the sc-syncthing (in my instance currently sc-sythinking__PKG_) group, could you please confirm.
Could you also please confirm that there should be no impact if I rename the local group sc-syncthing__PKG_ to sc-syncthing.
Sorry, in the heat of the moment. Yes, user ID is UID, group ID is GID.
You can not see this type of ID in the DSM, as already mentioned, those kind cannot be used in the DSM, the number ranges must look different to see such IDs also in the DSM. In order to be able to see the IDs, the console is required, such as PuTTY or better WinSCP to open the files passwd or group. DSM does not have its own server based console, it could just be an APP, like GateOne or something similar.
Therefore it makes no sense to add the group sc-syncthing or syncthing (name in DSM 6). Such a group certainly already exists, unless it was deleted manually.
You can try to change the name to sc-syncthing manually via the console, after which a reboot is required. However, this does not work reliably because it was not done through the system. It is therefore better use the system tools to go through the console and the system. The appendix refers to DSM 6 (!), It is only intended to show what I mean by way of example:
