samba - Jun 2016 - access denied with "hide dot files = Yes"

> On Wed, Jun 01, 2016 at 10:08:20AM +0200, samba.20.andwin at
spamgourmet.com
> wrote:
> > Hello,
> >
> > at our site we're using the revision control software Mercurial. A
> typical
> > workflow scenariao is that we have a Mercurial repository on a Samba
AD
> > Member share and the users pull and push commits to this central
> repository.
> >
> > This workflow is broken as of Samba 4.3.4. When doing certain
operations
> > (pull or push) on the central repository on the Samba share, Mercurial
> > complains that it has no access to a file in the repository and aborts
> the
> > operation, even if the user actually has full access to the repository
> (the
> > repository resides in the directory /.hg).
> >
> > It seems that the change
> > * BUG 11645: smbd: Make "hide dot files" option work with
"store dos
> > attributes = yes".
> > is related to the problem. When "hide dot files" is set to
"No", the
> > problem doesn't occur.
> >
> > The smb.conf is as follows:
> > [global]
> >         workgroup = AD
> >         security = ADS
> >         realm = xx.xxxx.xx
> >
> >         idmap config *:backend = tdb
> >         idmap config *:range = 70001-80000
> >         idmap config AD:backend = ad
> >         idmap config AD:schema_mode = rfc2307
> >         idmap config AD:range = 10000-70000
> >
> >         vfs objects = acl_xattr
> >         map acl inherit = Yes
> >         store dos attributes = Yes
> >
> >         winbind nss info = rfc2307
> >         winbind enum users = yes
> >         winbind enum groups = yes
> > [ftp]
> >         path = /home/shares/ftp/
> >         hide dot files = Yes
> >         read only = no
> >         vfs objects = acl_xattr
>
> This actually worked before due to a bug in Samba,
> which 11645 fixed to make us work the same as
> Windows.
>

I'm not familiar with Windows Servers. Do they provide an option similar to
"hide dot files"?

> When "hide dot files" is true the attribute
> returned is H, which restricts operations
> the Windows client can do to the file until
> it is removed.
>
I'd be curious what kind of restrictions these are. I still can't figure
out why Mercurial complains about "access denied" for certain files,
whereby I can edit, delete,... the very same files manually without a
problem.
>
> Prior to BUG 11645, the stored DOS attributes
> would override the H attribute, so you weren't
> actually getting correct behavior.
>
If I understand this correctly, the stored DOS attributes didn't contain
the H attribute and this did override (prior to the bug fix) the forced H
attribute from "hide dot files = yes". But if this was the case, why
did
the Windows Explorer show these files then as hidden?
>
> If you depend on accessing dot files without
> the H attribute, set "hide dot files = no".
>
Many thanks for your answers, this is what I will do. However, I'd also
like to understand the problem at hand.

On Thu, Jun 02, 2016 at 02:23:35PM +0200, samba.20.andwin at spamgourmet.com
wrote:
> 
> I'm not familiar with Windows Servers. Do they provide an option
similar to
> "hide dot files"?
No, only the 'hidden' attribute, which is either
set or not. No implicit file name conversion is
done.
> I'd be curious what kind of restrictions these are. I still can't
figure
> out why Mercurial complains about "access denied" for certain
files,
> whereby I can edit, delete,... the very same files manually without a
> problem.
You don't know what your editor is doing under the covers
without looking at a wireshark trace.
> If I understand this correctly, the stored DOS attributes didn't
contain
> the H attribute and this did override (prior to the bug fix) the forced H
> attribute from "hide dot files = yes". But if this was the case,
why did
> the Windows Explorer show these files then as hidden?
The stored DOS attributes may or may not have stored
the H attribute. The problem was that the file name
was being ignored when deciding whether to return H
or not - making the parameter non-functional in that
case.

On Thu, Jun 2, 2016 at 7:58 PM, Jeremy Allison - jra at samba.org <
samba.andwin.dacc010f26.jra#samba.org at ob.0sg.net> wrote:
>
> > If I understand this correctly, the stored DOS attributes didn't
contain
> > the H attribute and this did override (prior to the bug fix) the
forced H
> > attribute from "hide dot files = yes". But if this was the
case, why did
> > the Windows Explorer show these files then as hidden?
>
> The stored DOS attributes may or may not have stored
> the H attribute. The problem was that the file name
> was being ignored when deciding whether to return H
> or not - making the parameter non-functional in that
> case.
>
OK, so it seems that samba additionally sets the H attribute in the stored
DOS attributes when creating a dot file and having set "hide dot files
yes". So, from a users point of view, the parameter "hide dot
files" was
functional prior to bug 11645, too: Create a file beginning with a dot on
the Samba share -> Windows will report that the H attribute is set (using
attrib)
Btw, the original problem after bug 11645 can be easily reproduced using
Notepad++: Create a file beginning with a dot on the Samba share ("hide dot
files = yes" and "store dos attributes = yes"), edit it with
Notepad++ and
you will not be able to save it (Notepad++ will report that it is
protected).