OSX SMB Clients: The operation can’t be completed because the item “” is in use.

Status
Not open for further replies.

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
Honestly, I don't know what it adds. This is just some info that I have that I shared.

I agree that bugs shouldn't be worked around, but fixed. Unfortunately I'm guessing AFP has some kind resource needs that make "being in the know" non trivial. :/

There may be special code in the acl_tdb and acl_xattr modules to handle the aapl context that didn't make it into zfsacl. Apart from that "acl_tdb" also silently sets "inherit acls = yes" in the smb.conf. This will probably also change behavior a bit. In addition to this the defaults in FreeNAS probably handle the "creator owner" and "creator group" ACEs differently than under acl_tdb.

Per samba mailing list:
1) client> query the existing sd
2) server> compute sd with DACLs, add MS NFS SIDs when enabled by AAPL
context
3) client> check and pontentially modify MS NFS SID(mode), send
otherwise *unmodified* sd back to server
4) server> a) apply DACL from sd
b) chmod() with the request MS NFS mode
So for a file with no excplitic ACEs, the server will nevertheless
generate a DACL with ACEs in NT form. The client sends them back and
when the server applies them, the resulting file explodes into a set
of complex ACEs, where all we wanted is a simple change of the UNIX
mode. :(

There are three possibly implementation choices how we can deal with
that, all have in common that as a first step (iirc in
source/smnb/nttrans.c:set_sd()), *before* going into the VFS with
set_nt_acl(), we check whether a set_sd() request contains a MS NFS
SID with a UNIX mode. If it doesn't, we don't care and the code
proceeds as usual. If it does, we can either:

1) ignore the NT ACL and apply the mode by calling SMB_VFS_CHMOD() [1]

2) remove the MS NFS SIDs from the DACL, apply DACL, apply mode

3) apply the unmodified DACL, then apply the mode

Implementation 1) seems like a natural choice given that it matches
exactly the given use case: an OS X client wanting to do a
chmod(). But there's a serious drawback: if we follow that route,
we've preclude any future use of set_sd() requests containing both MS
NFS SIDs *and* a new or modified DACL. We therefor choose to reject
option 1).

Implementation 2) looks like a good way out of this, unfortunately
after removing the MS NFS SIDs from the DACL, VFS modules (or the
default backend) have no way of knowing the request originated from a
"AAPL chmod() request", resulting in not-roundtripped-ACL-explosion in
the case of POSIX ACLs.

We need a way for the VFS modules to detect these requests and act
accoding to what makes most sense for the module, which in the case of
POSIX ACLs is ignore the DACL request. This is implementation 3) and
this is what the attached patchseries does.

I've checked and modified all VFS modules (and the default backend)
that needed a change to either completely ignore set DACL requests
(POSIX ACLs), or just skip the MS NFS ACEs (all modules that use
nfs4_acls.c, eg vfs_zfsacl, vfs_gpfs).
http://samba.2283325.n4.nabble.com/...-Mac-OS-Mavericks-uber-slow-td4672582i20.html

So there's also a difference in the way that MS NFS ACEs are used by the AAPL SMB2 extensions is handled depending on whether you're using zfsacl or acl_xattr / acl_tdb. It's always possible that ignoring NFS ACEs is causing the problems you observed (or if samba's being sneaky and trying to change mode bits). If it is trying to change mode bits, then based on well-established FreeNAS lore, the OSX client has commited a mortal sin and its blood is on its own head.
 
Last edited:
Status
Not open for further replies.
Top