For those of us who dabble in penguins and apples, it seems very worth while to be able to use /home paths either out of habbit or for those odd cases where the value may have been sync'd somewhere along the line in some file you use on both machines.

  • 7
    ~username expands to your home directory irregardless of Mac OSX or Linux.
    – nohillside
    Mar 17 '12 at 13:23
  • 1
    I'm aware of this, but some cross-platform applications save absolute paths. An example being Sublime Text 2. Apr 29 '12 at 20:50
  • 1
    In fact just ~ expands to your home directory. Can you please clarify in your question whether you want to symlink to your user home directory (ie. /Users/[username]) or in fact the User directory itself (/Users/) which contains separate directories for all the users on the machine?
    – cleverbit
    Mar 22 '13 at 13:31

sudo ln -s /Users /home will work with additional configuration, but I don't think that is a good idea as you should access home via ~ in shell or $HOME. Also /home might be a Linux standard and often used in Unix but not always so better to rely on information that is guaranteed to work not something that works only most of the time if everyone has kept to a convention.

To make sudo ln -s /Users /home work, follow these steps (from the comments):

EDITOR=nano sudo -e /etc/auto_master
# add a "#" at the start of the line beginning with /home
# save changes
sudo automount -cv
sudo ln -s /Users /home
  • 7
    First edit /etc/auto_master and comment out the home line. Then reboot to free the existing /home resource. Then you can symlink the directory using the following. ln -s /Users /home. Until you do this, you simply won't be allowed to create the symlink as the resource is busy. Mar 18 '12 at 21:19
  • 1
    @AR. are there any potential negative consequences of doing so (or why is it there in the first place?). And I am not allowed to edit it even as root or after chmod a+w /etc/auto_master is there another way?
    – Abe
    Mar 21 '13 at 21:31
  • 3
    -1. This results in an operation not supported message
    – Abe
    Mar 28 '13 at 13:50
  • 2
    @Abe It doesn't if you follow @AR.'s direction. Note that you don't have to reboot; you can run sudo automount -cv instead.
    – zigg
    Mar 28 '13 at 15:16
  • @zigg thanks. But that still doesn't make the answer complete. I'll propose an edit - I couldn't downvote anyway!
    – Abe
    Mar 29 '13 at 18:38

I regret this answer is not exactly authoritative, since I've never actually done this myself--though I have used a similar automounter on other Unix systems--but here's my understanding as to what /home is used for on OS X.

So, let's follow the trail:

If you first type mount in Terminal to show active mounts, you'll see this line:

map auto_home on /home (autofs, automounted, nobrowse)

autofs maps are defined in /etc/auto_master, and /home is in turn defined specifically in /etc/auto_home. If you take a look at /etc/auto_home, you'll see this line:


Follow the trail one more step to the od_user_homes man page, and you'll find a program whose purpose is to take a username, look it up in Open Directory, and return a URL to that user's home directory. If you read up on auto_master at its man page, you'll find that using an executable program for a map results in that program being called to look up a URL to mount, which is in turn mounted in-place.

The intended application appears to be that, if your Mac is connected to a directory service, going to /home/jdoe will cause the automounter to mount jdoe's home directory there.

Based on this, it seems logical to conclude that if you don't intend to connect your Mac to a directory service, you're probably okay removing the /home auto-mount as detailed in this comment. I don't know how future OS updates will deal with this, though.

  • 1
    I like using the automounter, rather than disabling it. So I would let the automounter mount /Users/$USER onto /home/$USER. I wonder if it is as simple as replacing that line in /etc/auto_home with something like "+/bin/echo /home/$1", or if you want proper error handling, create a script that replicates what od_user_homes does
    – Tim B
    Mar 28 '13 at 12:59
  • @TimB Interesting thought. Having played with it a little, I'm not entirely sure you can specify a local path that automountd will deal with, though. It seems possible to do NFS, SMB, and AFS.
    – zigg
    Mar 28 '13 at 15:15
  • I don't know if that works on Linux, but it was what I always did on Solaris. The real directory was /export/home/$USER, and there was a standard configuration to automount that onto /home/$USER. In fact, it looks like that is now the standard configuration in Solaris 11.x according to blogs.oracle.com/observatory/entry/automounted_home_directory
    – Tim B
    Mar 28 '13 at 17:14
  • 1
    I just looked quickly. You don't even need to mimic the executable map od_user_homes. That's just there to support OD. Ordinary automounting of /Users/$USER onto /home/$USER is possible. It's shown in the auto_master man page, though the example there shows remote NFS mounts rather than local directories, it should work locally as well.
    – Tim B
    Mar 29 '13 at 20:08
  • I might have been doing something wrong, but I tried configuring a local path where I could use an NFS mount and received an Input/output error when trying to cd. From my reading, it looked like I could only use NFS, SMB, or AFS, like I said. But maybe we should take this line of experimentation elsewhere…
    – zigg
    Mar 29 '13 at 22:47

