samba - Sep 2022 - [lustre-discuss] Odd "File exists" behavior when copy-pasting many files to an SMB exported Lustre FS

On Thu, Sep 22, 2022 at 09:21:42AM +0000, Michael Weiser
wrote:
>
>I had a first impelementation of that attached to my first mail. Did that
get through? In my case it was enough to mask lustre.lov in flistxattr and
fgetxattr so that clients never get to see it and fsetxattr is never attempted.
No, I didn't see any code.
>What's bugging me about this approach as well as the xattr.conf
> workaround is that the error behaviour on the client side is so
> very unintuitive. How will we get people to correlate some
> "file already exists" error with peculiar extended attributes
> behaviour of their file system so they become aware they need
> to configure a workaround? It'd certainly be nice if we could
> find a way for samba to "just do the right thing"[tm].
Well in this case Lustre is acting as a malicious filesystem :-).
Inventing EA's in this manner isn't something Samba is written
to protect itself against. We expect sane filesystem behavior :-).
>The attributes using a non-existant namespace (lustre.*) doesn't seem
exactly right[tm] to me either. And it would wreak havoc if samba were actually
able to set the canonicalised user.lustre.lov attribute when copying it back,
duplicating and likely somewhat non-deterministically overwriting it later.
>
>But more crucially, what seems problematic here is that Lustre supports
> listing and reading extended attributes for unprivileged users but does
> not allow setting them and returns ENOTSUP rather than EPERM or
> something else at that.
That's a breaking of the Linux EA API contact. Don't do that.
> So samba would need to take into account that not all filesystems
> support extended attributes as a whole but might support some
> operations on them but not others.
No, that way lies insanity and unmaintainable complexity in
Samba. Blame POSIX (again) for not standarizing EA behavior.

If you have custom filesystem EA behavior the correct fix
is to write a Samba VFS module to expose only expected
behavior to the calling fileserver code.

It's what we do for every other filesystem and Lustre
just needs to do the same.
>I'm with Bjoern that there likely are or will be other
>filesystems with peculiar extended attribute behaviour.
Samba VFS modules. The only maintainable solution.
>What might be the possible fallout from removing the created
>file in the error code path? Shouldn't it be safe with proper
> locking in place as it appears to be?
>Wouldn't a best-effort cleanup in the error path be better
>than leaving a known-to-be-incorrect state behind?
When we have vfs_lustre, setting these EA's will silently
strip them off and not fail, so we don't have to change the
error code path.

Please fix your mailer to wrap at 80 columns. Reformating
your emails to reply is exhausting :-).

On 2022-09-22 at 09:38 -0700 Jeremy Allison via samba sent
off:
> > So samba would need to take into account that not all filesystems
> > support extended attributes as a whole but might support some
> > operations on them but not others.
> 
> No, that way lies insanity and unmaintainable complexity in
> Samba. Blame POSIX (again) for not standarizing EA behavior.
sorry, but POSIX is not to blame here. NFS4 ACLs are the only standardized ACL
implementation. The is no such thing as "POSIX ACLs". POSIX ACLs have
always
only been a draft. The draft was never finalized. All the UNIX falvours
implemented different draft version, this is also why it does not make any
sense to talk about a POSIX ACL standard here. Some implement for example DENY
ACEs, some don't. Some implement default ACEs, some don't. Some
implement a
access mask, some don't. All of them are completely proprietary. In our
Samba
documentation we still give the implession that POSIX ACLs are a kind of
standard. Honestly however, this is only the limited Linux proprietary version
that we document and implement.

All UNIX flavors (except for Linux however) support actually *standardized*
NFS4 ACLs. They were standardized by the same people to withdrew the previously
proposed POSIX ACL drafts.

I see more and more customers running into the limitation, that neither the
Linux SMB nor the NFS4 client implmentations satisfy their needs because NFS4
ACLs are non-existing in the Linux world and the management of NFS4 ACLs on
POSIX clients, even if supported server-side, is a pita. Frankly speaking, for
the majority of Samba fileserver setups actually Linux is no longer the
recommended platform. There is *one* good reason, why NAS vendors prefer
FreeBSD these days: the lack of NFS4 ACLs.

Bj?rn
-- 
SerNet GmbH - Bahnhofsallee 1b - 37081 G?ttingen
phone: +495513700000  mailto:contact at sernet.com
AG G?ttingen: HR-B 2816 - https://www.sernet.com
Manag. Directors Johannes Loxen and Reinhild Jung
data privacy policy https://www.sernet.de/privacy