[SOLVED] apache2: configuration of mod_dav, mod_dav_fs

Howdie,

I gotta question about the configuration of mod_dav and mod_dav_fs on a apache2 instance. What I've got:

On a mountpoint (specifically: /var/data/) I have mounted a 3tb raid partition that stores all kind of data and I would like to share it through WebDAV. So I installed davfs2 on my client and set up the server site by adding:

Code:

---

ScriptAlias "/var/www/webdav" "/var/data"
<Directory "/var/www/webdav">
  Dav On
</Directory>

---

Finally I added the www-data user to the media group, which is the group that has read/write access to all the /var/data stuff (file mode for all contents is 660, chown is "some_owner_which_is_part_of_media:media").

Then a a2enmod mod_dav and a restart of the apache should arise it to life. Ok, fine until here. I mounted the davfs on my client pc and it worked like a glance. At least it looked like that. The contents were listed and I was happy. Later I tried to open some file on my client, but sadly it failed with an IO error. And here the problems begin.

I then looked at the apache logfiles and I immediatly saw the problem. Some kind of weird permission error comes up?! When I for example try to edit a dummy text file created on the server, it fails with something like this in the log message:

Code:

---

Failed to execute "/var/data/test.txt"

---

So I gave it execute permissions (chmod +x), but that didn't help. Then I realized that the /var/data mountpoint is mounted with the noexec option. Which means nothing can be executed and this is perfectly fine. Noone who puts data on that partition should be able to execute anything from it. As I can't say who puts what where, I wanna go the safe way and disallow any kind of execution of (possible malicious / virused) data.

So, is WebDAV really that stupid that it wants to execute a file when someone tries to open it remotely or am I doing something wrong?!

*BUMP*

No ideas?

Here the log entries that may or may not help someone:

Code:

---

==> /var/log/apache2/access.log <==
jin.local - - [26/Jun/2010:14:04:45 +0200] "PROPFIND /webdav/ HTTP/1.1" 207 25152 "-" "davfs2/1.4.5 neon/0.29.0"
jin.local - - [26/Jun/2010:14:04:46 +0200] "GET /webdav/test.txt HTTP/1.1" 500 823 "-" "davfs2/1.4.5 neon/0.29.0"

==> /var/log/apache2/error.log <==
[Sat Jun 26 14:04:46 2010] [error] [client 192.168.2.50] (13)Permission denied: exec of '/var/data/test.txt' failed
[Sat Jun 26 14:04:46 2010] [error] [client 192.168.2.50] Premature end of script headers: test.txt

---

And here another side note:

I can create files and I can edit them. So let's say, I created a file "test" on the server with the content "test" and another file I created from the client named "anotherTest" with the content "anotherTest". Now if I try to open "test", it fails with execute failed and if I open "anotherTest" it works perfectly fine.

Code:

---

# ls -la
-rw-r--r--  1 www-data www-data  22 2010-06-27 10:07 anotherTest
-rw-r--r--  1 www-data www-data    5 2010-06-26 19:28 test
# cat anotherTest
this is another test
# cat test
test

---

I truely can't see the (permissions) difference on the server side?! WTF

Alright, I'm ready to believe that I used it in a wrong way. Probably files are versioned in some way and as I just put files into the dav, he cannot open as he doesn't know that they're there. Any idea how one can add (large) amounts of data into dav without the need of copy / move them all, i.e. with a cronjob that somehow adds the data just as mercurial would do?

I could bang my head. The solution was simple:

Code:

---

        Alias /webdav/ /var/data/
        <Location /webdav/>
                DAV On
                AuthType Basic
                AuthName "Restricted Files"
                AuthBasicProvider file
                AuthUserFile /var/www/passwords
                AuthGroupFile /var/www/groups
                <LimitExcept PROPFIND>
                        require group webdav
                </LimitExcept>
        </Location>

---

Note the "Alias" in the place of "ScriptAlias". The reason why this works can be found here