There's no use for /home. OS X, like various other Unix versions, has a unique location for the user. In Linux it's at /home/user, and in OS X it's at /Users. This is why it is good practice to use the shorthand "~" or the environment variable $HOME.

While you can create a symlink to the user's base/home directory /Users/[username] using the following command:

ln -s ~ /foo

It will not work to create a link named /home as there is already a(n unused) directory with that name at the root of the system.

  • 1
    Exactly. I've been on other Unix-like systems that used other conventions for home directories for various reasons, e.g. /export/home/username on Solaris. It's bad practice to assume /home/username will work. Programs looking for home directories should be using getpwnam or getpwuid.
    – zigg
    Mar 22 '13 at 14:20
  • 1
    I fully agree that it's bad practice for programs to assume it's existence, but that doesn't address that sometimes software isn't developed in a competent way. Mar 22 '13 at 17:56
  • Amongst the mounts in my case and others: map auto_home on /home (autofs, automounted, nobrowse) … whilst I don't know the origin of that mount, I should disagree with "no use for /home". Mar 26 '13 at 2:29
  • Sorry should have been clearer: just meant /home is apparently reserved, but unused in OSX, not that there is no point using it ;)
    – cleverbit
    Mar 27 '13 at 11:12
  • @richarddas I get the same operation not supported error from sudo ln -s /Users/username /home/username as I do from sudo ln -s /Users /home. The solution provided by @AR works (comment out the /home line in /etc/auto_master and reboot).
    – Abe
    Mar 28 '13 at 14:05

I tried this before and got it working for about a week until I rebooted...

You can't just symlink /home to /Users. In fact, you can't even remove /home.

If you manage to remove /home, it will reappear after you reboot.

If you move /home to /home.old, and symlink /home, it will remove the symlink /home.

You can have this working for as long as your mac does not crash or reboot.

When you reboot, it all vanishes!

When you reboot, Mac OS X seems to think that you are creating a new user, so it will overwrite all of your user preferences in your old /Users/username directory.

Since you copied everything to /home/username, you expect to see your new home directory when doing ls /home after you reboot. Instead, you get NOTHING!!! It is as if it never existed.

In my case, I was freaking out for about 30 minutes, then I booted into single user mode to see if something could be done. I was thinking that I might be able to grab a log file or try to start a repair utility.

In single user mode, my home directory was there. Apple intentionally hides any newly created directories under /home from the user when in multiuser mode. This is an intentionally evil design feature.

Apple is lame and discourages any and all kinds of hacking their OS. What kind of a design feature is that? Apple hides the contents of the newly created /home directory. There is absolutely no legitimate reason for Apple to auto-remove the /home directory...or any user-created directories at all!

In this case, they are mounting a directory over your /home directory...effectively hiding it.

If you are really determined to use /home instead of /Users, you might be able to get around it by writing a script to set everything up upon every boot.

Also, I should mention that you should be able to use some other directory that is not /home as a replacement for /Users because only /home is banned.

If you use bash, then you will have to set some of the environment variables... namely: CD_HOME and HOME.

I wish to add that...although you cannot unmount or force unmount /home, you can mount a disk on top of /home. All of this mounted on top of "auto_home".

I was able to mount the recovery disk on top of /home successfully...perhaps this is how it can be done.

  • TL/DR; re-boot-proof customization is possible using the top-rated answer
    – MarkHu
    Sep 2 '15 at 20:46

I don't see any reason at all not to rename the directory /home (in case I'm wrong) and creating a symbolic link from /home to /Users (or, as in my machine, /Volumes/Users since my system disk is for system, dammit!)

I used to work as a sysadmin, in a university department with 11 flavours of unix. We had all sorts of symlinks in the global directory tree so that the file system would do the right thing, and scripts came as close as possible to working everywhere. You do run into a few gotchas, but if your fingers are used to typing /home/foo and a symlink postpones job retraining for your fingers, go ahead.

Similarly some linuxen will have home directories as /usr/home already.

One place I worked had home directories of /Users/{group}/{username} as a partial protection against students groveling around professors' files if the prof was careless with his permissions. The Users directory had execute but no read bits set, and the group directories were readable only to the group members.

(All this in illustration there being many ways to deprive this particular feline of his pelt.)

One possible gotcha -- check that time machine doesn't end up making two copies of everything. I don't know how TM treats symlinks. If it does, then add /home to the exclude list of TM.

  • 1
    If something or someone sets an inappropriate mode or ACL for your alternative to /Users then the familiar routines for repairing permissions will probably fail to make the required corrections. So I recommend that /Users should be as installed by Apple: a directory, not a symbolic link. Mar 26 '13 at 2:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .