AutoFS and NFS improvements in Leopard

Filed under: Geekiness — iain @ 10:45:12

It’s fair to say that I’ve been disenchanted with my Leopard upgrades. My gripes are documented in these very pages. Recently, though, I’ve found some stuff in which Leopard is a real improvement over Tiger.


NFS support is much improved. NFSv3 with options tcp,rw,intr is massively more reliable. I don’t remember the last time the system completely hung and while it’s still possible to upset a Mac by killing its NFS server, a Leopard machine can now actually recover – perhaps with the help of a umount -f – when the file server comes back.

Leopard even has rudimentary NFSv4 support but this is little more than a novelty given that it has no idmapd, Kerberos doesn’t appear to work (at least for me, against a known working Red Hat system) and Apple force you to use ridiculous syntax to mount.

    # mkdir nfsv4
    # mount -o nfsvers=4 filer:/stuff nfsv4
    mount_nfs: sorry, you must specify vers=4.0alpha to use the alpha-quality NFSv4 support
    # mount -o nfsvers=4.0alpha filer:/stuff nfsv4


The Leopard automounter is also much better. Apple’s proprietary nonsense has been replaced with a real RFC2307bis implementation which is compatible with your existing LDAP rules.

Leopard’s stock /etc/auto_master looks like this:

    # Automounter master map
    +auto_master                # Use directory service
    /net                        -hosts          -nobrowse,nosuid
    /home                       auto_home       -nobrowse
    /Network/Servers    -fstab
    /-                  -static

This is interesting for a number of reasons. First of all it includes a /net entry allowing you to do something like the following, just like on a Linux or Solaris system:

    # cd /net/filer/share

Secondly you’ll notice the /Network/Servers entry which ensures back-compatibility with your Tiger mounts. There’s also a /home rule which is unexciting in itself but which influenced my choice of mount rules when I was configuring this.

The most important entry in the file is the first one.


This tells the automounter to look for a map called auto_master in the directory service. Let’s call this the map_name. Leopard will therefore go and make the following LDAP query:

    base="automountMapName=<map_name>,<mount_base>" filter="(&(|(objectClass=automount)))"

We’ve already seen that the map_name is auto_master. By default the thing I’ve called mount_base is just the search base configured when the LDAP server was added with Directory Utility. So on my network that would mean a search base of automountMapName=auto_master,dc=iain,dc=cx.

This wasn’t what I wanted. My AutoFS mounts were all under ou=mounts,dc=iain,dc=cx. Luckily you can change this in Directory Utility by editing the search base for the Automount and AutomountMap record types.


Now’s probably a good time to mention that if you configure your LDAP server with macosxodconfig, ie From Server and it was last configured from Tiger, you won’t have the automount record types and AutoFS won’t work at all! It took me a while to figure this one out. Depending on how many tweaks you’ve made to the stock mappings you might find it easier to create a brand new LDAP server configuration and re-apply your changes than to retrofit these mappings.

    Automount => automount
        AutomountInformation => automountInformation
        Comment => description
        RecordName => automountKey

    AutomountMap => automountMap
        Comment => description
        RecordName => automountMapName

Another gotcha!

The AutoFS schema that ships with Linux AutoFS5 has different OIDs for the automount objects to the ones in Apple’s schema. I had to slapcat my directory, delete the database, remove the autofs.schema from slapd.conf and slapadd the database so that the entries were catalogued correctly.

Furthermore the apple.schema in Leopard no longer has apple-user-homeDirectory but that’s OK because you’ll want to revert the mapping of NFSHomeDirectory to homeDirectory once you have AutoFS working properly.

Sharing automount entries with Linux

Now that OS X understands the same mount syntax as everyone else and we have it looking in the same search base, we can ditch (almost) the two copies of every map and share things. I decided to map /home to auto_home instead of auto.home as I had been, because that way it will actually work out of the box on Leopard even if auto.master doesn’t.

See, I told you the auto_home line in /etc/auto_master was interesting.

Here’s my schema.

    dn: automountMapName=auto_master,ou=mounts,dc=iain,dc=cx
    automountMapName: auto_master
    objectClass: top
    objectClass: automountMap

    dn: automountKey=/home,automountMapName=auto_master,ou=mounts,dc=iain,dc=cx
    objectClass: top
    objectClass: automount
    automountKey: /home
    automountInformation: auto_home

    dn: automountMapName=auto_home,ou=mounts,dc=iain,dc=cx
    automountMapName: auto_home
    objectClass: top
    objectClass: automountMap

    dn: automountKey=/,automountMapName=auto_home,ou=mounts,dc=iain,dc=cx
    objectClass: top
    objectClass: automount
    automountKey: /
    automountInformation: -fstype=nfs,rw,intr files:/home/&

    dn: automountKey=*,automountMapName=auto_home,ou=mounts,dc=iain,dc=cx
    objectClass: top
    objectClass: automount
    automountKey: *
    automountInformation: -fstype=nfs,tcp,rw,intr files:/home/&

Note I have two wildcard rules (hence the comment about almost ditching duplicate entries. Leopard understands * as a wildcard, like in flat files, but my Fedora 7 test clients still want / as a wildcard. In the future they might not need the workaround.

The final step on my Fedora clients was to play with /etc/sysconfig/autofs to uncomment the record mappings corresponding to this schema. But they might actually be the default on Fedora. I probably already changed them last time!


  1. Can you give some hints for autofs4 records I need to purge from my linux ldap server before using the macosx autofs schema ?

    Comment by chuntera — 2008-05-20 @ 21:44:22

  2. Anything that appears in both the apple.schema file (from the schema directory of any Mac) and your Linux schema should be checked. If the OIDs are different you’ll want to pick one before installing the apple.schema. automountKey, automountInformation, automountMapName etc are the things to look for.

    If you already have both schemas installed you shouldn’t have a problem as the server would have complained before now that you tried to redefine an attribute if there were any conflict.

    In my case the OIDs for the attributes were different so I couldn’t just remove the old schema and add the new one; the raw data was stored against the old OIDs.

    Comment by iain — 2008-05-20 @ 22:07:55

RSS feed for comments on this post.

Leave a comment

You must be logged in to post a comment.

Powered by WordPress