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 shares.example.com 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:

*        -fstype=nfs,rw,bg,hard,intr,tcp share.example.com:/ifs/groups/foo/&

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:

#
# Automounter master map
#
+master # Use directory service
/net -hosts -nobrowse,hidefromfinder,nosuid
/home home -nobrowse,hidefromfinder
/Network/Servers -fstab
/- -static
## everything above this line is in the default auto_master file ##
/groups/foo /etc/automounts/foo
/groups/bar /etc/automounts/bar
/groups/baz /etc/automounts/baz

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:

sudo automount -vc

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

automount: /net updated
automount: /home updated
automount: /Network/Servers updated
automount: /groups/foo mounted
automount: /groups/bar mounted
automount: /groups/baz mounted
automount: no unmounts

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.

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

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 auto.groups.foo. As soon as you go into a share inside /groups/foo, e.g. /groups/foo/images, the Finder renames the foo directory to auto.groups.foo. Directory names viewed from the Terminal are unaffected.

About these ads

About pmbuko
mac/linux geek

28 Responses to Automount NFS in OS X

  1. Craig Doran says:

    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.

    • pmbuko says:

      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.

      • mklement says:

        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.
        AUTOMOUNTD_MNTOPTS=nosuid,nodev,browse

        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.

    • jamauai says:

      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. Pingback: Deploying NFS automounts for Macs via installer package « Der Flounder

  3. doubter says:

    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” http://images.apple.com/business/docs/Autofs.pdf. 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).

    • pmbuko says:

      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.

  4. Arjen van Bochoven says:

    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/share.example.com:/ifs/groups/foo/ /groups/foo
    ln -s /net/share.example.com:/ifs/groups/bar/ /groups/bar
    ln -s /net/share.example.com:/ifs/groups/baz/ /groups/baz

  5. Barry McInnes says:

    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 ?

    • pmbuko says:

      I’ve tried 10.8, but we don’t currently use nfs4.

    • Thom says:

      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:

      (rw,no_root_squash,no_subtree_check,anonuid=1000,anongid=1000)

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

      Credit: http://www.gordonizer.com/2009/04/nfs-mount-ubuntu-linux-drive-on-mac-os.html

      HTH

  6. Michael says:

    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?
    Cheers
    Michael

    • pmbuko says:

      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 share.example.com:/ifs/groups/foo/&

      • mklement says:

        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:/&

        • mklement says:

          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:/&

          • pmbuko says:

            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.

            • mklement says:

              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).

    • RAQ says:

      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.

  7. Pingback: NFS on OSX Mountain Lion « Burgundywall.com

  8. Ads1980 says:

    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?

  9. Pingback: Automount on MacOSX

  10. S says:

    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

    http://scottlab.ucsc.edu/~wgscott/xtal/wiki/index.php/Man_auto_master

    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.

    • pmbuko says:

      Thanks for the great info. It’ll probably be a better fit for many people’s environments.

    • acfkevin says:

      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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 481 other followers

%d bloggers like this: