2.4.20 autofs: non-toplevel mounts broken?

From: Bob Proulx (bob_at_proulx.com)
Date: 07/30/03

  • Next message: Greg Folkert: "RE: Arpwatch (was : mac addresses)" 
    To: debian-user@lists.debian.org
Date: Tue, 29 Jul 2003 23:18:53 -0600 (MDT)

    After upgrading to 2.4.20 I seem to have lost the ability to autofs
    mount non-toplevel mounts. This worked in 2.4.18. Does not work in
    2.4.20. Has anyone else seen this?

    Here is the situation. An NFS server machine exports /mnt/a, /mnt/b,
    etc. but does not export the root filesystem. With 2.4.18 and autofs
    these were automatically mounted fine. But after an upgrade to 2.4.20
    from woody-proposed-updates this now fails. The /var/log/syslog shows
    this message:

    On server, /etc/exports:
      /mnt/a *(rw)

      Jul 29 22:43:52 misery automount[26757]: mount(nfs): calling mkdir_path /net/torment/mnt/a
      Jul 29 22:43:52 misery automount[26757]: mount(nfs): mkdir_path torment/mnt/a failed: Operation not permitted

    It is still possible to autofs nfs mount systems which do export the
    full hierarchy of filesystems from the root down.

    On server, /etc/exports:
      / *(rw)
      /mnt/a *(rw)

    If I return to the previous kernel then the mkdir_path does not log an
    "Operation not permitted" message and everything succeeds.

    Something really strange to my thinking is that the automount daemon
    from autofs did not change. Only the kernel was updated. The autofs
    side should not have changed. But since it is now not working I can
    only assume this is an interaction with the kernel which is causing
    this problem.

    Any clues?

    Thanks
    Bob 

    -- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: Greg Folkert: "RE: Arpwatch (was : mac addresses)"

    Relevant Pages

    • Re: Problem with mount.nfs4 on latest Fedora 10 updates
      ... Chuck Lever wrote: ... This occurs when autofs calls the mount program. ... The autofs mount has worked and the directories under /hosts/battleaxe have been successfully accessed prior to the problem occuring - I suspect this is a remount after and expire has occurred. ... It would seem that the problem is in the kernel - probably in the NFS4 code path. ...
      (Fedora)
    • Re: [autofs] [RFC] Towards a Modern Autofs
      ... >entangling autofs with that work. ... >filesystem it's willing to export. ... >>map is mounted. ... The result is that some users will see mount points ...
      (Linux-Kernel)
    • Re: [autofs] [RFC] Towards a Modern Autofs
      ... entangling autofs with that work. ... > map is mounted. ... I don't quite see the need for the mapkey mount option. ... But in sec. 5.3.2 I see you making filesystem dirs in /tmp which seem to ...
      (Linux-Kernel)
    • Re: How to Mount devices
      ... > I am testing a couple of versions of Linux, Knoppix and Fedora. ... > I want to open a console session and mount the same devices in Fedora, ... specify the file system. ... For such cases we have the autofs application. ...
      (alt.linux)
    • Re: [VFS-RFC] autofs4 and bind, rbind and move mount requests
      ... The result is very similar to move mount. ... > I don't think it should because autofs needs be true to the mount maps ... do_add_mountcall (which places the vfsmount on the expiry list), ... If you just want to disable bind, ...
      (Linux-Kernel)