If you have ever tried mapping a drive to a SharePoint document library, from a MacBook Air or MacBook Pro - essentially any Mac OSX 10 device, you have probably noticed that it doesn't work!
My experience was with a MacBook Air and MacBook Pro, both with OSX 10.
What you might not be clear on is - Why doesn't it work? or - Where does the problem lie, in SharePoint or in the Mac OSX?
Pardon any misuse of Mac terminology here, as I live in Windows 99% of the time.
This is a high level look at what's happening:
The problem starts when you use the Mac OSX Finder, which is similar to Windows "Explorer.exe", to connect to a SharePoint document library.
This is done by clicking on Go -> Connect to Server -> Add the path to the SharePoint document library like http://SharePointPortal/sites/MyTeamSite/MacFilesGoHere/
Once the mapped drive (Connect to Server) is connected and opened, you try to drag and drop files from your MacBook into the drive/location. This results in either no file being copied over, or a 0 byte file being copied into the library.
Additionally, you will likely see the following error:
Copy
-----------
The Finder can't complete the operation because some data in "TheFileName.rtf" can't be read or written.
(Error code -36)
---------------------------------------------------------------------
This error may look familiar, as it's often seen copying to other devices or locations from Mac's Finder.
In addition to this error, you will probably find that Finder is now hung in an infinite loop (making repeated unauthenticated requests and getting 401 authentication responses) or is generally just no longer responding. To recover from this, you may be able to use the "Unmount" command, or you may have to power down the device and restart it.
So, what is the problem?
The Finder uses User-Agent: WebDAVFS/3.0.1 (03018000) Darwin/13.4.0 (x86_64)
The Finder attempts to do PROPFIND and PUT for additional files that it wants to copy to the library. For example, if I’m trying to copy a file called “MyFile.rtf”, these additional files include files like ._MyFile.rtf, ._., .DS_Store, etc.
These requests all return 414 errors from SharePoint:
HTTP/1.1 414 REQUEST URI TOO LONG
X-MSDAVEXT_Error: 589924; The%20following%20file%28s%29%20have%20been%20blocked%20by%20the%20administrator%3a%20%2fsites%2fMyTeamSite%2fMacFilesGoHere%2f%2e%5fTheFileName%2ertf
(decoded: X-MSDAVEXT_Error: 589924; The following file(s) have been blocked by the administrator: /sites/MyTeamSite/MacFilesGoHere/._TheFileName.rtf)
Ultimately, Finder will either copy a 0kb file or no file to the document library because of this error.
What's the cause?
SharePoint is not designed to handle files with file names beginning with a dot "." and in fact is designed, since the days of FrontPage server extensions, to block them. These additional “sidecar” files that Mac OSX Finder tries to add would be likely to interfere with advanced features like required properties, force checkout, event receivers, versioning, alerts, workflows, etc. So SharePoint is really not in a good position to allow these additional files to be added. Certainly, additional handling would have to be built into many areas in SharePoint for this to even be feasible.
SharePoint returns 414 response to these requests with an error like:
HTTP/1.1 414 REQUEST URI TOO LONG
Cache-Control: private,max-age=0
Content-Length: 0
Expires: Wed, 29 Jul 2015 20:38:26 GMT
Server: Microsoft-IIS/7.5
X-SharePointHealthScore: 0
Public-Extension: http://schemas.microsoft.com/repl-2
X-MSDAVEXT_Error: 589924; The%20following%20file%28s%29%20have%20been%20blocked%20by%20the%20administrator%3a%20%2fsites%2fMyTeamSite%2fMacFilesGoHere%2f%2e%5fTheFileName%2ertf SPRequestGuid: 5daf239d-edd1-a029-f747-911b5e295656
request-id: 5daf239d-edd1-a029-f747-911b5e295656
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 12
SPIisLatency: 0
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4420
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 13 Aug 2015 20:38:26 GMT
What can I do?
Right now, and in the foreseeable future, the best option is to not use the "Connect To Server" option of Finder in Mac OSX to try to copy files into SharePoint.
Instead, just use the browser. SharePoint 2013 allows you to drag files directly into the web UI from Finder (a file on your Mac). Just browse to the document library in the browser and drag files into the area indicated. You can also use the options in the web UI to upload files via the menu. With this capability, there isn't a really compelling need for this functionality to also work in Finder.
And now you know why it doesn't work. It's not evil ;) , it's just different file systems with different schemes crashing into each other. It's a new day and I think we'll find we're moving away from the concept of mapped drives anyway, and toward more modern concepts like syncing and web driven, cloud enabled storage and management of files.
A deeper look
If you want to see what files, exactly, that the MacBook is trying to copy over, you can do two things:
use a web traffic analysis tool to inspect the traffic
format a thumb drive as Fat32 or exFat and plug it into your MacBook. Then use Finder to drag files over to the drive. Now take the drive back to windows (easiest way) and unhide hidden/system files. You’ll see all the additional files that were copied over to the drive along with the one file you selected.
exFAT: allows you to store files larger than 4 GB and can be read and written in Windows and OS X 10.6.5 and later.
To analyze web traffic from the MacBook, I set up Telerik’s Fiddler on a Windows PC and enabled remote connections in Tools -> Fiddler Options -> Allow remote computers to connect, and set Fiddler to listen on port 8888. I then set up a web http proxy on the MacBook to point to the PC on port 8888. This allows me to load Fiddler on the PC and capture all of the traffic coming from the MacBook, including the conversation with the SharePoint server.