Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

OSX 10.9 - Mavericks webdav client broken

My company provides a webdav server solution for OS X webdav clients.


Since OS X 10.9 upgrade, many webdav actions including dragging a file onto a webdav mount using Finder and editing files using MS office applications (Microsoft Word, Office, Powerpoint) have stopped working.


Looking at client <-> webdav server traffic, it appears that after acquiring LOCK on a file, client is not supplying lock token in subsequent requests to server, resulting in 423 responses on subsequent operations.

According to webdav spec, client needs to supply file lock-token in subsequent commands to server.


At this point, webdav mount also gets disconnected with following error in dmesg.


Sandbox: QuickLookSatelli(41334) deny network-outbound /private/tmp/.webdavUDS.YlINRf

webdav_sendmsg: sock_connect() = 1

webdav_close_mnomap: no cache file

webdav server: https://server.com/webdav/: connection is dead

webdav_sendmsg: sock_connect() = 61

webdav_sendmsg: sock_connect() = 61


I confirmed that this is not a problem with 10.8 or earlier versions.


Has anyone else seen this problem and have a solution ?


Thanks

OSX Webdav-OTHER, OS X Mavericks (10.9)

Posted on Oct 25, 2013 5:22 PM

Reply
56 replies

Oct 25, 2013 6:33 PM in response to Egnyte

Well, I've spent the last 3 months writing my own webdav server specifically for use with the Finder. I don't claim to understand the reasoning behind the Finder's requests, but I can't confirm what you are seeing. I can see instances of the Finder issuing a LOCK and then a PUT, but the PUT always has an If header. Are you sure the resource is still locked? One odd thing about the Finder is that most of its LOCK commands are immediately followed by UNLOCK, with no operation in between. I can only find some PUT requests that actually do come after a LOCK and it they have the required lock If header. I see other requests that I would expect to have had a lock reference, but the resource in question had already been UNLOCKED beforehand - immediately after the LOCK.


You can download the webdav client for Mountain Lion and look at it. Surprisingly, Apple has already posted the Mavericks source. I haven't looked at the Mavericks source but I did look at the Mountain Lion code. The source really didn't help me but I did notice quite a bit of IIS-specific code. If there were changes in the locking code, it was probably to support IIS or perhaps Apache. There isn't much other than those two as far as servers go. Still, I don't see anything Mavericks is doing wrong. For good or bad, my server is happy enough 🙂

Oct 27, 2013 4:20 PM in response to Egnyte

I am having this problem myself, and I have no solution. This is definitely new in Mavericks. Initially I was having a problem that I had seen with previous versions of Mac OS X, with folders randomly disappearing in the Finder, but I fixed this on the server side as I had before by adding a BrowserMatch directive for WebDAVFS 3.x. I am also getting the 423 errors, so if anyone figures this out, I'd be most grateful.

Oct 28, 2013 1:42 PM in response to Egnyte

Yes there is a problem for me with Mavericks and connecting to a webdav share on our intranet. Sometimes it connects and then drops out after a short period, other times it just wont connect. Also mounting an SMB share to the same server causes an issue which locks me out of the Intranet completely via Safari and via mounting it. I'm using:


SBS2008 with Sharepoint 2007 and network shares.

Connecting using https:// and SMB://, which actually doesn't work either so I use CIFS://


The same computer on the same network had no issues connecting to both types of shares simultaneously when on OS X Mountain Lion.

Oct 31, 2013 5:38 PM in response to NHC2365

More info.



File drag and drop to Finder webdav mount show following sequence of request and responses:





PROPFIND /webdav/Private/a123/test.pptx 404

PROPFIND /webdav/Private/a123/test.pptx

PUT /egnyte-internal/webdav/Private/a123/test.pptx 201

PROPFIND /webdav/Private/a123/._test.pptx 404

LOCK /webdav/Private/a123/test.pptx 200

UNLOCK /webdav/Private/a123/test.pptx 204

PROPFIND /webdav/Private/a123/._test.pptx 404

LOCK /webdav/Private/a123/test.pptx 200

