#60 davfs2-1.0.2_p20060820 mount fails

closed-fixed
nobody
5
2006-10-07
2006-09-14
No

When I try to mount a webdav server using davfs2, the
mount fails, and my logs
contain (I skipped the login messages from mount.davfs):
Sep 13 17:28:59 [mount.davfs] Accepted by user.
Sep 13 17:28:59 [kernel] coda_read_super: device index: 0
Sep 13 17:28:59 [kernel] psdev_write: too much cnt: 28,
cnt: 32, opc: 2, uniq:
1
.
Sep 13 17:28:59 [kernel] coda_read_super: rootfid is
(01234567.ffffffff.0053ce20
.00000000)
Sep 13 17:28:59 [kernel] psdev_write: msg (0, 0) not found
Sep 13 17:28:59 [kernel] Failure of coda_cnode_make for
root: error -2
Sep 13 17:28:59 [mount.davfs] Got singal 15:

With davfs2-0.2.8 everything works perfectly . Then the
log shows:

Sep 13 17:33:05 [kernel] coda_read_super: device index: 0
Sep 13 17:33:05 [kernel] coda_read_super: rootfid is
(01234567.ffffffff.00527e70
.00000000)
Sep 13 17:33:05 [kernel] coda_read_super: rootinode is
3073017191 dev coda

The webdav server is accessed using https with a
username and password. Unfortunately I can't give you
these. I am using the gentoo-packaged version of davfs2.

This bug might be related to the one described in
http://bugs.gentoo.org/show_bug.cgi?id=144949

