1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Unable to properly mount the AdminDAV share

Discussion in 'Troubleshooting and Problems' started by Shadab, Feb 5, 2011.

  1. Shadab

    Shadab Well-Known Member

    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:

    Screenshot.png


    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

    [​IMG]
     
  2. Mike

    Mike XenForo Developer Staff Member

    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.
     
  3. Shadab

    Shadab Well-Known Member

    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
    Code:
    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
    Code:
    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?
     
  4. Mike

    Mike XenForo Developer Staff Member

    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.
     
  5. Shadab

    Shadab Well-Known Member

    #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.

    Code:
    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. :)
     

Share This Page