[Samba] access denied with "hide dot files = Yes"

[samba.20.andwin at spamgourmet.com]

> 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.