Automount NFS in OS X

I work in a mixed Mac/Windows/Linux environment. The majority of our fileshares are located on Isilon gear and are accessible over SMB with AD authentication, and over NFS with LDAP authentication. Our Macs bind to AD and therefore use SMB to access fileshares. As the size of the scientific datasets people use grow, the (lack of) performance of SMB in Mac OS X becomes more of an issue — especially for people who know they can get far better performance in Windows and Linux. To remedy this, with the help of my colleague and Mac admin, Rich Trouton, we’ve started to migrate certain Mac users away from AD and SMB to LDAP and NFS. Because our Mac users have mobile accounts with local homes, the move requires a bit of finagling, which is why Rich scripted the process.

Once a Mac user’s account has been migrated to LDAP, s/he can use NFS URLs in the Finder’s Connect to Server window and will see vastly superior performance to the previous SMB connections. The more Macs we convert to LDAP/NFS, the more active connections we’ll have to our fileservers. At a certain point, this will become a problem. Fortunately, there’s a way around this that all our linux computers already use: autofs. Autofs will automatically mount fileshares on an as-needed basis and will automatically disconnect fileshares after an idle timeout period (which defaults to one hour). Another benefit of autofs is that users no longer have to mount shares manually. Simply by navigating to where the share is supposed to be will mount it there. Automount is clearly the best solution going forward.

My primary goals for this NFS automounting solution was to make it easy to manage and update — we sometimes add and remove fileshares — and to have the Macs mount fileshares at exactly the same paths as in Linux, inside a root-level directory called ‘groups’. Because of a peculiarity in OS X Lion’s Finder (that I’ll discuss later), this goal precluded the use of the automount maps that our linux hosts get from LDAP. My solution (which works with OS 10.6 through 10.8) adds entries to /etc/auto_master that reference files in a new /etc/automounts directory.

Example Scenario

Let’s say my Isilon cluster is called and it is exporting a number of NFS shares with root paths beginning with /ifs/groups/foo, /ifs/groups/bar, and /ifs/groups/baz. Each of these directories contains at least two subfolders which are the actual shares. I want these shares to mount inside /groups/foo, /groups/bar, and /groups/baz. To do this, I need to create three files inside a new /etc/automounts directory called foo, bar, and baz containing the respective automount maps. Because I’m working outside the user space, I’ll need root/admin privileges.

Here’s what /etc/automounts/foo looks like:

The asterisk at the beginning and the ampersand at the end of the line tell automount to mount any shares it finds inside /ifs/groups/foo with the same name as the share. This saves me from having to specify each share individually. (The mount options are beyond the scope of this post, but go here if you want to learn more about them.) The other two mounts follow this same pattern. You can, of course, specify each share individually. These mount files can have any number of lines in them.

When all the mount files are written, I need to add one line per file to my /etc/auto_master file. It ends up looking like this:

Looks pretty straightforward, right? After these modifications are in place, I check to make sure all files are root:wheel owned, the automounts directory has rwxr-xr-x (755) permissions and /etc/auto_master and all files within /etc/automounts have rw-r–r– (644) permissions. Now I need to restart the automounter so it sees the new mount maps:

When this command runs, it should output all the new mounts it has created. The first three lines are from Apple’s default mounts:

Now, even though it says “mounted”, nothing has actually been mounted. If you look in the Finder, you should see that autmount has created the mount  points, but nothing else. This is an important concept to understand. A share will not actually mount until you traverse its mount point. This is confusing for anyone who has not wrapped their head around autofs — and I’m staring in the general direction of most Mac users, here. For example, let’s say you want to get to /groups/foo/images. If you look inside /groups/foo in the Finder or the Terminal, you will see an empty directory. To go that next step, you’ll need to either use “Go to Folder” and specify “/groups/foo/images” or use the terminal and cd into that directory.

One last thing to mention. You will probably wish to disable the creation of .DS_Store files on network volumes when using automounts. The Finder has a bad habit of leaving these files open, so your automounted shares will not unmount after set idle times like they’re supposed to. To keep your Mac from writing .DS_Store files to network drives, run the following defaults command in the terminal. This is a per-user setting.

Deploying this solution

As I mentioned earlier, because we add and remove new shares semi-regularly, I needed this solution to be manageable. If you’re already using configuration management tools in your Mac environment — be it Casper, Puppet, or anything else — you’re probably already familiar with the best way to deploy and manage a small collection of files. My colleague Rich just wrote up how to wrap all this into a package that you can deploy with your tool of choice. Any time we add or remove a share, we can push out a new package with the changes and the packages postinstall script will reload automount. The reload process won’t affect any active mounts so we can push the package out at any time.

Appendix: Why not use LDAP?

Because the Finder (at least since 10.7) will rename mount points to match the filename that contains the autofs mapping. Our LDAP server’s maps are named with a format of As soon as you go into a share inside /groups/foo, e.g. /groups/foo/images, the Finder renames the foo directory to Directory names viewed from the Terminal are unaffected.


