Open jokogr opened 5 years ago
You cannot login as a system internal user, DSM does not allow that. This has nothing to do with either ACL's or SMB3. Both don't have any issues at all
For granting permissions you have to use the either the group (not the user) sc-syncthing or the group you created during installation of the package.
So adding the user that you login with to those groups will fix your permissions.
@BenjV I was expecting that DSM does not allow to login as a system internal user, that's a bummer.
Let me show you an example where using a normal user is not sufficient to fix permissions:
root@nas:/volume1/syncthing/test# ll tmp
-rw-r--r-- 1 sc-syncthing sc-syncthing 640 Nov 6 2017 tmp
(this is from an SSH session to my NAS)
sudo mount -t cifs -o vers=1.0,credentials=/tmp/smb-secrets,uid=1000,gid=1000 //<NAS.IP>/syncthing /mnt/st
cd /mnt/st/test
touch filetest
This would create a file in NAS with wrong ownership and permissions (wrong as in Syncthing cannot propagate the permission to other nodes:
root@nas:/volume1/syncthing/test# ll filetest
-rwx------+ 1 joko users 0 Nov 22 20:56 filetest
And of course both the SMB client and the other Syncthing nodes have wrong permissions for that file:
joko@othersyncthingnode ~/st/test
% ll filetest
.rwxrwxrwx 0 joko 22 Nov 20:56 filetest
The same applies to the previously mentioned SMB Linux client.
If there is a file sync'ed from another node, it has sc-syncthing as owner and thus the normal user cannot alter its permissions. E.g., I have created a simple file in othersyncthingnode, it got sync'ed and if I issue from the SMB Linux client chmod, it is not working:
Original permissions:
root@nas:/volume1/syncthing/test# ll tmp
-rw-r--r-- 1 sc-syncthing sc-syncthing 640 Nov 6 2017 tmp
Try to change them from the SMB mount:
% chmod g+w tmp
chmod: changing permissions of 'tmp': Permission denied
As it can be seen, file permissions can be properly handled only if the system internal user is the owner. Since this type of user cannot login to the SMB service, I currently consider SMB shares for Syncthing as read-only and Syncthing on DSM as a backup-only mechanism.
Can anyone come up with a workaround?
Even if owner and group seems "incorrect", files have also ACL you can query with synoacltool -get
Now it would Samba server responsability to create files with expected mode and permissions. When setting up Samba share, options are available to do so: force mask, force owner, force group, inherit acl, inherit owner... See reference https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html
In DSM specific context:
I propose you to try some of these options. Please provide feedback, it sounds interesting to be documented in FAQ
I have Syncthing installed and been wondering what would be the best approach to access the sync'ed directories and preserve their permissions.
This lead me to (1) actually using SMBv1 since my Samba client is a Linux one and there are still many things to be done for CIFS ACLs on SMBv3 and (2) wanting to log in as the syncthing user (sc-syncthing).
Unfortunately the latter is not possible. My guess is that system internal users do not have credentials for Samba:
Is there a way to create manually such credentials?