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

[MrAkai]

Hello!

We are running into what seems to be a long-standing error between OSX and SAMBA based SMB/CIFS servers.

When copying files (usually images or media files, but maybe that is because that is what we predominantly use) in OSX Finder, our users are often presented with the error: The operation can’t be completed because the item “[item name]” is in use.

Using google-fu this seems like something people have been fighting with since apple moved away from SAMBA to their own SMB stack.

We've followed all of the suggestions out there (most of which are forcing CIFS(SMB1) which we do at both the server and client level) with no luck.

If we use a program other than finder to copy then the copy works just fine, so what we believe is happening is the finder is trying to open the files r/o after they are created but before data is copied, which causes this error. (in my debugging, the way OSX finder creates a file is to open/close a 0 byte file and then open it with append to write data, so I think the r/o access is happening in that interval between the initial creation and append)

I'm wondering if there is a configuration level solution on the FreeNas/Samba side that could help?

There are some older threads I've found but none of them seem to have reached a resolution. If this has been solved I apologize for wasting time.

Thanks!

Tech Details:
FreeNAS-9.3-STABLE-201602031011 on a SuperMicro based system with 256GB RAM and ~450TB usable space, using AD as auth source.

 

[dlavigne]

Not that I'm aware of. If you manage to find something, please add to your thread.

 

[anodos]

Post the contents of /usr/local/etc/smb4.conf.

It could be that finder is getting held up while trying to generate a resource fork / ADS.

 

[MrAkai]

I put the smb4.conf here:
http://pastebin.com/QB55VGL1

I deleted some of the shares and changed the workgroup and domain to "MYCOMPANY" but I don't think there's any other proprietary info in there (I hope ;-) )

This started out as a 9.2 system updated to 9.3 so there could be some cruft that the update vs a clean install.

Thanks!

 

[anodos]

A few comments about parameters:
"veto oplock files" - are you sure you need this?
"nt acl support = no" - why are you doing this?
"reset on zero vc = yes" - ditto
"acl group control = yes" - ditto
"force create | directory mode" - ditto
"aio read size | write size | write behind" - ditto

Try enabling the "streams_xattr" vfs object on all of your shares

 

[MrAkai]

Thanks!

As for the options you asked about, here is why they are there:
"veto oplock files" -> We are 95% mac with a handful of windows machines in one department. We were finding that shared excel sheets would have weird locking issues if opened on both a mac and a PC (both connected over SMB). This resolved that.
the "nt acl support" was similar I think the windows computers were setting ACLs properly but the macs were not, but turning of nt acls the zfs facls took over.
The rest were either attempts for force company policy (group read/write on all files and folders by default for example) or speed things up (probably taken from various optimizing samba web pages).

I'll try adding the streams_xattr to everything and let you know how it goes.

Thanks!

 

[MrAkai]

Okay so I added streams_xattr to the shares and we had a big problem.

Any files with a resource fork (basically anything saved out of Adobe) at this point were corrupted, with the resource fork either being prepended to the file or overwritting the first chunk of the file. I haven't figured out which.

If we use the "nsmb.conf" file on the mac client to specify streams=no then the ._XXX files are created and all is well, but when streams are enabled on the OSX client, the file is corrupted seemingly irreparably.

Could this be related to ZFS on FreeBSD not supporting xattr or is that something else?

# zfs get xattr vol1/webimages
NAME PROPERTY VALUE SOURCE
vol1/webimages xattr off temporary

# zfs set xattr=on vol1/webimages
property 'xattr' not supported on FreeBSD: permission denied

Thanks!

 

[anodos]

Okay so I added streams_xattr to the shares and we had a big problem.

Any files with a resource fork (basically anything saved out of Adobe) at this point were corrupted, with the resource fork either being prepended to the file or overwritting the first chunk of the file. I haven't figured out which.

If we use the "nsmb.conf" file on the mac client to specify streams=no then the ._XXX files are created and all is well, but when streams are enabled on the OSX client, the file is corrupted seemingly irreparably.

Could this be related to ZFS on FreeBSD not supporting xattr or is that something else?

# zfs get xattr vol1/webimages
NAME PROPERTY VALUE SOURCE
vol1/webimages xattr off temporary

# zfs set xattr=on vol1/webimages
property 'xattr' not supported on FreeBSD: permission denied

Thanks!

FreeBSD supports extended attributes. https://www.freebsd.org/cgi/man.cgi?query=getextattr
The size of resource forks supported with streams_xattr is extremely limited (I believe 64kb). This can be a problem with apps that want to write a large amount of data as a resource fork (like adobe products). You should look into properly configuring the vfs_fruit for improved OSX compatibility. This requires enabling the streams_xattr, catia, and fruit vfs objects.

For more info on VFS_fruit and its config see here: https://github.com/zentyal/samba/blob/master/docs-xml/manpages/vfs_fruit.8.xml

 

[MrAkai]

Thanks for the info.

