More on autofs

Adam’s comment on my previous post on autofs in Leopard reminded me of some other improvements over the legacy automount program I hadn’t mentioned:

Wildcards:
The legacy automount doesn’t support these at all. autofs supports these, so you can have map entries like this:


* -rw,hard,intr host:/export/apps/&

If this entry was in the map associated with the /apps mountpoint, then a `cd /apps/foo` would attempt to mount host:/export/apps/foo on /apps/foo.

-hosts map

A special /net map is defined in /etc/auto_master that automatically mounts all exports from a given host:

/net -hosts -nobrowse,nosuid

This option existed under Tiger on PowerPC, but was broken on Intel. To use it, you’d cd to /net/hostname. An `ls` then shows all the available exports from hostname.


aquaman:~ root# cd /net/french
aquaman:french root# ls
rel sw vol

Variable Substitution

autofs supports variables in automount maps. ARCH, CPU, HOST, OSNAME, OSREL, OSVERS, and NATISA are directly supported. Most are defined by uname:

ARCH = `uname -m`
CPU = `uname -p`
HOST = `uname -n`
OSNAME = `uname -s`
OSREL = `uname -r`
OSVERS = `uname -v`
(If you look at the output of `uname -v` on OS X, you’ll see this isn’t terribly useful in an automount map… )
NATISA (NATive Instruction Set Architecture) = currently the same as CPU. No distinction between ppc and ppc64 or i386 and x86-64.

You can define additional variables in /etc/autofs.conf – see `man autofs.conf` for details.
These variables can then appear in automount maps, and their values will be substituted. To get similar functionality with the legacy automount program, you needed to use a script that did text substitutions – substituting the correct values for variable references.

You can find more info in the man pages for autofsd, automount, automountd, autofs.conf, and auto_master.
Most of the info here for Linux autofs.5 is also relevant.

More on autofs

8 thoughts on “More on autofs

  1. I was wondering what had borked the -hosts map in Tiger, I never put together that it was the move to Intel.

    Out of curiosity … what are your major sources of info for all this? I thought I was fairly well informed but just recently I’m seeing people with lots more knowledge with me about the details of Leopard. I’d love a recommended reading list!🙂

  2. My major sources of info are my Linux and Solaris sysadmin colleagues, my own reading of man pages and documentation for autofs for Leoaprd, Linux, and Solaris, my own experiments and testing, and some conversations with Apple’s autofs engineers, who I had the pleasure of meeting at WWDC last June. I credit them for pointing me in the right direction as I worked to get Leopard’s autofs working with our LDAP infrastructure, which was built with Linux autofs4 in mind. Prior to talking with them, I assumed that the format of auto.master in LDAP that Linux autofs4 was the “correct” format, and couldn’t understand why Leopard’s autofs failed to work with it. As with most things in life, reality is a little more complicated…

    I wish I had kept track of all the web-based documentation I read, but I’ll see what I can dig up…

  3. Thanks for that, sounds about the same as me (I’m a Linux/ex-Solaris admin who has started looking after Mac’s in the last couple of years).

    Sounds like there’s no gold mine of info that I was missing out on. Bugger.🙂

  4. Jeff says:

    Hi Greg, have you found a way to do ‘nested’ mounts in autofs? I’ve defined my mounts in the fstab file. I’ve simplified this fstab greatly, but it will work in illustrating my question.

    –begin fstab–
    server:/share /mount/point nfs 0 0
    server:/anothershare /mount/point/mounts/nestedmount nfs 0 0

    Basically, I have an NFS export that is mounted inside of another mountpoint. When I make this edit, things don’t work correctly. It makes it so that I cannot get to /mount/point defined in my fstab. When I CD to that directory, I only see mounts/nestedmount, not any of the other files that live in the root of that export. I have un-nested them, and it works fine. I can tell you that it works fine in Linux, and on 10.4 (NOT using automount. lookupd and fstab was used). Automount seems to choke on it.

    I hope that I’ve explained this well, but I’m wondering if this will work with autofs. Any ideas?

  5. Nested NFS automounts seem like a bad idea to me, but it looks like this should work in autofs by defining an automount entry with multiple mounts, ala

    auto_master contains a line like:
    /mount auto_point

    auto_point looks like
    point \
    / server:/share \
    /nestedmount server:/anothershare

    Not sure if it actually will work, though. Look at `man auto_master` and read the section on automounter maps. If the example above (which uses indirect maps) doesn’t work, you might try a direct map instead:

    /mount/point server:/share
    /mount/point/mounts/nestedmount server:/anothershare

    I wonder if any of this will actually work, though, as fstab entries are mounted by autofs using the special “-static” direct map. Your sample entries should be equivalent to the direct map entries I mention above.

    -Greg

  6. Jeff says:

    I have one last autofs complaint. Is there any way to get these mounts to show up on the users desktop? I know that if a mountpoint isn’t defined, they show up under the ‘shared…All…servers’ part of the finder sidebar. Everyone is used to having a nice grey globe on thier desktops that link them directly to the servers.

    My only workaround might be to create symlinks, and put them in the user template. That way they have their old desktop mounts back. This isn’t super elegant. Unfortunately we have a couple of divisions in our enterprise, that have completely different mounts.

    Have you found a way to make these mounts appear on the desktop?

  7. Integrating Leopard Autofs with LDAP

    In the two-part series titled “Autofs goodness in Apple’s Leopard (10.5)“, we took a detailed look at Leopard’s automount, autofs. In this article, we will look at the integration of leopard’s autofs with LDAP. There is not a …

  8. the nested mount does work well.
    auto_master:
    /test /etc/auto_test
    /test/top_dir2 /etc/auto_test_top2

    /etc/auto_test file:
    top_dir1 server1:/top_dir1

    #will be overwrite by auto_test_top2
    top_dir2 server1:/top_dir2

    /etc/auto_test_top2
    sub_dir server2:/sub_dir

    finally:
    /test/top_dir1 server1:/top_dir1
    /test/top_dir2/sub_dir server2:/sub_dir

    refer the sectioin 5.3: Multimounts and Offsets
    http://lwn.net/Articles/65193/,

Comments are closed.