Home > Linux, Mac administration, Mac OS X, Unix > Using /etc/auto_home on Mavericks to mount shares under /home

Using /etc/auto_home on Mavericks to mount shares under /home

One of my users at work asked me recently about symlinking his network home folder to /home on his Mac running 10.9.2 and wanted to check to see if it was safe to do so.

In this case, the person in question works on both Fedora Linux, where his network home directory was mounted as /home/username, and on OS X. His network home directory was available via SMB on his Mac as smb://servername/home$/username. He wanted to be able to mount smb://servername/home$/username to /home/username on his Mac, so that it matched the mountpoint of his network home on his Fedora box.

At the time, here’s what I knew about /home:

1. Nothing appears to be stored in it by default

2. It’s listed in /etc/auto_master as a mountpoint

Screen Shot 2014-04-05 at 10.52.02 PM

3. Time Machine does not back it up

After talking with Apple’s enterprise support folks and doing some additional research, the file that controls what’s mounted in /home is the /etc/auto_home auto mount file.

Screen Shot 2014-04-05 at 9.32.29 PM

To do what my user wanted to do, the following entry could be added to /etc/auto_home to have the designated share mount as /home/username:

username	-fstype=smbfs	://'DOMAIN;username':password@servername/home$/username

Screen Shot 2014-04-05 at 9.32.03 PM

Note: If you have a password longer than 8 characters, or if the password has special characters in it (like “! # $ % & ‘ ( ) * + , – . / : ; & < = > ? @ [ \ ] ^ _ { | } ~”), you may receive a “No locks available” error message and the share will not mount under /home. You will also receive a “No locks available” or similar “Host is down” error if the password is wrong or missing.

That said, having an SMB mount entry in /etc/auto_home may not a good idea for the following reasons:

1. The username and password will need to be stored in /etc/auto_home as part of the mount entry. autofs on OS X doesn’t support using Kerberos authentication, so there’s no good way to secure the connection.

2. The first person to access /home/username will have full access to the share as that user on the server. If this is a multi-user system, subsequent users will have no access to /home/username on that Mac.

If NFS is an available option, this may be better because no usernames or passwords will need to be stored in /etc/auto_home in order to mount an NFS share. If the network home is mountable from the server from a home NFS share, the following entry could be added to /etc/auto_home to have the designated share mount as /home/username:

username	servername:/home/username

If you want to have an NFS mount show up under /home for each user that logs in, you can also use wildcards ( * ) and ampersands (&) in /etc/auto_home. For example, the following entry could be added to /etc/auto_home to have appropriate shares mount as /home/username_goes_here:

*	servername:/home/&

For more information on properly formatting entries for /etc/auto_home, including information on using wildcards ( * ) and ampersands (&), I recommend reading the man page for /etc/automaster. The wildcard information is in the Wildcards section, while information about using ampersands is available in the Substituting the map key entry section.

  1. Mattias
    April 7, 2014 at 9:55 am

    Isn’t this what the fstab file used to do? I’ve tested the fstab file before in our environment and chose not to use it, because we only have MacBooks and if the machine isn’t connected to the network during boot the boot up takes a long time.

    Don’t know if your solution also has this issue.

  2. April 7, 2014 at 5:48 pm


    Apple has autofs looking at various files now, with both fstab and /etc/auto_home being among them. That said, your larger point about not using it on laptops is correct.

    I would recommend using automounts only on machines that are always connected to a network because of the delay issue that you found in your testing.

  3. remd1196
    January 8, 2015 at 8:41 am

    Havent got it to work yet but osx should be able to mount kerberos auth afp shares:
    -> afp “afp://;AUTH=Client%20Krb%20v2@myserver/myVolume” /Volumes/myVolume
    or * -fstype=afp afp://;AUTH=Client%20Krb%20v2@servername.com/&
    to mount a home dir

  4. August 31, 2015 at 11:53 am

    AutomounMaker is an easy to use GUI tool (DONATEWARE OS X native Universal Binary) to create scripts that will mount an AFP, FTP, WebDAV(http), NFS or SMB network share.
    You can use the script as a Startup Item in your user’s session config to automatically mount the given share upon login.
    If you use always the same shared volume on your desktop, AutomountMaker is more easy than the classic Connect to Server… proposed by Apple.
    Go to http://jm.marino.free.fr/index.php?switch=sw_&title=AutomountMaker

  5. mellein
    May 30, 2016 at 7:34 pm

    This was a helpful post. I’m running into one wrinkle though. I’m getting the “No locks available” error when I try to cd in to the mounted directory. I’m certain the user/pass is correct because it works when I use afp instead of smbfs. I can also use the user/pass to ssh into the server.

    server is a mac mini running El Cap
    client is a mac air running El Cap

    File sharing is turned on for the target directory and the user is in the authorized list. SMB and AFP are both turned on for the target directory.

    Totally puzzling.

    • ylluminate
      August 10, 2016 at 7:03 am

      Same here on the “No locks available” result when cd’ing in on 10.11.6.

    • October 20, 2017 at 7:30 am

      @mellein and @ylluminate
      Try this in the server:

      smbpasswd -a your_user

      I think the problem is related with your user uid. macOS users uids begins with 501 and up, but Samba is expecting a uid 1000 and up. But, using a custom samba password via smbpasswd, bypass this.

  6. sxilderik
    August 7, 2020 at 10:31 am

    I think I found a solution to the “no locks available” problem due to a password longer than 8 characters or having non alphanumeric characters: enclose the password in quotes in the auto_xxx file.

    My password has more than 8 chars and holds a $ sign in it, I experienced the “no locks available” problem until I put it inside quotes!

    in auto_smb
    /System/Volumes/Data/xxx -fstype=smbfs,soft,noowners,nosuid,rw ://user:”long password with symbols in it”@serverr:/share

    Hope this helps

  1. No trackbacks yet.

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 )

Connecting to %s

%d bloggers like this: