autofs in Leopard

One of the features I’d been looking forward to in Leopard was autofs. We’re a heavily Linux shop here, and also have Sun boxes around. They all run autofs to implement their NFS automounts. I’d been frustrated and annoyed to have OS X be the odd man out – since Tiger and earlier releases of OS X used Apple’s proprietary automount program, which did not work like autofs. The two big deficiencies of Apple’s automount are that its automount maps are in a different format than autofs, and it does not do “mount-in-place”.

Additionally, we store our automount info in LDAP, which autofs supports, but Apple’s automount does not. I had to write and maintain a script that queried our LDAP server, retrieved the automount maps, then massaged them and wrote them out as flat files in a format that Apple’s automount liked.

So when I started working with the Leopard betas last summer, I was hoping that everything would just work.

I started by using Directory Utility to point the Leopard client to out LDAP server using the RFC2307 schema.
But it didn’t work! Grrr.

The Leopard box was seeing the automount maps, but wasn’t doing anything useful with them:

aquaman:Utilities root# dscl /LDAPv3/faldap.[...].com -list /AutomountMap

As it turns out, there are some forks in the autofs road. Apple’s implementation in Leopard is based on the OpenSolaris code, and very closely follows Sun’s implementation. Linux, specifically Red Hat Enterprise Linux 4 and earlier, which use autofs4, have some different ideas on the format of autofs automount maps.

The first difference is in the default naming: Linux’s autofs4 wants the master map to be named “auto.master”. Solaris and Leopard want it to be named “auto_master”. There are several ways around this issue. An easy one is to define a local auto_master file that references auto.master on the network. The default /etc/auto_master file looks like this:

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

You could change it to look like this:

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

and now autofs is looking for “auto.master” in Directory Services.

Another complication is that there are at least two different schemas in use for storing autofs automount info in LDAP. In the one that Leopard uses, automount maps have an object class of “automountMap”, and the attribute “automountMapName” is the name of the automount map. The map entries have an object class of “automount”, attribute “automountKey” is the key (typically the mount trigger point), and attribute “automountInformation” is the actual automount info.

There is an older schema where automount maps have an object class of “nisMap”, the attribute “nisMapName” holds the map name; map entries have an object class of “nisObject”, the “cn” attribute is the key or trigger point, and attribute “nisMapEntry” holds the actual automount info.

You can use Directory Utility to edit LDAP mappings if you find that you have the older schema.

More differences

A bigger problem is that Linux’s autofs4 and Leopard disagree on the proper format of the contents of the automountInformation/nisMapEntry attributes for children of the auto_master/auto.master map. Leopard, Solaris, and autofs5 on Linux all expect just the simple map name:

dn: automountKey=\/data, automountMapName=auto_master, [...],o=Disney,c=US
automountKey: /data
objectClass: top
objectClass: automount
automountInformation: -intr,noquota

autofs4 on Linux, however, wants a lot more info:

dn: automountKey=\/data, automountMapName=auto.master, [...],o=Disney,c=US
automountKey: /data
objectClass: top
objectClass: automount
automountInformation: ldap:faldap:",ou=autofs,
[...],o=disney,c=us" -intr,noquota

You can see that the entire LDAP DN of the map is in the automountInformation attribute. Leopard, Solaris, and autofs5 on Linux don’t like this format.

Executable maps are similarly affected:

dn: automountKey=\/cross, automountMapName=auto_master, ou=Autofs, [...],o=Disney,c=US
automountKey: /cross
objectClass: top
objectClass: automount
automountInformation: /usr/sbin/xmounter

vs Linux autofs4 format:

dn: automountKey=\/cross, automountMapName=auto.master, ou=Autofs, [...],o=Disney,c=US
automountKey: /cross
objectClass: top
objectClass: automount
automountInformation: program:/usr/sbin/xmounter

Note the “program:” tag added to the beginning of the automontInformation.

Sharp-eyed readers may have noticed my workaround: two master maps. One, named auto.master, in the format that autofs4 likes, and another, auto_master, in the format Leopard, Solaris, and autofs5 likes. As we move to autofs5 on Linux, we can get rid of the auto.master map.

One more thing

There’s one more difference that might trip you up: wildcards. The traditional wildcard mountpoint in autofs maps is an asterisk (“*”).

dn: automountKey=*, automountMapName=auto.facvs, ou=Autofs, [...],o=Disney,c=US
automountKey: *
objectClass: top
objectClass: automount
automountInformation: -vers=3 &:/disk1

For some reason, early implementations of LDAP-based autofs maps used a slash (“/”) instead as the wildcard key:

dn: automountKey=\/, automountMapName=auto.facvs, ou=Autofs, [...],o=Disney,c=US
automountKey: /
objectClass: top
objectClass: automount
automountInformation: -vers=3 &:/disk1

Leopard doesn’t recognize the slash as a wildcard. If you can, convert to asterisks. This works with autofs4 on RHEL4 at least.

With a little work (and maybe some cooperation from your Linux admins) you should be able to use LDAP to store autofs info that both Linux and Leopard clients can use.

autofs in Leopard

22 thoughts on “autofs in Leopard

  1. Adam, you’re right of course. What I meant was that Apple’s automount program could not use any _standard_ way of defining automount maps in LDAP. Your solution keeps automount data in LDAP, but in a completely different format than that used for your Linux boxes. It sounds like you were able to manage that, though. What Leopard’s autofs brings us is the possibility (once we move all our Linux clients to autofs5) of a single version of automount maps that work for all our UNIXy machines.

  2. True enough! For historical reasons we keep the canonical copy of our automount records in the old NIS style text files. We then wrote a couple of simple Perl scripts to publish any changes to our LDAP servers.

    Works nicely for us, but does require some tools.

    I hadn’t realised there was a Linux autofs5 in the works. I’ll have to have a look because autofs4 has been a major pain in our patooty.


  3. Shawn Duncan says:

    Tantalizingly close to what I’ve been looking for! I have two Leopard (client version, not Server) machines. What and how do I edit to automount an AFP share point from one machine onto the other?

  4. I too was very excited to see a real automounter included in Leopard.

    My biggest problem with it so far is that it doesn’t accept automount maps that include alternatives. Many of our automount maps look like:

    staroffice7 localhost,shasta:/opt1/&

    This is very useful, as it will check for a copy on the current machine
    and if there isn’t one there, then it goes out to the server.

    But their automounter chokes on this. I wonder why, since it’s
    supposedly the one from Solaris. I was going to report it as a bug,
    but noted they stripped any mention of this from the man page, so I
    can’t claim it as an error :-(.

  5. Shingi says:

    Hi Guys.
    I am seeing an interesting behavior with my Mac os leopard setup. When i connect resources on my nfs mount through finder i get permission errors because of group permisions, files i own work just fine.

    What is strange is that from the terminal i can access and edit or delete these same resoures just fine. But when i try and edit a file in finder it just wont work.

    Any ideas? I also have the machine hooked up to ldap.

  6. Jeff V says:

    Hi, I have seen the same problem that Shingi has seen. I have LDAP authenticated users, working on NFS volumes mounted via autofs. In some cases, the finder will not obey the unix permissions on a file. When I use the terminal, it works fine. I have seen this mostly related to group permissions. A directory will be 775, owned by username:chem. If I’m in the group chem, I will not have write permissions via the finder. But, if I got in via terminal I can write fine.

  7. Dave B says:

    Has anyone figured out how to do multiple levels of nested hierarchy? With autofs4 on linux I have:


    Some of those sites are on different servers, so I can’t just mount /hosted or even /hosted/web.

    Leopard seems to accept automountInformation: hosted at the top level, but not automountInformation: web at the next level.

  8. Dave B says:

    Ah, I don’t know why it took me so long to thing of this, but you need to specify it with -fstype=autofs, such as:

    dn: cn=web,ou=hosted,ou=autofs,dc=…..
    objectClass: automount
    cn: web
    automountInformation: -fstype=autofs web

  9. Fantastic! And makes perfect sense once you write it out. The fstype is NFS by default, so of course you must specify fstype=autofs….

  10. Tom McNicholas says:

    To do this, are you also required to go back into your LDAP mappings and map those attributes? Or do you simply rely on the configured LDAP search base, and it will find the proper auto.master based off that?


  11. Tom – what do you mean by “to do this”? To do exactly what?

    If your LDAP server has automounts and automountMaps defined using the RFC2307bis schema, or the autofs schema, and they are under the default search base, OS X will just find them and use them. If the naming or schema is not what OS X is expecting, you may have to remap attributes or make edits to /private/etc/auto_master to get OS X to derive useful info from LDAP.

    1. RyanS says:

      I could not find any way of getting OS X’s directory services to play nice with rfc2307bis. For example, with groups who identify their members by DN (rfc2307bis’s “member” attribute, instead of rfc2307’s “memberUid” attribute), OS X does *not* parse the DN-valued member attributes properly, when you map the OD attributes “GroupMembership” and/or “Member” to the OpenLDAP attribute “member”. It takes the DN-values attributes literally (e.g., uid=jdoe,ou=Users,dc=example,dc=com) and tries to match them up with a valid POSIX username (e.g., jdoe). The only solution I have found that works, which is extremely ugly, is using the slapo-rwm overlay on top of the slapd-relay backend to literally parse and rewrite the DN-valued attributes as plain UID’s, on the response’s way back to the OS X clients. Terrible.

  12. RFC2307bis automount maps are supported just fine in Leopard and Snow Leopard (which is what the original post was about). You are talking about groups, which I haven’t encountered (our LDAP implementation has just the traditional POSIX group format).


  13. Hi!

    Could someone hint me how I can tell one of my servers NOT to automount an afs autmountable directory,.. but still allow my clients to do so?


    p.s. (more details).
    I have user home directories on server1 in /Volumes/team1/users. Through WGM I have the following sharepoints defined:
    team1 /Volumes/team1
    users /Volumes/team1/users

    That users sharepoint has guest enabled.
    That users sharepoint has automount enabled (using AFP and with ‘use for home folders’ checked.

    AOK so far 🙂
    BUT (drumroll please…)

    The same drive is being mounted on server2 as /Volumes/team1 (yup.. it’s an XRaid on XSan FibreChannel).
    Here are the df’s for both servers:

    admin@server1:/ > df
    /dev/disk4 155954976 76947464 78751512 50% /
    devfs 189 189 0 100% /dev
    /dev/disk7 7324196864 3976125808 3348071056 55% /Volumes/team1

    admin@server2:~ > df
    Filesystem 1K-blocks Used Available Use% Mounted on
    /dev/disk3 155954976 45690688 110008288 30% /
    devfs 190 190 0 100% /dev
    /dev/disk7 7324196864 3976125808 3348071056 55% /Volumes/team1

    The mobile accounts (portable home directories) are working fine on the client machines. When I home sync on mac123 I see the following during sync (the mount goes away afterwards):

    user1@mac123:~ > df
    /dev/disk0s2 116753840 50364876 66132964 44% /
    devfs 108 108 0 100% /dev
    7324196864 3976125808 3348071056 55% /Volumes/users

    BUT (AIH aih aih!)
    if I ssh into server2…
    I get the following horror-story:

    user1@server2:~ > df
    /dev/disk3 155954976 45691372 110007604 30% /
    devfs 190 190 0 100% /dev
    /dev/disk4s2 155954992 99008 155855984 1% /Volumes/scratch
    /dev/disk7 7324196864 3976135456 3348061408 55% /Volumes/team1
    7324196864 3976135456 3348061408 55% /Volumes/team1/users

    OH MY GOODNESS!.. users is being mounted on top of the /team1 mount!

    Besides not being necessary (/Volumes/team1 contains a fully populated users folder… so I don’t really need/want to mount)
    but, even worse, this has the consequence that all other users logged in LOSE THEIR PERMISSIONS to access (the mount is ‘owned’ by user123):

    admin@server2:~ > mount
    /dev/disk3 on / (hfs, local, journaled)
    devfs on /dev (devfs, local, nobrowse)
    map -hosts on /net (autofs, nosuid, automounted, nobrowse)
    map auto_home on /home (autofs, automounted, nobrowse)
    map -fstab on /Network/Servers (autofs, automounted, nobrowse)
    /dev/disk7 on /Volumes/team1 (acfs, local)
    afp_4CklDY4dyApk4Cs3qI0ykk2M-1.2e00000c on /Volumes/team1/users (afpfs, nodev, nosuid, automounted, nobrowse, mounted by user123)


    What do I need to do to prevent that automount from happening (the one /Volumes/team1/users)?
    Preferably,.. I’d like to continue to allow other automounting to occur… but not if it involves /Volumes/team1 or anything underneath.

    Thanks for any help….
    Free beer to you any helpers who end up visiting Switzerland.


  14. ps.2: not Dynamic?

    It’s kinda weird that the mount is happening under /Volumes/team1/users, isn’t it? Since I’ve said (via ServerAdmin AFP) that /Volumes/team1/users is for ‘User home folders’, then it should be a dynamic mount point mounted in /Network/Servers (the ServerAdmin says as much too… but I read this here: old 2004 article.. has this changed for Snow Leopard?).

Comments are closed.