Unable to properly mount the AdminDAV share

[Shadab]

I've been trying to properly mount the XenForo AdminDAV share on Ubuntu 10.10, but something just doesn't work right. The share is mounted successfully, and I can browse all the css/html templates. But any changes that I make to a template are not saved.

Editing via nano just silently fails. And using gedit produces this error message:




AdminDAV is probably not the culprit here, as I can successfully save the template when the share is not "mounted". Could it be a permissions problem? Here's the setup:

$ uname -srv
Linux 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:48 UTC 2011

Mount point: /home/shadab/XenForo_Dev
(tried /media/XenForo_Dev as well, owned by root)

Mount type: davfs

 

[Mike]

It may be the process that davfs takes that is messing something up in the underlying code; we have a rather specific setup/set of requirements.

Unfortunately, debugging WebDAV stuff is nightmarish. Generally, I end up in Wireshark to determine the raw response info, which generally gives more specific error messages.

 

[Shadab]

I haven't tried Wireshark, yet. (Didn't know about it.)
Thought I'd clear the access logs and see the exact requests that were sent to AdminDAV...

gvfs: (gvfs/1.6.4)
Successful save

PROPFIND /Public_Templates/Master Style (0)/helloworld_view.html HTTP/1.1 207 834 - gvfs
PUT      /Public_Templates/Master Style (0)/helloworld_view.html HTTP/1.1 200 191 - gvfs
PROPFIND /Public_Templates/Master Style (0)/helloworld_view.html HTTP/1.1 207 834 - gvfs
PROPFIND /Public_Templates/Master Style (0)/helloworld_view.html HTTP/1.1 207 834 - gvfs
PROPFIND /Public_Templates/Master Style (0)/helloworld_view.html HTTP/1.1 207 834 - gvfs
PROPFIND /Public_Templates/Master Style (0)/helloworld_view.html HTTP/1.1 207 834 - gvfs

davfs: (davfs2/1.4.6 neon/0.29.3)
Fails

PROPFIND /                                                        HTTP/1.1 207 1952   - davfs2
PROPFIND /Public_Templates/                                       HTTP/1.1 207 4270   - davfs2
PROPFIND /Public_Templates/Master Style (0)/                      HTTP/1.1 207 179266 - davfs2
LOCK     /Public_Templates/Master Style (0)/helloworld_view.html  HTTP/1.1 200 778    - davfs2
LOCK     /Public_Templates/Master Style (0)/.goutputstream-PCN3PV HTTP/1.1 200 778    - davfs2
DELETE   /Public_Templates/Master Style (0)/helloworld_view.html  HTTP/1.1 412 677    - davfs2
PROPFIND /                                                        HTTP/1.1 207 1952   - davfs2
PROPFIND /Public_Templates/                                       HTTP/1.1 207 4270   - davfs2
PROPFIND /Public_Templates/Master Style (0)/                      HTTP/1.1 207 179266 - davfs2
PUT      /Public_Templates/Master Style (0)/.goutputstream-PCN3PV HTTP/1.1 412 677    - davfs2
UNLOCK   /Public_Templates/Master Style (0)/.goutputstream-PCN3PV HTTP/1.1 409 724    - davfs2
PUT      /Public_Templates/Master Style (0)/helloworld_view.html  HTTP/1.1 412 677    - davfs2
UNLOCK   /Public_Templates/Master Style (0)/helloworld_view.html  HTTP/1.1 409 724    - davfs2

gedit shows there was an error while renaming the temporary file.
But the temporary file wasn't created in the first place?

 

[Mike]

You can also see that it wants to do locking and delete the helloworld_view template (which gives it a 412 precondition failed, but I don't know why). There are 409's on the unlocks too.

We don't support locking - we just respond like we do, so it's possible there's a conflict there.

 

[Shadab]

#1. After much searching and debugging, I've found that neither AdminDAV nor the share mounted via davfs is at fault. It was gedit. The component which you least expect to be wrong! Here's the bug report:

https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/34813
(Reported in 2006! Affects smbfs, cifs, sshfs. And now davfs as well.)

#2. Figured out how to disable locking in davfs. Now I can successfully save the templates via nano. Gedit appeared to work, but it never saved the file. The DELETE request went though, and the last PUT request failed: effectively deleting the template.

GET      /Public_Templates/Master Style (0)/helloworld_view.html HTTP/1.1 200 361    - davfs2
PROPFIND /Public_Templates/Master Style (0)/                     HTTP/1.1 207 179266 - davfs2
DELETE   /Public_Templates/Master Style (0)/helloworld_view.html HTTP/1.1 204 199    - davfs2
PROPFIND /                                                       HTTP/1.1 207 1952   - davfs2
PROPFIND /Public_Templates/                                      HTTP/1.1 207 4270   - davfs2
PROPFIND /Public_Templates/Master Style (0)/                     HTTP/1.1 207 178778 - davfs2
PUT      /Public_Templates/Master Style (0)/helloworld_view.html HTTP/1.1 412 690    - davfs2

https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/177710
(Reported for Samba shares. But it applies to WebDAV too.)

#3. It's a good thing the last PUT request didn't succeed. If it did, a new template would have been created for the 'default' addon ID; which would be even harder to notice. As if the template deletion wasn't a major WTF already. Damn it, gedit. I want my 4 hours back.


tl;dr: Don't use gedit when dealing with files in network shares mounted via fstab. Nano and Eclipse work well.