how to export permissions/ACLs from Samba share to clients?

Question

I have a Synology NAS running Samba that serves up shares in my network. I've set up autofs, LDAP and sssd and can mount Samba home directories on the fly when I log into Linux and MacOS machines.

My shares on the NAS are on an Ext4 volume, i.e. they have never been anything other than Linux files on a Linux filesystem. On the NAS they look like this:

-rwxrwxrwx+ 1 smbowner users    0 Jan 30 03:05 abc
drwxrwxr--+ 2 smbowner users 4096 Jan 30 02:37 bin
-rw-r--r--  1 smbowner users    0 Jan 30 16:43 def

However, on a Linux client they look like this:

---------- 1 netbackup netbackup 0 Jan 30 03:05 abc
drwxr-x--- 2 netbackup netbackup 0 Jan 30 02:37 bin
-rw-r--r-- 1 netbackup netbackup 0 Jan 30 16:43 def

All of the files were created on the Linux client. And they all initially had the file mode 000, like abc has in the example above. If I change the file mode on the NAS, as I did for def, the change is passed through to the client, as above (0644). However, if I do chmod 0644 on the client side, I get an error message ("changing permissions of 'abc': Operation not supported") but it does it anyway :-) and the result on the NAS is 0666.

In the listing on the NAS side, there are + signs after the file mode, indicating that the files have "syno ACLs", which are proprietary Synology ACLs. These get translated and exported to the client and look like the following when displayed on the client with getcifsacl:

~> getcifsacl def
REVISION:0x1
CONTROL:0x8004
OWNER:S-1-5-21-1620245859-1572950330-1674857983-3068
GROUP:S-1-5-21-1620245859-1572950330-1674857983-1201
ACL:S-1-5-21-1620245859-1572950330-1674857983-3068:ALLOWED/OI|CI/0x1201df
ACL:S-1-5-21-1620245859-1572950330-1674857983-1201:ALLOWED/OI|CI/R
ACL:Everyone@WORLD AUTHORITY:ALLOWED/OI|CI/R
ACL:S-1-5-88-3-33188:DENIED/0x0/
ACL:S-1-5-88-1-1034:DENIED/0x0/
ACL:S-1-5-88-2-100:DENIED/0x0/

Clearly, something is wrong here: the SIDs should have been 'idmapped' into something recognisable to a Linux user.

The autofs command (extracted from LDAP) with which the Samba share is mounted is:

-fstype=cifs,vers=3.1.1,cifsacl,perm,mapposix,user_xattr,domain=<dom>,rw,credentials=<file>,file_mode=0640,dir_mode=0750,uid=&,gid=& ://<machine>/<UNC>

My understanding is that the option cifsacl should have caused the SIDs above to be 'idmapped'. It should also have fixed the file modes too...

On the basis of what I have gleaned from various sources in the web, I have the impression that I need somehow to configure sssd (on the client?) and smbd (on the NAS?) with idmap data. My problem is that I haven't been able to find any information on how to do this in the absence of an Active Directory Domain Controller.

Are my conclusions correct thus far? And is there a way of making sssd and smbd work together to make the permissions on the NAS and on the client resemble each other? Or should I be looking at something else?

Answer 1

I'm not sure this is a proper answer in the broader sense, but to the extent that it solves my problem it is.

Discussions and recommendations in this thread and in other earlier ones (LDAP/Samba/autofs i.a.) led me to reconsider my approach. I was trying to configure a LAN consisting of MacOS clients and Unix/Linux servers with a central LDAP server for authentication, SSH access from machine to machine, some common network file system and autofs. This was triggered partially by Apple's abandonment of MacOS Server and also by Apple's (for me: inexplicable) move to SMB. A more pressing need was to re-establish a working infrastructure for Time Machine backups for the Mac OS clients, which were failing because of Apple's use of their SMBX dialect of SMB, which is not supported on the Synology NAS on which the TM backups were to be stored.

The further I got, the more Windows crud was appearing in my network, which has no Windows machines in it at all. My whole network architecture was being dictated by Active Directory, towards which I was inexorably being pushed. Given that Windows file systems are an awful match (in a purely structural sense) for MacOS and Unix/Linux anyway, using SMB simply on Apple's say-so suddenly appeared ridiculous. Samba is an amazing piece of software, but "you can't make a silk purse out of a sow's ear", as the old saying has it.

So I have started to replace SMB with NFSv4. I now have a network file system that is congruous with my MacOS and Unix/Linux filesystems and I have made more progress in the last three days than in the previous three months.

I still have the problem of providing network access for Time Machine backups, but I'll do that by attaching disks to a Mac Mini (which has been my traditional server and now has time on its hands) and letting Apple's SMB implementation handle what is a purely Apple problem.

I was trying to use SMB because the buzz I got heard off Apple and the net was that it was really the only show in town. Apple were dropping support for AFP (which doesn't really work on Unix/Linux anyway - but then, neither does SMB); and NFS was reputedly too insecure. It may well be that hacking together an SMB solution would be even more insecure, if it even worked. So, I have solved my problem for now, I hope.

Even if this isn't a proper answer :-)