Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I configured Apache2 to allow WebDav on a directory (CentOS 5 / Plesk 8.6):

  • WebDav is enabled in httpd.conf
  • /var/lib/dav/lockdb is writeable by Apache
  • My target dir is chmod 777
  • My target dir is chowned apache:psacln
  • using Basic Authentication (setup by Plesk interface)

in my vhost.conf I have:

<Directory /var/www/vhosts/domain.com/httpdocs/target_dir>
        Dav On
    AllowOverride none
        Order allow,deny
        Allow from all
</Directory>

I can connect to the directory using authentication fine and download files from it. But I cannot write to the dir. I get a 403 Error when I attempt to upload or create a dir.

Anyone have any tips?

Thanks in advance -

Update - 6/5 Using the comments below I've isolated the issue to being some type of conflict with .htpasswd protected directories. I can created an unprotected dir and enable WebDAV uploads fine. But once I enable Basic Auth on the directory everything goes south. I can read but no longer upload.

This is my vhost.conf:

<Directory /var/www/vhosts/domain.com/subdomains/subdomain/httpdocs/>
        AuthUserFile /var/www/.htpasswd
        AuthName "Login"
        AuthType Basic
        Require valid-user

        DAV on
    AllowOverride none
        <Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
                Require valid-user
        </Limit>
</Directory>

Update 6/6

Was able to get WebDAV working on a different domain with minimal effort. The only difference between the two domains is that in the one which refuses to allow write access I have a DocumentRoot directive:

    DocumentRoot /var/www/vhosts/domain.com/httpdocs/app/webroot

Might this be causing some problems?

share|improve this question
add comment

6 Answers

up vote 1 down vote accepted

I recently struggled with the same problem on my Fedora 10 system. In my case the culprit was some odd redirection that I was doing in Apache. Specifically, I use a content management system (Drupal, to be exact) that within it's .htaccess includes the following redirection logic to redirect missing files to a PHP script:

# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

It makes sense that the above only affects the PUT method since in that case REQUEST_FILENAME does not exist.

Not having the WebDAV area inside of the Drupal area, which seems like a reasonable constraint, fixes the problem.

Also, I think it is likely that SELinux would result in a different error, but it's not mentioned in the discussion above. Did you try disabling SELinux?

share|improve this answer
    
This pretty much nailed the problem. I switched on WebDAV on a subdomain without mod_rewrite and everything worked as expected. –  Darren Newton Jul 13 '09 at 11:57
add comment

Same problem. Solved by:

<Location /xyz>
    DAV On
    AuthType Digest
    AuthName "webdav-xmarks"
    AuthDigestProvider file
    AuthUserFile "/home/xy/xba/digest-password"
    Require valid-user
    RewriteEngine off <-- this part solved it!
</Location>
share|improve this answer
add comment

What does your error_log say? That's the first place to look.

Also, look in the regular access_log; sometimes some DAV clients will try to do DAV things at higher level directories than where you're doing your work, which requires them to have at least read-only DAV access up to the virtualhost root.

share|improve this answer
    
I don't see anything in error_log specific to web_dav. –  Darren Newton Jun 5 '09 at 1:34
    
okay now we're getting somewhere: <b>error_log</b> [Thu Jun 04 21:27:14 2009] [error] [client xxx] Unable to PUT new contents for /depot/flvplayer.swf. [403, #0] [Thu Jun 04 21:27:14 2009] [error] [client xxx] (2)No such file or directory: An error occurred while opening a resource. [500, #0] <b>access_log</b> 2xx.xxx.xxx.xxx - user [04/Jun/2009:21:46:38 -0400] "PUT /depot/flvplayer.swf HTTP/1.1" 403 423 "-" "WebDAVFS/1.2.7 (01278000) Transmit/3.6.7 neon/0.25.4" –  Darren Newton Jun 5 '09 at 1:47
    
So.. not clear why I'm getting a 403. I can read files from the dir and also delete them (!), but I cannot PUT them. –  Darren Newton Jun 5 '09 at 2:36
add comment

Did you try using limit: (for example)

  <Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
    Require valid-user
  </Limit>
share|improve this answer
    
Okay - added this to my Directory in vhost.conf - still not working, getting 403 error –  Darren Newton Jun 5 '09 at 12:21
add comment

Same problem.

Solved by creating a .htaccess file in the webdav directory with :

RewriteEngine off

Found here: http://annoyingtechnicaldetails.wordpress.com/2007/07/20/webdav-vs-drupal-htaccess-redirect-rules/

share|improve this answer
add comment

As Ram Prasad said, you need that Limit statement in the Directory entry in your vhosts.config file.

You also need a .DAV directory that is owned by apache in the same directory as your .htaccess file. I have found this usually causes the 403 error, as Apache uses this folder to write temporary files to.

See also: http://www.webdav.org/mod_dav/install.html

share|improve this answer
    
I added a .DAV dir to the top level (httpdocs) where .htaccess is and chowned to apache:apache. Still getting 403 error. –  Darren Newton Jun 5 '09 at 12:22
    
BTW - not using .htaccess to set directives, using vhost.conf (plesk) –  Darren Newton Jun 5 '09 at 12:22
    
The .DAV dir should be in the directory that you have configured to be shared by WebDAV, not in the top level httpdocs dir. –  tonyk Jun 5 '09 at 12:48
    
Tried it. I created a .DAV folder in my WebDAV folder, chowned to apache:apache and even chmod to 0777 still no luck. Tried creating a .dav folder as well just in case its a case issue. –  Darren Newton Jun 5 '09 at 12:59
    
Meant to say still getting the 403 - its rather baffling! –  Darren Newton Jun 5 '09 at 12:59
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.