Mapping a drive to a SharePoint library (Connect to Server) from Mac OSX Finder does not allow drag and drop of files into a SharePoint document Library

Posted On August 27, 2015

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 was not built on top of Mac OSX obviously.  The additional files that are so integral the way OSX, and more specifically, the way their HFS or HFS+ file system works, are not used in an NTFS files system and are not understood by SharePoint.  SharePoint was designed to interface with NTFS directly when using “Open in Explorer view” and adding this functionality was no small feat.  The fact is, HFS and NTFS are two completely different and privately controlled, proprietary file systems which work in much different ways.  You can start to scratch the surface on understanding the HFS scheme and use of these additional files here http://lists.apple.com/archives/applescript-users/2006/Jun/msg00180.html.

Further, SharePoint has not been designed to accept file names beginning with a dot “.” and in fact is designed, since the days of FrontPage server extensions, to block them.  Even if SharePoint was changed to allow the dot (.) prefixed file names, 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 there would be a monumental coding and collaboration effort required, 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 begin to be feasible. 

This is not to say that SharePoint couldn’t either strip out these files or build in support for them, but this would not only require close collaboration with Apple to properly handle the files, but also Apple would have to be willing to expend effort to work with the SharePoint product team to help them improve their own product, much in the same way the Windows OS team had to expend time and resources to allow the SharePoint Explorer view feature to come into being at all. 

Long story short, fixing this would not be up to Microsoft alone, and to do this fully (i.e. not using some reverse engineered, open source version) would require a joint effort and buy in from Apple to assist with the effort every step of the way, including their support should it break.

 

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.

The alternative?  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 these additional options readily available, there isn’t a really compelling need for Microsoft to take on the monumental effort of rewriting SharePoint to comply with a completely different file system and concept of file metadata, just so it can allow a third entry point for these types of files.

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:

1. use a web traffic analysis tool to inspect the traffic
2. 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.