I wasn't sure on xattr support because the getextattr man page doesn't mention zfs and trying to turn them on results in an error message from zfs, so I just wanted to make sure I wasn't barking up the wrong tree entirely.

Some of the files that are corrupting are type 1 fonts (which are stupidly stored as 0 byte data+ resource) and the resource forks on those are right around 32k.

We'll do some testing with 9.10 and vfs_fruit and I'll update this thread with the results.

In the meantime, the client who was having the most issues stopped having issues when streams=no was added to his nsmb.conf file, so we're at least not corrupting work anymore.

Thanks again for all your help.

 

[anodos]

Thanks for the info.

I wasn't sure on xattr support because the getextattr man page doesn't mention zfs and trying to turn them on results in an error message from zfs, so I just wanted to make sure I wasn't barking up the wrong tree entirely.

Some of the files that are corrupting are type 1 fonts (which are stupidly stored as 0 byte data+ resource) and the resource forks on those are right around 32k.

We'll do some testing with 9.10 and vfs_fruit and I'll update this thread with the results.

In the meantime, the client who was having the most issues stopped having issues when streams=no was added to his nsmb.conf file, so we're at least not corrupting work anymore.

Thanks again for all your help.

Forgot to mention that you will have to enable "fruit" on all shares on the server. Mixing shares with and without fruit will globally disable the SMB2 AAPL extensions if the first tcon is without fruit.

 

[MrAkai]

So on my test box 9.10 with vfs fruit and streams_xattr are working quite well.

The "Get Info" on the SMB connection even says "SMB (OSX)" instead of "SMB (Unknown)"

I did have a question about using the "catia" vfs. Looking at the man pages/etc it seems to be exclusively for people using the Catia CAD software.

If that software is not in use, is it still recommended to be used?

Thanks!

 

[anodos]

So on my test box 9.10 with fruit and streams_xattr are working quite well.

The "Get Info" on the SMB connection even says "SMB (OSX)" instead of "SMB (Unknown)"

I did have a question about using the "catia" vfs. Looking at the man pages/etc it seems to be exclusively for people using the Catia CAD software.

If that software is not in use, is it still recommended to be used?

Thanks!

The man page is out of date. See fruit manpage here:
https://github.com/zentyal/samba/blob/master/docs-xml/manpages/vfs_fruit.8.xml

 

[Henning Kessler]

Hi there,

could some please be so kind and could give a glance at an example configuration? Even after reading the man page I am kind of unsure how to configure an smb share on a FreeNAS device for max compatibility with OS X clients.

this here would be my guess:

Selected VFS Objects:
aio_pthread
streams_xattr
catia
fruit
netatalk

Auxiliary Parameters:
fruit:resource = file
fruit:metadata = netatalk
fruit:locking = none
fruit:encoding = native

Is this correct?

And by the way did someone already tried to implement Spotlight on FreeNAS devices with Tracker?

Regards

Henning

 

[anodos]

Hi there,

could some please be so kind and could give a glance at an example configuration? Even after reading the man page I am kind of unsure how to configure an smb share on a FreeNAS device for max compatibility with OS X clients.

this here would be my guess:

Selected VFS Objects:
aio_pthread
streams_xattr
catia
fruit
netatalk

Auxiliary Parameters:
fruit:resource = file
fruit:metadata = netatalk
fruit:locking = none
fruit:encoding = native

Is this correct?

And by the way did someone already tried to implement Spotlight on FreeNAS devices with Tracker?

Regards

Henning

If you intend to use fruit, you need to set the following parameters on all of your samba shares:
VFS Objects - fruit, streams_xattr, catia

Do not enable vfs_netatalk. aio_pthread is neither here nor there since you don't have samba's AIO actually enabled.
I think you can safely get rid of all those auxiliary parameters (they are for the most part defaults).

 

[Henning Kessler]

Hi anodos,

thanks for your advice. Did you already had some experiences with:

fruit:resource = xattr

· xattr - use a xattr, requires a filesystem with large xattr support and a file IO API compatible with xattrs, this boils down to Solaris and derived platforms and ZFS

Regards

Henning

 

[Henning Kessler]

thanks again anodos

Henning

 

[MrAkai]

Just a follow up, after updating to 9.10 and enabling vfs_fruit, the error seems to have gone away.

Thanks everyone!

 

[cyberjock]

Another one to consider is acl_tdb. That may help some users with Apple SMB machines. :P

 

[anodos]

Another one to consider is acl_tdb. That may help some users with Apple SMB machines. :p

What does acl_tdb provide that zfsacl doesn't?

I get somewhat nervous about storing permissions and metadata in ways that aren't transparent to the underlying OS. What happens to the tdb file (which is stored in the system dataset) if you have to roll back a share dataset? What about backups of the "file_ntacls.tdb" file? In the webgui you can't set a snapshot or replication task for the system dataset. If there is a bug in zfsacl that is affecting mac users, then it should be fixed rather than worked around.

 

[cyberjock]

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