UNLOCK /webdav/Private/a123/test.pptx 423



Finder sends multiple lock-unlock requests and looking at wireshark output for this sequence, second unlock request doesn't include the Lock-Token header. At this point, system.log shows error "unexpected statusCode 423" and mount disconnects.


I also pointed Mavericks webdav client to tomcat webdav implementation and I see the same issue. Other operations like opening MS Office files and editing them show similar errors with missing lock tokens. At different points, I have also noticed "Too many files open" message in the

system.log


webdavfs_agent[42090]: (victim_node != ((void*)0)) failed; going to too_many_files_open; file: /SourceCache/webdavfs/webdavfs-352/mount.tproj/webdav_cache.c; line: 477


I compared webdavfs codebase between ML and Mavericks and I do see changes made to locking and unlocking code.

Oct 31, 2013 7:17 PM in response to Egnyte

Sorry, you are going to have to go deeper than that. I just ran the same sequence through and the request where you return 423 I return 204. Here is the request:


UNLOCK /test copy.txt

Accept: */*

Lock-Token: <urn%3Auuid%3A70E157D7-8653-4721-8390-8110184ABC5C>

Host: unsaved-etrezip-document.local:61276

User-Agent: WebDAVFS/3.0.0 (03008000) Darwin/13.0.0 (x86_64)

Authorization: Digest username="93A8E265-BED6-44C9-9184-73EE976F2A5F", realm="auth-etrezip@etresoft.com", nonce="a467b76869eefe2ff250cdce91ff7b3836", uri="/test%20copy.txt", response="820496ff335caf543bc9e4ac5e6c0070", opaque="2022BB3E-D36A-4AE3-BF83-E3E39A4E284A", cnonce="e8943b92ce0af97ee22d071748c98a7a", nc=0000004d, qop="auth"

Content-Length: 0

Connection: keep-alive


The lock token is there. As far as I can tell, every UNLOCK request has a Lock-Token.

Nov 1, 2013 11:29 AM in response to etresoft

etresoft,


you are returning 204 _because_ you get Lock-Token in the request. As I said, I did not get a Lock-Token in the request in the second UNLOCK request. What can a server implementation do in such a case.


FWIW, here is the requets in wireshark:


UNLOCK /webdav/Private/a123/test.pptx HTTP/1.1

Host: localhost:10001

Accept: */*

Authorization: Basic YWRtaTeyhsbaksVusjhs9tZTEyMw==

Content-Length: 0

Connection: keep-alive

User-Agent: WebDAVFS/3.0.0 (03008000) Darwin/13.0.0 (x86_64)

\r\n



What do you mean by "you are going to have to go deeper than that" ?

Would it be possible for you to pm me a test account on your server ? I can then test my Mavericks against your server to see if this issue shows up.


Thanks

Nov 1, 2013 2:47 PM in response to Egnyte

Egnyte wrote:


What do you mean by "you are going to have to go deeper than that" ?

Would it be possible for you to pm me a test account on your server ? I can then test my Mavericks against your server to see if this issue shows up.

I just mean that something like this requires additional supporting evidence. I was looking for the HTTP headers, which you provided.


My server is inside an application. Hopefully it will get approved and be in the Mac App Store any day now. Unfortunately, I have heavily dependent on the Finder working correctly on the reviewer's machine. As you know, such things are not guaranteed. Send me an e-mail and I will give you either a promo code or a test iTunes account, depending on my luck in the next 48 hours. You can crank your LogLevel to 9 and fill your console.app log - no Wireshark required.


However, you may need to go quite deep with this one. I looked at the webdav client code for Mavericks, and I just don't see any way for it to not include the Lock-Token. This is the only place UNLOCK is ever sent from. The C++ style comments are from me.


int network_unlock_with_nodecache_locked(


struct node_entry *node) /* -> node to unlock on server */

