Mac OS X clients have problems copying files with Finder
The server that I am having trouble with is running a stable OmniOS build:
SunOS lfdisk 5.11 omnios-33fdde4 i86pc i386 i86pc
I have got a domain mode setup with Active Directory and do sharing with smb only (for simplicity reasons). An OS X user (which is not logged in to his client machine with AD) can successfully authenticate to the share where he wants to write to. For that he connects to the share with the Finder and pointing to "smb://x.x.x.x/ShareName" which works flawlessly. Then he can write/delete/rename folders and most of the files. All UID mapping is reflected correctly in the file system; all NFSv4 ACLs are inherited correctly as well.
However, if the user tries to copy a file with Finder which contains an extended attribute which is very often the case on OS X because of the resource fork entries or other OS X related informations on files (in this case JPG files), the copying will fail (not at all times!) with the Finder error message that it could not complete the process because of an unknown error (error -50). What perfectly works though is to open a terminal and copy all files with a simple "cp" command.
My workaround at the moment is: I deactivate extended attributes on that share with "zfs set xattr=off mypool/myshare". After that I have no trouble copying files with Finder as well.
I can also provide some WireShark traces from both scenarios. However, they are bigger then 4MB which is the upload limit here.
Updated by Graham Perrin almost 9 years ago
Which version of OS X?
With or without an extended attribute on an original file, expect an extended attribute to be added whilst Finder performs a copy. Consider:
- the brokMACS value of com.apple.FinderInfo in this answer to a question in Stack Overflow: How can I tell if a file or folder is busy, e.g. the Finder is busy copying to it?
- the related question in Ask Different.
If you disable native support for extended attributes at the file system level, then the Apple operating system may attempt to store those things (and others, if required) in the way that's normal where there's lack of support:
… a companion dot underscore file.