In fact my home directory is only as small as it is because I moved a wodge of files to a separate storage area. The Documents directory, in which my Mac wants to save … pretty much anything … is actually a symlink to /files/iain/Documents which is automounted from somewhere else. And since my documents are the kind of things which I like to have available all over the place, that same directory is also shared by Samba and my Windows roaming profile knows to go there when I try to open (My) Documents. Some other directories are similarly shared across operating systems, including Desktop, Pictures and Movies.

I’d been thinking for a while that it might be better to move these well-known file stores into their own separate ZFS filesystems on my fileserver. Things came to a head this very evening when I downloaded Steam for Mac only to have it refuse to install because Library/Application Support/Steam wasn’t on a case-insensitive filesystem. It occurred to me that if Library were its own filesystem as I’d been considering, I could make it case-insensitive and trim the size of my home directory by a considerable margin. Although I wouldn’t advocate actually doing it in so crude a way, I believe that a home directory should be small enough that if you were given a UNIX account on a new system you should be able to get yourself up to speed by quickly transferring your entire home area from another environment. A home directory should be for dotfiles, SSH keys and the like. Everything else (real documents) should go Somewhere Else.

Since I use the automounter for everything I figured this would be pretty simple. As it turns out it actually is. The syntax works with Mac, Solaris and Linux as is documented to a greater or lesser extent in each system’s AutoFS manpages. The only potential stumbling block was getting it to work with LDAP but ended up being just as simple as you might hope.

The syntax to have the automounter mount a subdirectory of a configured mount is as follows, in auto.home for instance:

    * / files:/export/home/& /Library files:/export/library/&

So for all x /home/x will be mounted from fileserver:/export/home/x and /home/x/Library will be mounted from fileserver:/export/library/x.

On Linux I found I didn’t need the initial / by itself but both Mac and Solaris didn’t work without it. Another gotcha was that the Library directory had to actually exist in the original directory for it to be mounted from the specified location. In other words it wasn’t sufficient to export /export/home/iain and /export/library/iain from my file server. I also needed to create /export/home/iain/Library for it to be mounted.

In LDAP speak my auto.home became:

    dn: cn=/,ou=auto.home,ou=mounts,dc=iain,dc=cx
    objectClass: automount
    cn: /
    automountInformation: -fstype=nfs,tcp,rw,intr / files:/export/home/&
     /Library files:/export/library/&

To automount more subdirectories it suffices to add more bits to the automount entry.

    dn: cn=/,ou=auto.home,ou=mounts,dc=iain,dc=cx
    objectClass: automount
    cn: /
    automountInformation: -fstype=nfs,tcp,rw,intr / files:/export/home/&
     /Library files:/export/library/& /Documents files:/export/documents/&

And by redirecting my Windows shell folders to point to these filesystems in their CIFS form I can share them between operating systems.

    filter="(&(|(objectClass=automount))(|(automountKey=.DS_Store)))"
    filter="(&(|(objectClass=automount))(|(automountKey=.hidden)))"
    filter="(&(|(objectClass=automount))(|(automountKey=\2A)))"
    filter="(&(|(objectClass=automount))(|(automountKey=\2A)))"

This was because the Mac wanted to see what was under /home, on which home directories were automounted. It would be annoying if all it did was fill my LDAP logs with this spam. When the automounter causes Rebecca’s machine to kernel panic once every few days, it gets extremely tiresome.

My response to this was to change the automount rules so that /home was managed by auto_static instead of auto_home.

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

On the Linux clients this worked. The Macs, however, were having none of it. With this setup /home was completely inaccessible. All attempts to look at the directory, even ls -ld failed with Permission Denied. The solution is to comment out the /home line in /etc/auto_master.

As a poster in the above thread puts it, sigh.

NFS

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
    #

AutoFS

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.

    +auto_master

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.

Gotcha!

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!

It’s been an eventful day which started and ended with frustration but finishes with a greater understanding of network home directories, a working AFP server and cleartext passwords finally banished.

I sent my fileserver down for reboot to install the latest Linux kernel. At this point my iMac, on which I had a desktop session, became very very upset. My home directory is NFS mounted and when the server went away the client became totally unusable. Even when the server came back up it wouldn’t re-establish the mounts.

UNIX machines traditionally tend to choke when NFS servers go away but the Mac automounter absolutely refused to come back to life and I had no option but the reboot the machine. I wondered if AFP home directories would be more reliable.

It turns out they are but there’s a fatal flaw. An ssh connection to the machine won’t mount the AFP home which means they’re only useful for a desktop session. At least I did get them working though.

Netatalk

The netatalk software suite contains the AFP server afpd and it was actually very simple to set up. Two config files were all that were needed.

/etc/netatalk/afpd.conf:

    - -noddp -uamlist uams_dhx_pam.so,uams_gss.so \\
      -k5service afpserver -k5keytab /etc/krb5.keytab \\
      -k5realm IAIN.CX -fqdn files.iain.cx:548

/etc/netatalk/AppleVolumes.default:

    ~ "home" adouble:v2

The only daemon that needs to be started is afpd which, with the above configuration, advertises a share called home which maps to the connecting user’s home directory.

The prerequisites for this are a working /etc/pam.d/netatalk configuration and an entry in /etc/krb5.keytab for afpserver/files.iain.cx. Users can then authenticate either with PAM (passing a username and password) or Kerberos.

LDAP configuration

Users need an apple-user-homeurl entry (mapped to HomeDirectory in DirectoryService) of the form:

    <home_dir><url>afp://server/share</url><path>username<path><home_dir>

For example:

    <home_dir><url>afp://files/home</url><path>iain<path><home_dir>

They still need the apple-user-homeDirectory entry which refers to where the share will be mounted. If NFS automounts are in use (as they are in my network) you can’t reuse /Network/Servers so /home/username is a good choice (it will be automatically created as needed). This, I suppose, is why the default LDAP mappings have NFSHomeDirectory in DirectoryServices mapping to homeDirectory in LDAP…

Plaintext passwords banished

You may recall that I stated that passwords needed to be stored in plaintext because Mac clients tried a CRAM-MD5 bind to the directory server in order to validate a user’s logon credentials.

This is actually a fallback. The clients first attempt to authenticate with Kerberos. The only problem was that I’m using the Heimdal implementation because of its seamless integration with Samba and by default principals are not allowed to get proxiable tickets. I tried setting proxiable = false in /Library/Preferences/edu.mit.Kerberos but this flag was not honoured (although it is if you run kinit on the command line).

Heimdal is great because if you tell it you are joebloggs it looks for a user in LDAP with the sambaSamAccount objectClass and compares the password you provide against the NTLM credentials stored for that user. Effectively this means that you get Kerberos for free when you set up Samba with an LDAP backend.

But if you don’t also add the krb5KDCEntry objectClass you won’t be able to change the principal’s flags which means that the default disallow-proxiable flag will be set for the user and when the Mac comes along and asks for a proxiable ticket the request will be denied. You won’t be able to log on even though you got the right password. And then the Mac tries CRAM-MD5 instead.

The fix was to add some attributes to my user entries.

    dn: cn=iain,ou=users,dc=iain,dc=cx
    objectClass: krb5KDCEntry
    krb5PrincipalName: iain@IAIN.CX
    krb5KeyVersionNumber: 1
    krb5KDCFlags: 70

krb5KDCFlags=70 happens to be the default set of flags minus disallow-proxiable.

Now I can authenticate with Kerberos and I don’t need to store my passwords in plaintext. Hurrah.

Last time I hinted at getting automount and DHCP-supplied LDAP settings working. I gave up on DHCP since a) I tried to get it working last year at CacheLogic and failed; b) I couldn’t find much documentation on it; c) the documentation I did find suggested that it only provides an LDAP server and base, which wouldn’t be sufficient on my network because of the attribute mappings needed to placate DirectoryService.

I did get automount working, however. And as a special bonus I got it working on a Linux machine too. Since there isn’t a massive amount of useful documentation out there for AutoFS and LDAP, I’ll talk about the Linux configuration here as well as the Mac configuration.

Automounted home directories are typically used on big networks with many users. The idea is that you define a mountpoint, say /home and when a user process tries to access a subdirectory of that mountpoint, the automounter dynamically mounts it according to a mapping stored in NIS, flat files (boo, hiss!) or LDAP. The subdirectory is unmounted again a short time after the last process finishes with it. In big networks you can use this functionality to have certain users’ home directories stored on different file servers from other users’. In smaller networks you might just mount the whole of /home from one server (the benefit of automounting being that you don’t need to edit the fstab on each client). And in networks with two clients and two users, automounting redefines overkill.

Sounds like my network!

Automounting on Mac

Our old friend the Apple schema defines the mount objectclass which contains the same details we previously stuck in NetInfo. The schema is fairly self-explanatory if you read Part 2.

    dn: cn=files:/home,ou=mounts,dc=iain,dc=cx
    objectClass: mount
    cn: files:/home
    mountType: nfs
    mountOption: net
    mountOption: -P

Really quite simple. The cn is the exported share we’ll be mounting and since the net option is defined, the place we’ll be mounting it in is /Network/Servers/files/home.

If you wanted to do a per-user mapping you could have individual entries viz:

    dn: cn=files1:/home/user1,ou=mounts,dc=iain,dc=cx
    objectClass: mount
    cn: files1:/home/user1
    mountType: nfs
    mountOption: net
    mountOption: -P

    dn: cn=files2:/vol/vol1/home/user2,ou=mounts,dc=iain,dc=cx
    objectClass: mount
    cn: files2:/vol/vol1/home/user2
    mountType: nfs
    mountOption: net
    mountOption: -P

And so on…

Automounting on Linux

The AutoFS package installed with modern Linux distributions uses a different schema. Actually it understands two schemas, one being an older format that Solaris used to use. The one I used is the automountMap type. Configuring it is a bit more of a black art than the simple Mac way described above.

On the client you edit /etc/nsswitch.conf and set

    automount: ldap

You also make sure that /etc/ldap.conf is set up correctly.

Upon startup the automount searches for (&(objectClass=automountMap)(ou=auto.master)) and, assuming such an entry exists, (objectClass=automount) under the base it found. This means that the client requires zero configuration if you create the correct objects in LDAP.

Here’s the schema I set up:

    dn: ou=auto.master,ou=mounts,dc=iain,dc=cx
    ou: auto.master
    objectClass: automountMap

    dn: cn=/home,ou=auto.master,ou=mounts,dc=iain,dc=cx
    cn: /home
    objectClass: automount
    automountInformation: ldap:ou=auto.home,ou=mounts,dc=iain,dc=cx

This tells the automounter that it should handle /home and that it should consult ou=auto.home,ou=mounts,dc=iain,dc=cx to find out what to do with it.

    dn: ou=auto.home,ou=mounts,dc=iain,dc=cx
    ou: auto.home
    objectClass: automountMap

    dn: cn=/,ou=auto.home,ou=mounts,dc=iain,dc=cx
    objectClass: automount
    cn: /
    automountInformation: -fstype=nfs,tcp,rw,intr files:/home/&

Here cn=/ is a wildcard, meaning whatever is requested under the mapping, and the ampersand in files:/home/& is substituted with the value of the wildcard.

In flat file terms it’s equivalent to:

    * -fstype=nfs,tcp,rw,intr files:/home/&

This means that whenever I try to access /home/iain, the automounter will try to mount files:/home/iain and show me what’s there.

A per-user configuration would, as I’m sure you can guess, require an LDAP entry such as this:

    dn: cn=iain,ou=auto.home,ou=mounts,dc=iain,dc=cx
    objectClass: automount
    cn: iain
    automountInformation: files:/home/iain

You’ll notice that the Mac and Linux configurations aren’t strictly speaking the same. The Mac configuration mounts files:/home directly whereas the Linux configuration mounts files:/home/X on demand for all X. In a large network you’d want to do things the way I’ve set up Linux. On my network I want to do things the way I’ve set up the Mac.

Ways to get around this:

• Remove /home and symlink it to /net/files/home. This would work out of the box with AutoFS.
• Undo the NFSHomeDirectory mapping from Part 3 and set up an automount entry for /Network/Servers/files/home; set users’ home directories under there. In other words adapt the UNIX environment to the Mac, not the other way round.

Now I had belsunce and maling configured so that Rebecca and I could log on at either machine and get the same UID and GID for our accounts. Additionally, maling was set up so that users could have NFS home directories. Rebecca’s account was set up to take advantage of this.

The next step is to do away with local accounts on maling altogether (remember that for the moment I’m keeping local details on the laptop; it could be an LDAP secondary I suppose). Users there will authenticate against LDAP instead.

I’m going to deviate a little from the "this is how to do it on the command line" side of things this time because these steps are a bit of a hassle to do at the terminal. You can put the configuration in DHCP, apparently, so maybe there will be further episodes with an easier way of doing this stuff.

And in fact I’m going to deviate a little from the client side altogether. The stuff below will make more sense with the correct Apple schema installed on our LDAP server. Any Mac has the latest schema installed in /etc/openldap/schema/apple.schema which just happens to be the default OpenLDAP schema directory. Copy the schema file into the right place on your LDAP server. Beware that you might need to edit the file to keep slapd happy. Perhaps Apple turn off schema checking because the version on belsunce didn’t actually work. This was because the apple-user objectclass which it defines referenced some attributes which were commented out or defined later in the file (and hence strictly unavailable). After sorting all the objectclass definitions to the end of the file and uncommenting attributes I was able to satisfy slapd. Don’t forget to check your configuration with slaptest!

Back on the client, the first thing to do is to open Directory Access.app and enable LDAPv3. Click the Configure button and authenticate. You’ll need to click New to tell the tool about the new LDAP server. At this point a box pops up for you to enter the server details. With my setup this just hangs forever after entering the LDAP address so I would hit Manual.

You then have the chance to enter a Configuration Name which can be anything. Use your domain name or something. The Server Name or IP Address is the name or IP of the LDAP server. The LDAP Mappings is interesting. Choose RFC2307 for now. You’re prompted for your search base which you should now enter. If you don’t know what to put here you shouldn’t be reading this post.

Click OK and fire up a terminal to see what we’ve done so far.

Readers who’ve been following this series might expect that the details of the server you just added will be visible to dscl. In the output below I’m going to substitute the actual names with the headings from the Directory Access.app configuration to show how they’re mapped.

    $ dscl localhost -read LDAPv3/Server Name or IP Address
    TrustInformation: Anonymous Encryption
    AuthMethod: dsAuthCrypt dsAuthClearText dsAuthNodeNativeCanUseClearText dsAuthNodeNativeCannotUseClearText
    AccountName: No Account Name
    NodePath: LDAPv3 Server Name or IP Address
    ReadOnlyNode: ReadWrite
    RecordType: Groups CertificateAuthorities Mounts Users People
    RealName: Configuration Name

You can now also search for LDAP users. Let’s assume from now on that my LDAPv3 Server Name or IP Address was ldap.iain.cx.

    $ dscl localhost -list /LDAPv3/ldap.iain.cx/Users
    iain
    maling
    ...

These users are, however, not yet accessible to DirectoryService and hence cannot authenticate. Back in Directory Access.app you can select the Authentication pane, set Search to Custom path and Add the NetInfo path /LDAPv3/ldap.iain.cx.

By the way the file changed is /Library/Preferences/DirectoryService/SearchNodeConfig.plist.

After applying the configuration you should be able to see the users.

    $ dscl localhost -read /Search/Users/maling
    cn: maling
    description: Rebecca Ma
    displayName: Rebecca Ma
    gecos: Rebecca Ma
    gidNumber: 100
    homeDirectory: /home/maling
    loginShell: /bin/bash
    objectClass: person inetOrgPerson posixAccount shadowAccount sambaSamAccount
    sn: Ma
    uid: maling
    uidNumber: 314
    AppleMetaNodeLocation: /LDAPv3/ldap.iain.cx
    Comment: Rebecca Ma
    NFSHomeDirectory: /home/maling
    PasswordPlus: ********
    PrimaryGroupID: 100
    RealName: maling
    RecordName: maling
    RecordType: dsRecTypeStandard:Users
    UniqueID: 314
    UserShell: /bin/bash

    $ id maling
    uid=314(maling) gid=100(users) groups=100(users)

This looks mostly OK but if you read Part 2 you might guess what’s bad about the following:

    NFSHomeDirectory: /home/maling

NFSHomeDirectory is actually the local mountpoint, not the server export of the home directory. This isn’t going to work because there is no /home/maling on the Mac.

    ls ~maling
    ls: /home/maling: No such file or directory

The fix for this is to set up an attribute mapping which will translate attributes in the LDAP schema to key names as understood by DirectoryService.

Back in Directory Access.app, Edit the LDAPv3 you added and open the Search & Mappings pane. It should still say Access this LDAPv3 server using RFC2307 (Unix) because no changes have been made.

Below are two columns. On the left, Record Types and Attributes; these are the DirectoryService names for things. On the right, the items Map to their LDAP equivalents.

Expand Users and find NFSHomeDirectory. This maps to homeDirectory in LDAP. Well it shouldn’t do. According to the Apple documentation, the correct attribute in their schema is apple-user-homeDirectory. We Delete homeDirectory from the mapping and Add apple-user-homeDirectory in its stead. Notice that RFC2307 is now Custom after making the change.

Incidentally the file that is edited by playing with this graphical tool is /Library/Preferences/DirectoryService/DSLDAPv3PlugInConfig.plist.

Of course we still need to add this information to Rebecca’s user information in LDAP. This means adding the following attributes.

    dn: cn=maling,ou=users,dc=iain,dc=cx
    objectclass: apple-user
    apple-user-homeDirectory: /Network/Servers/files/home/maling

Go back and read Part 2 if you are wondering where I got the path from.

Now things look better.

    $ dscl localhost -read /Search/Users/maling NFSHomeDirectory
    NFSHomeDirectory: /Network/Servers/files/home/maling

Rebecca should be able to log on. But note that the Mac will attempt to verify her password by making a SASL bind to the LDAP server using the CRAM-MD5 mech. This means you need a line in slapd.conf:

    sasl-regexp ^uid=(.*),cn=cram-md5,cn=auth$ cn=$1,ou=users,dc=iain,dc=cx

And since CRAM-MD5 requires a plaintext password in the directory, she needs a userPassword in clear text.

Some more tricks

You can set a user picture in LDAP. This is used in the fast user switching menu and for the default Mail, Address Book and iChat avatar. The picture must be in TIFF format and the attribute to set is apple-user-picture. It should be mapped to the Picture attribute. Because Rebecca had previously set a user picture for her NetInfo account, I was able to copy it from maling:/Library/Caches/com.apple.user501pictureCache.tiff to files:/home/shared/maling.tiff and set:

    dn: cn=maling,ou=users,dc=iain,dc=cx
    apple-user-picture: /Network/Servers/files/home/shared/maling.tiff

Kerberos works more or less out of the box. Copy your UNIX /etc/krb5.conf to /Library/Preferences/edu.mit.Kerberos (the file is called edu.mit.Kerberos). If DNS works the file can be as simple as:

    [libdefaults]
      default_realm = IAIN.CX

And install a server keytab in /etc/krb5.keytab as usual.

sshd works with no changes needed. I haven’t looked at LoginWindow yet (/etc/authorization).

Assuming I get it working, I’ll post about DHCP and LDAP automounts next time.

Since I sometimes take my MacBookPro out with me it makes sense that I have a local user account to log on. Rebecca’s Mac Mini, on the other hand, never leaves the house. It’s a prime candidate for mounting user home directories over NFS.

To do this we need our friend the automounter. Automounts can be configured in old-skool flat files. They can be imported from LDAP or NIS with the DirectoryService. Or they can be taken direct from NetInfo. That’s what we’ll use here.

Automounts go into NetInfo (under /mounts) as a record whose name is the path to the export, in the form server:/path. You can create them with /Applications/Utilities/Directory Access.app (I believe this is due to be renamed in OS X 10.5) and there are several documents floating around the internet describing how to use that tool. If you understood Macs at home; Part 1 you will probably have guessed that it’s pretty simple to use nicl to set up an automount.

The homedirectories on files are exported as /home so our automount is created like so:

    # nicl -create . /mounts/files:\\\\/home

Note the double backslash between files: and /home. This is to escape the / lest nicl interpret it as a separator in the NetInfo hierarchy. The second backslash protects the first from being eaten by the shell.

    # nicl . -append /mounts/files:\\\\/home vfstype nfs

This defines the mount as an NFS share.

    # nicl . -append /mounts/files:\\\\/home opts -P

This line instructs automount to add the -Poption to mount calls when trying to mount the share. The -P option specifies that a privileged local port should be used. This is required by the NFS daemon on files. It might not be needed on your network. Try it if your NFS server gives a permission denied error when you try to mount the share.

    # nicl . -append /mounts/files:\\\\/home opts net

The net option instructs automount to mount the share under /Network/Servers. Since the share is files:/home it will be mounted at /Network/Servers/files/home.

Without the net option you would need to add a dir option with the key being the local mountpoint where the share should be mounted. The problem in this situation is that you then have to choose between mounting /home over /Users – thus trashing local home directories – or adding one automount for each user.

The only remaining step is to restart automount.

    # killall -HUP automount

The contents of /home on files will now be available at /Network/Servers/files/home and in particular Rebecca’s home directory is at /Network/Servers/files/home/maling.

There is one sticking point, however. The system expects Rebecca’s home directory to be at /Users/maling. This can be fixed with our old friend dscl.

    # dscl localhost -create /NetInfo/Users/maling NFSHomeDirectory /Network/Servers/files/home/maling

Update 2007-10-31: On Leopard the syntax is:

    # dscl localhost -create /Local/Default/Users/maling NFSHomeDirectory /Network/Servers/files/home/maling

Auto login

I did have Rebecca’s Mac Mini set up to automatically log on her user account without requiring a password. This won’t work with an NFS home directory, presumably because the LoginWindow races with automount and starts the window manager before the NFS share is mounted. The Mini now boots up to a username and password prompt.

This isn’t a massive issue. After all we now have a machine that is only a few steps away from being usable by multiple users so it makes sense that you’d have to specify which user was at the console. Speaking of which, my next post will discuss LDAP authentication.