Discussion

  • Maik Nijhuis

    Maik Nijhuis - 2006-09-14
    • summary: davfs2-1.0.2_p20060820 broken --> davfs2-1.0.2_p20060820 mount fails
     
  • Werner Baumann

    Werner Baumann - 2006-09-15

    Logged In: YES
    user_id=1260327

    Hello Maik,

    I assume your working on a 64-bit machine. In this case:

    There is a bug in davfs2 concerning alignment of data
    structures. You may look at
    http://sourceforge.net/forum/forum.php?thread_id=1559956&forum_id=82589
    which seems to be the same bug.

    You may use the latest version of davfs2-1.0.2 from CVS or
    just apply the simple patch I suggestet in the above forum
    thread. But there are still open problems.

    I am working on a new version of davfs2 that will propably
    solve this issues (it also will include support for the fuse
    kernel module). The beta version should get ready until the
    end of this month and it might be a good idea to wait for
    this, if the CVS version will not help.

    Greetings
    Werner

     
  • Nobody/Anonymous

    Logged In: NO

    That's wahat I got as a Response from the Kernel Mailing
    list (originally I suspected coda to be in error):

    Opcode 2 = CODA_ROOT, the kernel module expects a 28 byte
    response from davfs,
    but the davfs daemon is sending 32 bytes of data.

    The expected response is described bythe following structure,

    struct coda_root_out {
    struct coda_out_hdr oh;
    struct CodaFid VFid;
    };

    coda_out_hdr consists of 3 32-bit integers
    (opcode/unique/result) and CodaFid
    consists of 4 32-bit integers. 7 * 4 = 28, so the bug is
    with the davfs application.

     
  • Werner Baumann

    Werner Baumann - 2006-10-03

    Logged In: YES
    user_id=1260327

    Hello Maik,

    the coda peaple ar right.

    I believe I fixed this bug in the new release 1.1.1. But I
    don't have acces to a 64 bit system. So I am very curious to
    hear about your experience.

    Greetings
    Werner

     
  • Maik Nijhuis

    Maik Nijhuis - 2006-10-04

    Logged In: YES
    user_id=1289105

    Hi Werner!

    Good news! 1.1.1 works on my 64 bit system! I tried both
    coda and fuse, and neon versions 0.24.7 (only coda) and
    0.26.1 (coda and fuse).

    However, there are some 64-bit related compilation warnings.
    At amd64, a pointer is 8 bytes while an int is still 4
    bytes, so gcc gives a warning about casting an int to a
    pointer at dav_coda2.c, lines
    218,233,235,248,267,289,356,381,399,428,435,450,479,519, and
    570. At dav_fuse5.c, line 695 it says argument 1 is passed
    to dav_write with an incompatible pointer type. dav_fuse7.c
    has the some warning at line 828.
    kernel_interface.c has warnings at lines 251 and 262:
    unsigned int format, different argument type (arguments 6 and 7)

    And there's also something else: When I try to mount a
    webdav server as a user, I get the following error:
    /sbin/mount.davfs: You can't mount into another users home
    directory.
    "/" is the home directory of nobody.

    Indeed, my passwd file shows the line
    nobody:x:65534:65534:nobody:/:/bin/false

    So either your check in mount_davfs.c, lines 571 to 590, is
    invalid or the gentoo people or doing something wrong. Other
    user mounts (e.g. dvd drive) work fine.

     
  • Werner Baumann

    Werner Baumann - 2006-10-04

    Logged In: YES
    user_id=1260327

    Hello Maik,

    thanks for the detailed information.

    Compiler warnings:
    As far as dav_fuse5.c, dav_fuse7.c and kernel_interface.c
    are concerned, there are no real problems and I can fix the
    code to avoid the warnings.
    But with dav_coda2.c there is a real bug: In the message
    structure of coda kernel version 2 there are only 32 bit for
    the node number. But davfs2 uses pointers as node numbers;
    so this can not work on 64 bit systems. I will have to
    disable this interface for 64 bit systems. But no 64 bit
    system will use coda kernel version 2 anyway (I believe).

    "/" is the home directory of nobody:
    I will have to change the message into "...user nobody". It
    is confusing.
    Background:
    As mounting a resource from a remote webdav server might be
    even more dangerous than mounting a CDROM (?), I felt the
    need to put additional restrictions on user mounts (that are
    not allready demanded by mount). One restriction is, that a
    user may not use a mountpoint that lies in the home
    directory of somebody else (mount_davfs.c, lines 571 to 590).
    Unfortunately gentoo makes the file system root "/" the home
    directory of user nobody (the same problem is reported by
    Toralf Foerster, feature requests 1488505), so almost
    everthing belongs to the home directory of user nobody.
    I believe this is a bad choice by gentoo. Maybe you can get
    some information about the reasons for this. On my Debian
    Sarge system the home directory of nobody is "/nonexistent",
    which does not exist. Nobody never complained about this.

    So I would prefer to let the extra restrictions intact,
    until I get notice of good reasons why "/" should be the
    home of nobody. (Of course you can remove it, if you don't
    like it. As far as I can see, this will not affect the rest
    of davfs2.)

    Greetings
    Werner

     
  • Werner Baumann

    Werner Baumann - 2006-10-05

    Logged In: YES
    user_id=1260327

    Hello Maik,

    I just uploaded bug fixes for the 64 bit problems to CVS.

    It would be nice if you could get the sources from CVS and
    test whether they now compile on a 64 bit systems without
    compiler warnings.

    If you don't like to get get the sources from CVS I could
    send a prerelease package to you.

    Greetings
    Werner

     
  • Maik Nijhuis

    Maik Nijhuis - 2006-10-05

    Logged In: YES
    user_id=1289105

    Hi Werner!

    When I look at the CVS repository at sourceforge, all files
    are more than 2 months old. It contains release 0.2.8. This
    is both when checking out the files using
    anonymous@dav.cvs.sourceforge.net:/cvsroot/dav
    and when using the CVS web interface
    (http://dav.cvs.sourceforge.net/dav/).
    Only the files section mentions v1.1.1.

    Do I have to use a different repository, or provide special
    cvs options?

    Sending a prerelease package would also work but I prefer CVS.

    Greetings,

    Maik

     
  • Werner Baumann

    Werner Baumann - 2006-10-05

    Logged In: YES
    user_id=1260327

    Sorry, I forgott about this.

    The organization of our repository is not very straight
    forward, and davfs2 1.1.1 is in a branch.

    After login, like described on the cvs page:

    cvs
    -d:pserver:anonymous@dav.cvs.sourceforge.net:/cvsroot/dav login

    (Just hit return for password)
    you get the latest sources with this command:

    cvs -z3
    -d:pserver:anonymous@dav.cvs.sourceforge.net:/cvsroot/dav co
    -r v1 -P davfs2

    The important parts are
    -r v1 (this is the branch)

    and
    -P davfs2 (this is the module)

    Greetings
    Werner

     
  • Maik Nijhuis

    Maik Nijhuis - 2006-10-07
    • status: open --> closed-fixed
     
  • Maik Nijhuis

    Maik Nijhuis - 2006-10-07

    Logged In: YES
    user_id=1289105

    With -r v1 it indeed works perfectly. I'd never used cvs
    branches before.. All compiler warnings are gone! And it
    still works , both with coda and fuse. When I rmmod both the
    coda and fuse modules, the fuse module gets loaded
    automagically.

    I tried searching forums.gentoo.org for a reason why
    'nobody' has '/' as homedirectory but I couldn't find it. I
    don't want to spend more effort in that. If you really want
    to know, you can create a free account there and ask the
    question.

    I'll close the bug because everything works fine. If you
    need to test a new version @ amd64, please let me know. My
    email is manyac (at) gmail (dot) com.

    Thanks Werner!

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks