WebDAV over https not working anymore

Same Problem here with:

https://webdav.mediencenter.t-online.de

It works in the Finder with 10.6.8 and 10.7.4 but not with 10.8.

We have the same problem with a share we are using for development. It has a self signed certificate, same error you are getting.

Tried it with basic authentication and digest authentication, did not help.

If I turn off SSL on the server it works fine. Fails on two webdav servers in the same way, both are different versions of ubuntu. Server side logs show no errors, appears to be a successful login.

I can mount it fine using transmit.

Ok, I opened up keychain and found the certificate for the server listed under "Certificates". Right clicked, selected Get Info. Opened up the trust branch and set it to Always Trust. Problem solved.

I also run a WebDAV server on Linux with a self-signed certificate. The certificate trust was already configured like that before I upgraded to Mountain Lion.

However, the WebDAV client of Mountain Lion still behaves very weird. Drag-drop multiple files at once doesn't work complaining that the filename of 1 of the files being copied already exists. Also, files that were copied disappear all of a sudden. I even checked on the server via the terminal and they are no longer on the disk. Checking my Apache server log, I notice http DELETE commands while I didn't delete anything.

Anyone else experiencing this same strange behaviour?

For the record: I am also connected to that WebDAV server from a Linux desktop, and that works like a charm! It also worked correctly from Lion (10.7).

Ringo

Now that we got the certificate thing sorted out and have been using webdav this morning we are noticing that it is super buggy. A lot of the time folders just disappear. They don't get deleted, but you have to unmount the drive and open it again, or close the finder window and reopen it a few times. NetBeans is really flaky with it only showing half the projects and folders randomly disappearing from the project.

Its the same way on both webdav servers. Never had any of these sort of problems with 10.7.

We are back to using transmit and mounting it as a drive that way. Its a little slow with saves taking a few seconds, but at least it works. Hopefully this gets sorted out, using webdav on our test servers is a big part of our workflow.

I'm not sure this will help, but...

I had a set of strange problems with my implementation of Apache WebDAV, and a self-signed certificate, too.

I was never able to get a client cert to work for authentication, perhaps that will be solvable now. But I did have the strange problem of directories disappearing (well, becoming invisible). I eventually tracked this down to the need to tell the DAV module to use the "redirect-carefully" option.

Mountain Lion came out yesterday, and darned if I didn't see that same problem. I know I fixed it... But when I took a look at the data on the wire, I realized that Apache was matching for the user-agent version "1.*" - and the WebDAVFS in Mountain Lion is 2.0.1.

I'm glad I was able to remember this problem and find a solution. The other symptom was in the server logs, where Apache would complain that a directory was being requested without a trailing slash. That might also be a hint.

Hope this might prove useful. Happy to try to assist with any other questions...

I'm having this problem now in 10.8 with a WebDav server I've used for 2 years now. No luck connecting after the upgrade. The error message in the log follows:

Jul 28 00:15:36 macbook1.home webdavfs_agent[4633]: network_mount: URL is not a collection resource (directory); file: /SourceCache/webdavfs_executables/webdavfs-334.1/mount.tproj/webdav_network.c; line: 3132

Ok, seemed to have gotten it to work by adding the following to the apache config as per K.M. Peterson

BrowserMatch "^WebDAVLib/1.*" redirect-carefully

I'll post back if things fall apart.

Any suggstions if one cannot change the corporate webdav server?

This is an issue with the mac client requesting folders without a trailing slash (at least the issue we were having). I can think of nothing you can do on the client side except for switching to a third party webdav client such as transmit. I have no idea if this will ever be fixed on the mac as this fix is required quite often. Transmit works reliably but is extraordinarily slow with a large number of files/folders.

You should really put pressure on your corporate guys to put in this fix. It should not affect any other services, should take maybe 1 minute to implement.

K.M. Peterson

Thanks much for this, really appreciate it as I think it solved the problem for us.

Hi there,

Thanks for letting me know that this helped you!

I should make explicit what I only implied in my post: I originally had the issue of the trailing slash/mismatch when I implemented Apache WebDAV a couple of years ago. At the time, the Mac OS X 10.6 and 10.7 clients reported themselves as "WebDAVFS/1.x" (I forged which version exactly.)

This broke again last week with 10.8. I found that I hadn't done a good job of documenting this (yeah, that's what my blog should do, but...) I was able to piece the cause together.

10.8 reports a user agent of "WebDAVFS/2.0".

I had the following rule in my Apache config:

BrowserMatch "^WebDAVFS/1.*" redirect-carefully

This didn't catch Mountain Lion. I've added

BrowserMatch "^WebDAVFS/2.0" redirect-carefully

I want to see whether I remember this if 10.9 ups the version to 2.1. :-) Actually, I'm just really conservative.

I think that WebDAV is open-source, and possibly not only used by Apple, but if you aren't conservative, you could likely get away with

BrowserMatch "^WebDAVFS/*" redirect-carefully

Feel free to add something here if there's anything else I can help with. It took me 2-3 weeks to figure this out originally; I'm happy to save someone else the trouble.

Perhaps a dumb question, but is there a way for webdavfs to "spoof" the string so 10.8 reports WebDAVFS/1.x or some other client-side hack to make this work? Otherwise, I'll have to buy Transmit as a work around for the time being.

Thx

Not a dumb question at all...

But I don't think this is possible. The particulars about starting WebDAVFS and webdavfs_agent are fairly buried; since it's not a user-level application there's not likely to be a resource string that you could patch.

I would suggest that your corporate IT people shouldn't have much objection, assuming that they actually support WebDAV, to adding the configuration directive(s) that I talked about. I'm pretty careful to evaluate risks, and these don't have much potential to affect security or availability. The implication is that they might affect performance, but if you're the only one to have come across this problem there may not be enough of an affected set of machines to make any performance issues come up. (Supposedly, WebDAV performance has been improved recently, anyway.)

I'm assuming that you're using Apache/Linux, BTW. Other servers might operate very differently, or already be in compliance.

For the record, here are my issues with larger-scale use of WebDAV and Apache - what I've found, and I'd buy anyone with workarounds to these issues a beer or a case of such:

. Apache offers no ability to control access to directories served via webdav other than by user-specific configuration stanzas. In other words, there's no way for Apache to respect OS-level permissions or ACLs (on Linux, anyway) based on the identity of the user, because all files on the server are "owned" by Apache as far as the OS is concerned. That means it's impractical to think of sharing access to WebDAV resources. (Perhaps OS X Server has a solution to this?)

. Mac OS X doesn't seem to support client certificates for user auth. This would be a way to make Internet-wide access to files a bit more secure, as it would add an additional layer to password-based authentication.

I haven't tried Transmit. I did download Interarchy, but I couldn't get it to work and my email to the author/support address wasn't returned. On my iPad, GoodReader, the iWork apps, Password Wallet, and OmniOutliner all talk happily to my WebDAV server.

Wish I had a better answer for you... and I'd love to hear I'm wrong about any of this.

Message was edited by: K. M. Peterson1 (For some reason, UL tags not being rendered properly in actual published version, added spaces and "manual" bullets.)