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

Dec 3, 2013 12:21 PM in response to Egnyte

We'll this is strange. I've just purchased a brand new 15" Macbook Pro Retina (the base model). Now I can connect to my SMB and HTTPS shares with no problems at all. Can anyone explain that for me? On my old 13" Macbood Pro R I had tried a complelty fresh install of Mavericks but still had the same problem. I migrated all my apps, data etc from that to the new machine. Wierd.

Dec 4, 2013 11:26 AM in response to kvandivo

kvandivo wrote:


I'm also seeing behavior where Finder does a LOCK/UNLOCK and doesn't send the required lock token in the UNLOCK. What are people doing as they wait for Apple to fix things? Anyone come up with a workaround?

I hope no one is sitting around and waiting for a fix. Anyone who is can reproduce this problem needs to file a bug report about it. I have not seen such a problem despite being very focused on WebDAV the past few months. According to Apple's WebDAV source code, it shouldn't even be possible. Of course, I may have missed it both in the logs and the source code. But that's my problem. I'm not filing any bugs on something I can't reproduce.

Dec 4, 2013 2:23 PM in response to Egnyte

Egnyte wrote:


etresoft,

You can always test against tomcat webdav implementation to reporduce it. I can do that very consistently.

I would have to install it and set it up. I have plenty of testing to do on my own WebDAV implementation. I check for a valid lock token on unlock and return 400 if that happens. Either that hasn't happened or the Finder recovers from it. I haven't had to do any DAV-level debugging in some time.

Dec 9, 2013 10:52 AM in response to etresoft

"I would have to install it and set it up. I have plenty of testing to do on my own WebDAV implementation."


As I said, I can reproduce this with Tomcat Webdav implementation and have already logged a bug. More verifications will help.


Anyone else who can test against tomcat implementations or has issues with other implementations ? Any solutions you have come across ?


Thanks

Dec 13, 2013 4:21 PM in response to kvandivo

Thanks Kvandivo.


Filing bugs is a good way to increase chances of getting some help. Each bug deemed duplicate is also an independent verification of the original issue.


I thought about letting unlock with a misisng lock token, go through but I also noticed PUT requests missing If header.

Also locking is heavily used by MS Office apps and is required to get a consistent view of my server state so I was not able to remove it. If you dont have those constraints then it is definitely worth a try.

Jan 3, 2014 4:28 AM in response to Egnyte

I have the same problem and also just filed a bug report to apple. hope that get's fixed soon since I highly rely on that feature and don't want to use third party tools for a simple task like that.

As far as I know nobody can actually read others bug reports, but nevertheless here's the bug number I received:

15743395

Jan 29, 2014 6:50 AM in response to JunkiXL

Same problem here... -36 error. Shame as Webdav performs so much faster than SMB over VPN. No solution yet. I did the three files into WEBDAVfs with no luck. I even tried using http with no ssl since it is over VPN from home but still same errors. Apple really needs to stop breaking stuf that worked great before. Hopefully some enterprising person out there digs into the open source part and finds a solution. I even saw where Egnyte stopped offering the mount drive option (via webdav) as a service to their clients since they could not fix it or get Apple to fix it since October 2013.

Jan 29, 2014 9:14 AM in response to keithfromvirginia beach

keithfromvirginia beach wrote:


Shame as Webdav performs so much faster than SMB over VPN.

Then you must have a serious SMB problem. WebDAV, especially through the Finder, is the slowest protocol known to to humankind.


Hopefully some enterprising person out there digs into the open source part and finds a solution.

While I did dig into the open source part, I couldn't find any possibility of the problem described in this thread. Nor have I ever seen it with my own servers.


I even saw where Egnyte stopped offering the mount drive option (via webdav) as a service to their clients since they could not fix it or get Apple to fix it since October 2013.

That's Egnyte's problem. Mavericks WebDAV works just fine with Apache. The Finder's use of WebDAV is not particularly logical. Perhaps that is what is giving Egnyte such a problem.

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.