When I first setup davfs it worked fine. Now it won't let me write to the mounted fs. The command line error is:
% cat > /mnt/foo
bash: /mnt/foo: No such file or directory
An error is logged to /var/log/messages of the following form:
Jul 8 17:08:05 jukebox mount.davfs: /foo: LOCK failed
Same error is returned if I attempt to copy a file to that location.
Oddly enough, I'm able to create a file using vim,
that is, just "vi /mnt/foo". Maybe vim uses a different write() call? Thought I'd throw that in there.
Any way around this?
One final question: Is there any way to override the warning message about unsigned certificates? My server issues an unsiged one, and I have to respond to the "are you sure?" question, thus not allowing me to use auto mount.
Thanks in advance,
OK, it appears nolocks option gets around this. Sorry.
while the nolocks option gets around this problem, there is the danger of different users overwriting each others files. So it would be nice to solve the problem. cat and vim do not use different file system calls. But while cat just opens the file, writes to it and then closes it again, vim creates a lot of temporary files.
There are a lot of possible reasons for the problem so I have got some questions:
- is the different behaviour of cat and vim reproduceable?
- does the file vim creates really exist on the server (is it still there when you stop davfs2 and then start it again)?
If the bug is reproduceable it would be nice to log the network traffic for both cases to see what's going on.
davfs2 has not yet the means to store new certificates (like browsers do), so you will have to do it by hand.
1. Find the directory wher your system stores trusted CA-Certificates. On Debian it is '/etc/ssl/certs', but it may be different on your system. This directory contains files and symbolic links like
. . .
. . .
2. Of what kind is your servers certificate:
It may be a self signed certificate (issuer and subject are the same) or it may be signed by some certificate authority (issuer and subject are different).
If it is self signed, copy it into '/etc/ssl/certs'.
Otherwise you need the certificate of the issuer (CA) and copy this into '/etc/ssl/certs'.
You may use
'openssl x509 -in certificatename.pem -noout -text'
to inspect the certificate.
3. Symbolic link:
As file names of certificates are arbitrary, openssl needs some way to find the certificate by the name of the CA. This is done by creating symbolic links. The name of this link is a hash of the name of the subject.
Use again openssl:
'openssl x509 -in certificatename.pem -noout -hash'
This will print the hash value, e.g. '2edf7016'.
Now create a symbolik link:
'ln -s certificatename.pem 2edf7016.0
Now your system will trust your servers certificate and davfs2 will no longer ask the user. Of course the certificate must be valid: it must not have expired and either the common name (CN) or the subject alt name must exactly match the servers domain name as used in the url.
Thank you for your response. I did some testing with the debug version of mount.davfs and captured the script, debug output, as well as messages logged to syslog. I think it's a bit much data to post here (77kb), but I'd be glad to send it to your email if you'd like. It reduces to a 5.8kb gzip'd tar.
As for the other issue (certificates): When I checked, all of those files/links were already in place. I'm using Suse 10.1. With mount.davfs from davfs2-0.2.8-bin-i386 I still have to answer the prompt every time I mount the fs. With the debug version I built, davfs2-0.2.8, it mounts fine, without prompting me. But then of course I get all the debug output...
The error that I get is similar to the following:
Server cerifticate could not be verified.
presented for `dav.server.com':
Issuer: Certification Division, ...
If you can't verify the fingerprint the server may be faked
or there may be a man-in-the-middle-attack!
I am not a coward and accept the certificate anyway [y,N]? y
... and yes, reconfiguring mount.davfs --with=nodebug fixes the certificate issue. But the prebuilt one does require accepting it every time.
concerning debug output:
Please send the debug message to my email adress:
It my be plain text or gzipped, does not matter.
Please first look at the beginning of the debug messages. There might be your username and password among the messages. Remove these lines, they are not needed.
This behaviour is really curious, but it may be related to different library versions. Also there is same confusion about where to put the server name within the certificate.
davfs2 does not directly call any functions of the ssl library. davfs2 calls functions of the neon library and neon calls functions of the ssl library.
The prebuilt binary is compilied against neon-0.24. What version of ssl is used depends on the neon-0.24 library on your system.
When you build davfs2 on your system, it will look for the neon headers in /usr/include. This determines what version of neon will be used and this again will determine what ssl library to use.
So there is a good chance, that the precompiled binary and the one you built on your system will use different ssl libraries.
You may do a 'ldd mount.davfs' for the precompiled version as well as for the one you compiled, to see what libraries are used.
Confusion about where to put the server name:
I am not really sure about this, but as far as I remember, some RFC demands the name of the server to be put into the field "subject-alt-name" within the certificate. But there is also some tradition to put it into the CN-field of "subject". Different ssl libraries might handle this different.
Please, when you get the message about unverified certificate, compare the server name mentioned in this message and the subject-line.
It would be nice if you could send me the information from 'ldd' and about the server names too, so maybe I could find the reason for this behaviour, so I could at least add some usefull information to the README file or even find a solution.
thanks for the log files. They helped to see what is going on.
SSL Certificate Problem:
I made a mistake in my last message. The binary package is statically linked, as 'ldd' told you. The neon and ssl libraries are included in the binary. But this is the problem.
The libraries in the binary are from my Debian system, where I built the package, and there often are slight differences between the libraries of different distributions.
The ssl library included in the binary looks for certificates in /usr/lib/ssl/certs. On my Debian system this is a symbolic link to /etc/ssl/certs. I asume there is no such link on your Suse system, so mount.davfs can't find the certificates. The program you compiled uses the Suse libraries and therefore finds the certs.
Please tell me whether I am right (is there really no such symbolic link in /usr/lib/ssl on Suse), so I can add a hint to the README file.
This seems to be a server error. From your file doTest.log I can see:
Line 47 to 88 (OPTIONS request):
The server (Apache 1.3.34) definitely declares it will support the LOCK method.
We also know from other successful requests that directory '/sam%5flambert.mail-central.com/files/' exists, whereas file '/sam%5flambert.mail-central.com/files/foo' does not exist.
Line 358 to 398 (LOCK request):
The request to LOCK '/sam%5flambert.mail-central.com/files/foo'
fails with error code '404 Not Found'.
This is not correct behaviour. According to the WebDAV RFC2518 the server should lock the name 'foo', but not create a file, and respond with '200 OK'. When you later store the file using the PUT-method the file will be created.
There is also a discussion within the WebDAV working group to change this and some servers already show this new behaviour: They will create a file and lock it in response to the LOCK request. Return code will then be '201 Created'. But in this case the request would succeed and so would mount.davfs.
It is not very likely that the neon library sends a malformed request. a) There would be another return code in this case; b) it works with other servers, Apache servers too (but I only did serious testing with Apache 2).
So I would suggest you contact the administrator of the server. Maybe he will find some more information in the server logs, or there is some misconfiguration; some servers, allthough beeing Apache, don't use the Apache DAV module but some other software, which may be buggy. I think the administrator should be able to help with this.
You are correct: The symlink between /usr/lib/ssl/certs and /etc/ssl/certs did not exist. Thanks for clearing that up!
I'll contact the admin at the server regarding the other problem.
Thanks for your help!
Hi - I'm the admin of the DAV server in question. You're quite right - our behaviour is only to lock things that don't exist.
I have a feeling that it's going to be a lot easier to return '201 Created' and just touch an empty file than to lock a name that doesn't exist yet due to the way our locks are implemented (by NodeId rather than by name).
Is there any strong reason to follow the RFC exactly and lock names instead? As in a real world use-case that would justify the extra work? The only thing I can think of is if the name is intended for a collection (directory) instead of a file.
Bron ( who tested with Konqueror's webdav support but not davfs )
I think it will be fine to do it the way you intend.
So far as I can see, there will be a revisited version of WebDAV soon and this will change the behaviour just the way you suggest:
When a client requests a lock for a nonexisting file, the server will created an empty file, lock the file and return "201 Created" together with a XML-Body containing the lock token.
Clients must not take locks for nonexisting directories, but first create the collection and then lock it.
I once contacted a server that already works this way, but I have forgotten where.
davfs2 should be able to handle this new behaviour, but this is not well tested and any bug report will be welcomed.
For the proposed next version of the WebDAV-RFC please see
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.