Some Microsoft services do unexpected things with/around DNS. Jared, see whether the host resolves when both Finder and the SharePoint service are in the same local area network.
–
Graham PerrinApr 27 '12 at 5:14

requirements of Microsoft Office 2011, when used with a file system such as webdav, are not met by SharePoint.

When SharePoint does not recognise that a user of PowerPoint or Word with webdav has opened a file, there's risk of dataloss — two or more users overwriting each other's work, with no warning before or after the loss. I can't reproduce this problem when NeoOffice is used to open such files.

Excel with webdav seems to always open .xlsx spreadsheets read-only. I can't reproduce this problem when NeoOffice is used to open such files.

Apps that are more compatible

Input/output errors affecting files saved in Microsoft formats

If an attempt to open an Office Open XML file (.docx,.pptx, .xlsx etc.) fails with an input/output error:

use Microsoft Document Connection to initiate an edit

save a trivial change to the file, close the window of the app that you used for edition

if necessary, quit the app that you used for edition.

Those two or three steps seem to resolve, or work around, the error.

(If I discover the exact cause of those types of input/output error, I'll either add to this answer or link to a question elsewhere. Early indications are that they occur only after a Microsoft Office app has failed to save with webdav.)

Point #2 above - I think depends on how Sharepoint authorization has been set up IIRC. Even if you're not a member of the domain, often you can authenticate against a domain account to get access... shrug
–
HarvJan 29 '11 at 22:31

In my limited experience with a SharePoint service, recently offered to me for test purposes: the URL for WebDAV connection should be https or http — as used with Microsoft Document Connection — not smb. In my case the same https URL works for both (a) a mount in OS X, and (b) a drive mapping in Windows 7.
–
Graham PerrinApr 26 '12 at 6:50

I'd be curious if you get this working. I can connect to our SharePoint 2010 server via the Finder (Snow Leopard 10.6.6), but any files copied to the share fail with a -36 error. The file appears on the share, but has 0 bytes. Copying with the command line works fine.

Update:

After some more detective work, I think I've found a cause of some problems: SharePoint has filename restrictions that conflict with the way the system stores extended attributes or resource forks on file systems that lack support for those things.

When using Finder to copy a file (example: foo) to a SharePoint WebDAV share, the system may require a counterpart (example: ._foo) during or after the write. Disallowance will cause a write operation to fail.

This also explains why third-party WebDAV clients such as Cyberduck and Transmit appear more compatible — with some types of connection, they lose metadata.

For a volume mounted by Transmit with a WebDAV HTTPS connection to SharePoint, the file system type is not webdav, it's:

transmitdiskfs

Unless the Finder stops the ._filename stuff when writing to webdav shares, or SharePoint starts accepting periods at the beginning of filenames, I don't think you'll be able to reliably use Finder with SharePoint WebDAV shares.

First a simple wdfs command, without the volname option of FUSE for OS X.

Then attempting to work around error -43 (see below), a similar wdfs command with a volname option.

Results, in brief

Finder appears to copy and move some types of file to SharePoint without error. The following types of file seem OK:

.docx

.sh

.txt

.zip

Finder copy of wdfs-1.4.2.tar appeared to succeed but:

the result was zero bytes

maybe .tar files are unacceptable to SharePoint (consider the silent loss of some types of metadata; maybe some types of data are rejected in an equally lossy way)

I don't plan further investigation of the reasons for this exception.

An extended attribute of a file (tested: Spotlight comments) may appear to be preserved following the copy to SharePoint, but you'll find the attribute missing when the volume is next mounted.

Dates of creation, modification and last opening appear wrong (reasons for this are known, but beyond the scope of this answer). For the same files, dates will appear proper with a system-managed WebDAV connection.

Folders

SharePoint will accept, from Finder, a copy or move of folder that is without a .DS_Store (Desktop Services Store) file.

More generally, attempts to copy or move folders may fail with errors such as:

Some of the information contained in this post requires additional references. Please edit to add citations to reliable sources that support the assertions made here. Unsourced material may be disputed or deleted.

Please, where did you read that HTTPS is not not supported by Finder? If you have a question about zero byte files, make it a question (not an answer) — thanks.
–
Graham PerrinApr 27 '12 at 5:05