We just noticed an annoying misfeature with smbd... If you have "vfs objects" enabled (even an empty list) in smb.conf then Windows clients trying to access files and/or attempting to read the security permissions of an object protected just with plain Unix permission bits (no ACL) will find that any Group Write permissions silently will be lost. If you disable the "vfs objects" feature (comment-out or remove completely) then things work correctly... The output from smbcacls also look a bit funny: With 'vfs objects' enabled, server on FreeBSD: % /liu/bin/smbcacls -k -m SMB3 //filur00/tmp test/hello.txt REVISION:1 CONTROL:SR|DP OWNER:AD\peter86 GROUP:AD\UF-ITI-All ACL:AD\peter86:ALLOWED/0x0/RWPO ACL:AD\UF-ITI-All:ALLOWED/0x0/0x0012008f ACL:Everyone:ALLOWED/0x0/0x00120088 Server on Linux (CentOS 7, with 'vfs objects' enabled): % smbcacls -k -m SMB3 -U peter86 //probe-g.it.liu.se/tmp test/hello.txt REVISION:1 CONTROL:SR|PD|DP OWNER:AD\peter86 GROUP:AD\employee-liu.se ACL:AD\peter86:ALLOWED/0x0/0x001e01ff ACL:AD\employee-liu.se:ALLOWED/0x0/0x001e01ff ACL:Everyone:ALLOWED/0x0/ With no 'vfs objects' in the smb.conf file things look right: % /liu/bin/smbcacls -k -m SMB3 //filur00/tmp test/hello.txt REVISION:1 CONTROL:SR|PD|DP OWNER:AD\peter86 GROUP:AD\uf-iti-all ACL:AD\peter86:ALLOWED/0x0/RW ACL:AD\uf-iti-all:ALLOWED/0x0/RW ACL:Everyone:ALLOWED/0x0/ Directory on the FreeBSD server: # ls -la /tmp/test total 50 drwxrwx--- 2 peter86 uf-iti-all 3 Feb 27 11:27 . drwxrwxrwt 10 root wheel 56 Feb 27 21:10 .. -rw-rw---- 1 peter86 uf-iti-all 6 Feb 27 11:27 hello.txt Directory on the CentOS server: # ls -la /tmp/test total 8 drwxrwx--- 2 peter86 employee-liu.se 23 Feb 27 21:15 . drwxrwxrwt. 12 root root 4096 Feb 27 21:17 .. -rwxrwx--- 1 peter86 employee-liu.se 6 Feb 27 21:15 hello.txt We see this behaviour on atleast Samba 4.9.4 on FreeBSD 11.2 and Samba 4.8.3 on CentOS 7.
Hmm... A drat. I forgot that comments can only be started at the beginning of a line in the config file. (I've been burned by it before). vfs objects = ;; shadow_copy2 zfsacl full_audit doesn't do quite what I thought. :-) Anyway, it seems the culprit is the "zfsacl" vfs module. With it enabled I see this behaviour for non-ACL-protected folders (on a ZFS filesystem) on our FreeBSD-with-ZFS servers.