40 thoughts on “Automount NFS in OS X

  1. My users demand that the shares appear as a volume icon on their desktop? Any ideas on this. Can I create aliases on the Desktop? I really appreciated this article.

    • Craig, if you choose /Volumes to be the root of your mount points, then I believe they will appear on the desktop like other network shares. I haven’t tested it but it’s worth a shot.

      • Sadly, by default they do NOT appear, even when mounted below `/Volumes`. The `autofs` system apparently applies the `nobrowse` option by default.

        There IS a property in `autofs.conf`, `AUTOMOUNTD_NOBROWSE`, that *ostensibly* allows changing that, but it has no effect (as of OS X 10.8.3).

        The only way I’ve found this to work – with limitations; see below – is to instead append `browse` to the `AUTOMOUNTD_MNTOPTS=…` line in `/etc/autofs.conf`; e.g.

        This causes automounted mounts to behave as follows – WHILE ACTUALLY MOUNTED:

        * They show up *individually* on the Desktop – assuming the Finder option to show connected servers on the Desktop is turned on.
        * in the Finder sidebar, only the *server* – not the individual mounts – shows up in category Shared as connected – implied by the eject icon next to it – assuming you have the Finder option to show connected servers in the sidebar turned on.
        * Also note that if you eject the server via the Finder sidebar, the icons disappear from the Desktop – yet, the shares will continue to be accessible, by virtue of being automounts that reconnect on demand.

        CAVEAT: I’m unsure as to whether automounts are actually *automatically* established on login, or only *once their mountpoint is accessed*. If the latter, you won’t see the mounts on your Desktop until you’ve accessed the mountpoints – a bit of catch 22.
        In my tests I’ve seen at least *some* NFS mounts connect automatically on startup, whereas at least one AFP mount didn’t.

    • No need to create any aliases. Open Finder preferences and under the General tab where it says “Show these items on the desktop”, check the box that says “Connected servers”.

  2. Perhaps I misunderstand the LDAP renaming issue, but I have not encountered any problems in my setup. I’ve set this up without issues by following “Autofs: Automatically Mounting Network File Shares in Mac OS X” I simply added a few entries in our OD setup under cn=automountMap with no further configuration changes on clients – absolutely no file modifications in /etc/… (and no messing with LDAP settings on clients either, document is a bit confusing about this).

    • Did you get this working on Lion? Our OpenLDAP directory serves linux computers, primarily. I wasn’t able to get ldap automount maps to work and I can’t change the maps without affecting everyone else, hence my decision to go with my non-ldap map solution.

  3. Hmm, why not use /net, that’s already in place and does not need any changes to /etc/auto_master. Then just symlink the /net entries to the group directories:

    ln -s /net/ /groups/foo
    ln -s /net/ /groups/bar
    ln -s /net/ /groups/baz

  4. Excellent writeup. Have you tried 10.8.x and nfs4 – we are having problems with speed of Linux mounts and getting the correct uid:gid on the mac client ?

    • I’m not sure it applies to NFS 4, but I was also having issues with GID/UID. If I mounted an NFS share owned by a Linux user (UID 1000, GID 1000), with my Macbook user (UID 501, GID 20), the permissions on my NFS server export directory would be changed to the user and group on the *server* which had those IDs.

      The solution is to map the IDs on the NFS server. Add a map file, e.g. /etc/nfs/laptop.mac with the mappings:

      # uid client_uid local_uid
      uid 501 1000
      gid 20 1000

      Then edit the /etc/exports so that the mount parameters include anonuid and anongid:


      I’m not entirely sure the map file is actually necessary anymore – check the comments in the link below.



  5. The solution works, but only if I’m on my home network and the NFS shares are found.
    If I’m on another (W)LAN with my MacBook Air, the system freezes or the wheel keeps spinning because the NFS shares are not found.
    I use 10.8.2 Mountain Lion.
    What is the best solution to mount NFS shares if you’re not constantly on the same (W)LAN?

    • Michael, this is the reason we only set this up on (presumably immobile) desktop Macs. It causes fewer headaches for us and our users. There is a way to mitigate the system lags, though. One thing I would do is reduce the autofs default timeout period to something lower than one hour. Open /etc/autofs.conf in an editor and change the AUTOMOUNT_TIMEOUT value to something smaller. If you set it too low, shares will unmount too often when you’re actually using them. Try starting with 900 (15 minutes).

      More importantly, you should edit the nfs mount options in your /etc/automounts files and change ‘bg’ to ‘fg’, and add ‘timeo=10,retry=2’ This should cause them to fail hard more quickly.

      An example mount record taken from my post would then look like this:

      * -fstype=nfs,rw,fg,hard,intr,tcp,timeo=10,retry=0

      • Perhaps I’m missing something, but there are no `fg`, `retry`, `fstype` options (`hard` is accepted, but not documented in the `man` page), at least as of OS X 10.8.3. Foreground is implied if `bg` is not specified, there’s `retrycnt`, and NFS is implied if you use `server:/export` path syntax (alternatively, you can use a `nfs://` URL).

        Here’s an attempt at a (soft) mapping that gives up quickly – both when trying to *establish* the mount and later, when filesystem calls to the already-established mount become unresponsive:

        media -soft,intr,retrycnt=0,retrans=0,deadtimeout=1 nas:/&

        • Oops – turns out value 0 is illegal for the `retrans` option; corrected example:

          media -soft,intr,retrycnt=0,retrans=1,timeo=1,deadtimeout=1 nas:/&

          • Thanks for your input, mklement. I pretty much copied the options we use on linux directly over. Our Macs don’t complain about the options, so I assumed they were all valid. I guess the nfs mounter just ignores the options that don’t make sense to it.

            • My pleasure, thanks for writing the article.

              Yes, unfortunately, the automounter silently ignores invalid options (doesn’t even log warnings); fortunately, `mount_nfs` does complain about invalid options, so it can be used to interactively test-drive a mapping.

              (By contrast, `/usr/libexec/mount_url` also silently ignores invalid options).

    • On my MBP I use the soft option on nfs and smb mount to solve the spinning wheel problem when the resource is not available on the network.

  6. Hey pmbuko, I’m having trouble with MAC OS X 10.8.2 and isilon storage, in that I don’t get realtime playback, what version of OneFS are you on?

  7. Pingback: Automount on MacOSX ~
  8. I’ve worked in a similar environment. You don’t need to fill the auto_master file with all of the mounts, instead you can create executable mount map files and have a yp server.

    Set the auto_master file to point to your executable file, eg.

    /moutnpoint /etc/executable_file

    and hash out the static line (this is for a dedicated legacy map file which ceased to be used from 10.6 I think)

    Populate the executable file based on the executable map section in the following man page

    Set up a yp server to supply the maps and edit the executable files to ypcat the files that are served by the yp server. Edit Directory Utility to make the NIS include your yp servers.

    With this setup, you don’t need to ever edit the clients again, since they are querying the server for the mounts. If you wish to makes changes, then this is done in one location – the server.

    Also, if your map points to the exported mount, then these will show up in Finder avoiding the need to ‘Go to Folder’ or cd using Terminal, but should still only mount when traversed. There have been times when Finder has broken these rules, but I’ve supplied bug reports in the past where they have fixed this. There have been other problems that Finder experienced, but I believe these are now fixed in 10.8. I no longer work in this kind of environment, so there may be newer gotchas.

    Overall a cleaner setup. One place to edit your maps and all the maps show in Finder.

    To take this a step further, take a look at the Variables that are built-in, eg ${CPU}, ${HOST}, which can be added to the mount paths, so you can tailor the path mounted depending on the machine or edit the autofs.conf file to include your own environment variables, maybe for mount points per department.

    • The /- -static line in /etc/auto_master is used for automatic NFS mounts created with Disk Utility from 10.5 to 10.7, or mounts defined in Directory Services. If you’ve defined NFS mounts with Disk Utility, you’ll want to leave that line “unhashed.”

      There’s a brief discussion (with several links to more comprehensive/helpful resources) in this Apple Support Community thread.

  9. Ok.. I’m new to Linux and Unix style of file sharing. I decided to try NFS for shares on my Mac because I wanted to get faster transfer speeds.

    I have a fileserver running OpenSUSE 13.1
    Just as you say, I can see the folder, but its blank. But when I connect to it via SMB, I see all the folders.
    What do I do now?

    • Does the account you’re logged in with on your Mac have read permissions on the directory that’s exported on the fileserver? The server must be aware of your uid. You can see your uid on the Mac by opening the terminal and typing ‘id -u’.

        • Do you know if the NFS server is using NFSv4 or v3? If you’re using v3 (simpler to configure and connect to), then all you need do is ensure that a user with the same uid as your Mac account is either the POSIX owner of the fileshare or is a member of the group. From the OpenSUSE side, you can do ‘ls -l /path/to/share’ to check the permissions of the directory.

          • Ok… How do I know which one the server is using and is there a difference in speed?
            The command you gave me states that the owner is sysadmin, group users.
            My username and password belongs to the same group.

            • An easy way to check if your nfs server is using v4 is to look at the exports file (usually /etc/exports). If the export options include ‘fsid=0’, then it’s likely using v4. Also check to see if the ‘idmapd’ service is running.

  10. Hi, I followed the steps above to map an NFS server on a new Mac with OSX Yosemite.
    The option with the * at the beginning and & at the end did not work, although there are two different folders shared from the same server. And when I leave those two characters out, it does works, although the mounted folder gets the same name of the… mount options:
    I probably made a novice mistake, but since I’m one, do you know how to avoid this?

      • I’m pointing to separate files from /etc/auto_master. In /etc/auto_master I have:
        /mnt /etc/automounts/shared
        And when I put a word in front of the line in shared:
        test -fstype=nfs,rw,bg,hard,intr,tcp ###.###.###.###:/tank/nas/cifs/shared
        then sudo automount -vc, I get two folders under /mnt:

        Adding a second line in in auto_master, pointing to another file, doesn’t add a second mount point either.

Comments are closed.