SynoCommunity / spksrc

Cross compilation framework to create native packages for the Synology's NAS
https://synocommunity.com
Other
3.02k stars 1.23k forks source link

Is it possible to access Samba shares with system internal user credentials? #3521

Open jokogr opened 5 years ago

jokogr commented 5 years ago

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:

../source3/auth/auth.c:178: [2018/11/21 11:57:21.096823, auth 3, pid=10850] auth_check_ntlm_password
  check_ntlm_password:  Checking password for unmapped user []\[sc-syncthing]@[] with the new password interface
../source3/auth/auth.c:181: [2018/11/21 11:57:21.096925, auth 3, pid=10850] auth_check_ntlm_password
  check_ntlm_password:  mapped user is: []\[sc-syncthing]@[]
../source3/passdb/pdb_interface.c:340: [2018/11/21 11:57:21.097496, passdb 3, pid=10850] pdb_getsampwnam
  getsampwnam account sc-syncthing fail NT_STATUS_UNSUCCESSFUL
../source3/auth/check_samsec.c:440: [2018/11/21 11:57:21.097609, auth 3, pid=10850] check_sam_security
  check_sam_security: Couldn't find user 'sc-syncthing' in passdb.
../source3/auth/auth.c:328: [2018/11/21 11:57:21.097716, auth 2, pid=10850] auth_check_ntlm_password
  check_ntlm_password:  Authentication for user [sc-syncthing] -> [sc-syncthing] FAILED with error NT_STATUS_NO_SUCH_USER

Is there a way to create manually such credentials?

BenjV commented 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.

jokogr commented 5 years ago

@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:

  1. Have the syncthing directory shared through Samba with proper permissions: The normal user, the sc-syncthing user and group, they all have read/write access.
  2. (Optional) Add the normal user to the sc-syncthing group.
  3. Start synchronizing stuff from other Syncthing nodes. This would create files such as:
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)

  1. Mount the share from a NAS client as the normal user. I am using Linux here, e.g.
sudo mount -t cifs -o vers=1.0,credentials=/tmp/smb-secrets,uid=1000,gid=1000 //<NAS.IP>/syncthing /mnt/st
  1. (1st test) Create a file there:
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.

  1. (2nd test) Modify permissions of an existing file

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?

ymartin59 commented 5 years ago

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