[Samba] Problems with inconsistent ACL inheritance and permissions after Samba upgrade
s.arcus at open-t.co.uk
Fri Jun 14 07:44:53 UTC 2019
On 13/06/19 17:59, Jeremy Allison wrote:
> On Thu, Jun 13, 2019 at 05:54:39PM +0100, Sebastian Arcus via samba wrote:
>>>> spite of the fact that the parent dir has full permissions for
>>>> "Domain Users" (on the Windows side).
>>> Ok - I might have at least a partial answer. Somehow the default mask in
>>> Samba still seems to be obeyed - even in AD mode. It seems to lack by
>>> default the 'write' bit - which gets removed from the permissions when
>>> creating a new directory. Without any additional share settings in
>>> smb.conf, a new subdirectory gets created with the following two sets of
>>> permissions, no matter what I try:
>>> "Domain users" - Traverse, Read attributes, Read extended attributes -
>>> This folder only
>>> "Domain users" - Full Control - Subfolders and files only
>>> If I add the following settings in smb.conf for the share:
>>> create mask = 0660
>>> directory mask = 0770
>>> Then finally the Windows permissions for a new subdirectory are as
>>> expected - just one set for "Domain Users":
>>> "Domain Users" - Full Control - This folder, subfolders and files
>>> It seems the the Samba default umask limits the ACL permissions it
>>> grants on the Windows side to new files and folders. Could this be a bug
>>> - as it doesn't seem to be mentioned anywhere in the docs?
>> Can anybody confirm if they have seen this behaviour with a Samba AD DC with
>> file sharing - where the default smb.conf umask setting (unset in smb.conf)
>> limits group ACL's assigned to subfolders - and doesn't grant group write
>> privilege - although it should?
> Try setting "obey pam restrictions = false" in [global].
> It's set to "true" by default.
> I believe the pam calls mess up the umask for smbd, known
> bug I think.
I am on Slackware, and Slackware doesn't use or have pam at all. Do you
think the above could still be applicable?
More information about the samba