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: [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)
    • [VFS-RFC] autofs4 and bind, rbind and move mount requests
      ... It is indeed disastrous for autofs. ... What should the semantics be for these type of mount requests against ... the newly mounted filesystem and so it would become useless and probably ... Bind mount requests are another question. ...
      (Linux-Kernel)