如何在 Mac OS X 上使用 /home 目录

Question

I've got a Mac that I can run either the Leopard (10.5) or Snow Leopard (10.6) version of OS X on. I'm using it to do web development/testing before publishing files to my production host.

On the production host my site's doc root is under the home directory (eg /home/stimulatingpixels/public_html) and I'd like to duplicate that location on the Mac. Unfortunately, their is a hidden and lock placeholder on the Mac that looks like a mounted drive with nothing in it sitting in the /home location.

I know from experience that it's unwise to move this and drop in your own /home directory because upgrades can cause it to be erased (and it doesn't get stored in the TimeMachine backup, by the way).

So, the question, is there anyway to safely use /home on a Mac either Leopard or Snow Leopard?

(Note: I realize this is very Mac specific and will be asking it in an Apple forum as well. Just wanted to ask here in addition to cover all the bases.)

Update: To help describe why I want to do this, in addition to the front end web site, I've got a series of scripts that I'd like to run as well. One of the main goals with being able to use the /home directory (and more specifically the same path from the servers root) is so that can use the same output paths on the development mac as well be used on the production server. I know there are ways to work around this, but I'd rather not have to deal with it. The real goal is to have all the files on the development Mac have the same filepath from the / root of the directory tree as the production server.

Another Update: The other reason that I forgot to mention earlier for this is setting up .htaccess paths when using basic authentication. Since those paths are from the file system root instead of the website docroot, they end up going through "/home" when that's part of the tree.

Answer 1

NOTE: As of 2015, I no longer use or recommend this method. Instead I use Vagrant to setup virtual machines for dev and testing. It's free, relatively easy, and allows better matching of the production environment. It completely separates the development environment and you can make as many as you need. Highly recommended . I'm leaving the original answer below for posterity's sake.

---

I found an answer here on the Apple forums .

In order to reclaim the /home directory, edit the /etc/auto_master file and comment out (or remove) the line with /home in it. You'll need to reboot after this for the change to take effect (or, per nilbus' comment, try running sudo automount -vc ). This works with Mac OS X 10.5 (Leopard). Your millage may vary for different versions, but it should be similar.

As noted on that forum post, you should also be aware that Time Machine automatically excludes the /home directory and does not back it up .

---

One note of warning, make sure to back up your /home directory manually before doing a system update. I believe one of the updates I did (from 10.6 to 10.7 for example) wiped out what I has stored in /home without warning. I'm not 100% sure that's what happened, but it's something to be on the lookout for.

Answer 2

Putting it all together from the tips and hints above:

• edit /etc/auto_master # comment out the line with /home in it.

• remount:

  sudo automount -vc

• make a softlink to the mac-ified dir:

  sudo ln -s $HOME /home/$USER

At that point, your paths should match-up to your production paths. env vars will still point to /Users/xxxx , but anything you hard-code in a path in your .bashrc --or say, in ~/.pip/pip.conf -- should be essentially equivalent. Worked for me.

re: "The real goal is to have all the files on the development Mac have the same filepath from the / root of the directory tree as the production server."

On production, my deploy work might happen in /opt/projects/projname , so I'll just make sure my account can write into /opt/projects and go from there. I'd start by doing something like this:

sudo mkdir /opt/projects sudo chown $USER /opt/projects mkdir /opt/projects/projname cd /opt/projects/projname

With LVM, I'll set a separate partition for /opt/ , and write app data there instead of $HOME . Then, I can grow the /opt file system in cases where I need more disk space for a project (LVM is your friend.)

Answer 3

I tried it on Yosemite (OS X 10.10.1) the sudo automount -vc didn't work, I had to use sudo umount /home .

Therefore my workflow would be:

# comment out line starting with /home sudo vi "+g/^\/home/s/\//#\//" "+x" /etc/auto_master sudo umount /home # link actual home directory (/Users/<user>) to new 'home' (/home/<user>) ln -s $HOME /home/$USER

Answer 4

I adapted the previous solutions to Big Sur (macOS 11.2), which is a bit more complicated due to the APFS file system changes. I managed to change /home by following these steps:

1. As recommended by Alan W. Smith, comment out the /home entry in /etc/auto_master .
2. As suggested by Marco Torchiano, run

   sudo umount /home

3. Since /home is currently a read-only link to /System/Volumes/Data/home , you have to change the latter. I did it with the following commands:

    cd /System/Volumes/Data/ sudo rmdir home sudo ln -s <some other directory> home

Answer 5

Why don't you just run MAMP and use the Sites directory? You can develop off localhost and just have a bunch of aliases for your sites. I'm not sure why you specifically need to use the home directory.

---

EDIT: Ok, I think you are going about solving your problem the wrong way.

If it's HTML paths you are worried about, the begin everything with a slash "/" which will default it to the home dierectory.

If it's the references in your PHP, then you need to create a global (or similar) and set it as the root of your site. Then you can reference everything from the global and when you move the site from dev to production all you need to change is the global.

Trying in a round-about way to develop from /home because it looks more like the production server is a bad idea.

Install MAMP, create the global somewhere high in the hierarchy and start re-referencing. It'll be less pain in the long run.