{

int error;

CFURLRef urlRef;

CFStringRef lockTokenRef;

char* locktokentofree = NULL;

uid_t file_locktoken_uid = 0;


/* the 2 headers */

CFIndex headerCount = 2;

struct HeaderFieldValue headers[] = {

{ CFSTR("Accept"), CFSTR("*/*") },

// Apple seems to think this is required.

{ CFSTR("Lock-Token"), NULL },

{ CFSTR("translate"), CFSTR("f") }

};


if (gServerIdent & WEBDAV_MICROSOFT_IIS_SERVER) {


/* translate flag only for Microsoft IIS Server */

headerCount += 1;

}


locktokentofree = node->file_locktoken;

node->file_locktoken = NULL;

file_locktoken_uid = node->file_locktoken_uid;

node->file_locktoken_uid = 0;



/*unlocking the node cache before calling send_transaction()*/

unlock_node_cache();



/* create a CFURL to the node */

urlRef = create_cfurl_from_node(node, NULL, 0);

require_action_quiet(urlRef != NULL, create_cfurl_from_node, error = EIO);


// Code obviously copy and pasted from network_delete() function.


/* in the unlikely event that this fails, the DELETE will fail */

// Event if locktokentofree is null or empty, lockTokenRef should still have a

// non-null value.

lockTokenRef = CFStringCreateWithFormat(kCFAllocatorDefault, NULL, CFSTR("<%s>"), locktokentofree);

// Don't even send the message if lockTokenRef is null.

require_action_quiet(lockTokenRef != NULL, CFStringCreateWithFormat, error = EIO);


// Lock-Token gets a value here. Is there some value that will make

// CFHTTPMessageSetHeaderFieldValue drop the header entirely in send_transaction()?

headers[1].value = lockTokenRef;



/* send request to the server and get the response */


/* Note: we use the credentials of the user than obtained the LOCK */

error = send_transaction(file_locktoken_uid, urlRef, NULL, CFSTR("UNLOCK"), NULL,

headerCount, headers, REDIRECT_DISABLE, NULL, NULL, NULL);


CFRelease(lockTokenRef);


CFStringCreateWithFormat:


CFRelease(urlRef);


create_cfurl_from_node:


free(locktokentofree);

locktokentofree = NULL;



/*Locking the node cache as the function returns a locked node*/

lock_node_cache();


return ( error );

}


The only real difference between the Mavericks code and the Mountain Lion version is that Mavericks has better thread safety. Mavericks pulls values from the node and sets the final node values right away, sending the old values over the wire. If send_transaction() fails or hangs, then the node is still unlocked and other routines can access the node.


I think you should look at all of your messages and find where the Lock-Token no longer gets included. Still, I don't see how it is even possible. If there is some header value you can provide such that CFHTTPMessageSetHeaderFieldValue does not create the header, then that would be your bug. It seems to handle null just fine and would emit "<>" on an empty string, which would still be a valid header.

Nov 19, 2013 12:22 AM in response to etresoft

We're running the Open Source VMWARE Zimbra server, version 7.2.1_GA2790.FOSS Aug 2012.


It has worked flawlessly up until the Mavericks clients upgrades.


Something is definately wrong in the new WebDAV omplementation. Quicklook on MS-files does not work. PDFs do, but there is also an inconsistency here. Opening Office-files directly via Finder is not working.


Generally weird stuff that has never been an issue before. Apple engineers has to look into this...

Nov 19, 2013 6:34 AM in response to Kenneth Andre

It is mainly a problem of market scale. If Mavericks doesn't work with Microsoft or Apache's WebDAV server, that is Apple's problem to fix. If Mavericks doesn't work with Zimbra's server, that is Zimbra's problem. Contact Zimbra support and have them look at it. If they identify a problem in Mavericks, they will have the information they need to submit a bug report to Apple.

Dec 3, 2013 9:54 AM in response to etresoft

I agree, it definitely needs to work with standard implementations like MS / tomcat.


As I stated above in my second post, I see exact same problem with Tomcat webdav implementation - randomly missing lock tokens in Lock-Token and If headers.


It would be great if someone else could also test and validate tomcat 7 webdav implementation.

OSX 10.9 - Mavericks webdav client broken

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.