i am running mod_dav on an openbsd system 3.9 with apache 1.3.29 (+patches) and mod_dav 1.0.3; the host system is gentoo linux. when i try to write to write to a webdav-folder i get the following errors:
on the client:
Resource deadlock avoided
error_log on the server:
[Wed Aug 9 23:26:02 2006] [error] [client 192.168.75.30] Could not LOCK /dav/aab.zip due to a failed precondition (e.g. other locks). [423, #0]
[Wed Aug 9 23:26:02 2006] [error] [client 192.168.75.30] (2)No such file or directory: Existing lock(s) on the requested resource prevent an exclusive lock. [423, #0]
access_log on the server:
192.168.75.30 - marc [09/Aug/2006:23:26:02 +0200] "LOCK /dav/aab.zip HTTP/1.1" 423 359
and, as you might guess, the file isn't wrote in the directory.
after porking aroung and getting rid of some 500 errors and creating the directories and files the server want to have, i am at this point and don't have any clue where my error's at.
can anyone point my in the right direction?
tried it today on mac os x 10.4 and 10.3, both worked, so it has to be something with davfs2. i am using version 0.28, kernel 2.6.14 and neon 0.25.3.
the apache log files are quite clear about this:
The file is already locked by some other client, so apache will not grant another (exclusive) write lock to the davfs2 client. That is what locking is for.
Why is the file already locked?
The lock held on the file may be a stale lock, left over by your previous attempts to get webdav running, but it may be a lock held by another user who is editing the file.
What to do?
- If you are sure, the locks held on your webdav resource are of no use, you may remove all of them from the server. You just have to delete the apache lock file (see option DAVLockDB in the apache configuration).
- If there will be no concurrent access to resources on the webdav server, you may run davfs2 without locking (option nolocks). (Propably mac os does no locking, so it worked).
- You may add a timeout for locks on your server. So locks that are not properly released by a client will be cleaned by apache after some time (option DAVMinTimeout). But be warned: currently davfs2 is not able to refresh a lock if it times out (future versions propably will). So the timeout should be not to short.
If you remove all the stale locks from the server and the problem still exists, there might be some misunderstanding between davfs2 and apache (not very likely, as davfs2 usually works with apache, including locks). In this case it would be usefull to log the traffic betweent davfs2 and apache (using ethereal or tcpdump). This should start with a clean apache installation (all locks removed).
the file is for sure not in use or locked by another client, because it doesn't exist and the apache was restarted just before the attempt to put the file on it. my configuration is similar to the one in the webdav-faq and no other client was connected or doing something on it.
now i am confused, because it works with davfs2, too (as root or with sudo, both work). didn't change anything...
okay, sorry for the noise
apache will also lock files that don't exist. This is compliant with the WebDAV RFC. It is to protect the name from beeing used by somebody else, after you created a new file until you finish editing and it is saved to the server.
You will get stale locks whenever a client locks a file (existing or not) and terminates or gets disconnected before it can release the lock. This often happens to me when I am testing new code (and davfs2 crashes because of new bugs). It also often may happen when you try to set up davfs2 and something goes wrong.
Please forget about my proposal to set DAVMinTimeout on apache. It is only a minimum, but all current versions of davfs2 demand for infinite timeout and will get it. apache stores lock information in a file, defined by DAVLockDB. If you get stale locks, you will have to clear this file manually to get rid of them.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.