Behaviour mismatch between "store dos attributes" and "map archive" from man smb.conf(5)
jra at samba.org
Wed May 13 18:42:33 UTC 2020
On Wed, May 13, 2020 at 04:42:30PM +0530, Anoop C S via samba-technical wrote:
> Following is a question I have regarding the interaction between two
> smb.conf parameters mentioned in the $subject. It can very well be a
> misunderstanding from my side.
> We have both "store dos attributes" and "map archive" set to 'yes' for
> default install. But according to its description man smb.conf(5):
> store dos attributes (S)
> . . .When this parameter is set it will override the parameters map
> hidden, map system, map archive and map readonly and they will behave
> as if they were set to off. . .
> My question is around smb2.read.access torture test where it tries to
> open a file with different access flags including SEC_FILE_EXECUTE.
> When run against a share with "map archive = no"(or implicitly assumed
> by "store dos attributes" set) we cannot expect execute bit to be
> present for the owner. Thanks to Ralph(and Michael, Guenther) who
> helped me understand basic selftest architecture which adds
> vfs_acl_xattr in [global] section for many torture tests including
> smb2.read making it pass with `make test`.
> Nevertheless, leaving "store dos attributes" at its default, why would
> smbd create file with execute bit set for the owner? I hope its not
> because of some umask calculation done at the end outside Samba because
> if that's the case I would expect it to be set even when "map archive"
> is explicitly set to 'no'. There seems to be some mismatch between
> assumed and real behaviour.
Quick check - does your smb.conf have "obey pam restrictions = yes"
set anywhere ?
That can mess up our mask calculations. Let me know that parameter
is set to "no" before I dig in further :-).
More information about the samba-technical