Virtual hosts, PHP and MySQL on Mac OS X 10.5 Leopard

A couple of weeks ago when I posted Mac OS X 10.5 Leopard improves accessibility I mentioned that I hadn’t yet been able to get hold of a copy of Leopard to try the new features out for myself.

Well, later that week I decided to give it a try, so I went out and bought myself a copy along with a new hard drive so I could clone my current disk before installing Leopard. And that proved to be a very good thing.

Relying on my previous experiences of upgrading to a new major release of Mac OS X I decided to play it safe and use the Archive and Install option. I wanted a “clean” OS without having to create a new user and reinstall everything.

Archive and Install has worked fine for me before, but not this time. I’m not blaming Apple or anyone else for the trouble I had, but I think others may find themselves having similar problems, so describing my problems and what I did to work around them will hopefully be of help to someone.

First try: Archive and Install

As I write this I am running Leopard again, and this time everything seems to work properly. I say again, because after running into too many problems after my initial install I thanked myself for taking the time to make a bootable clone of my hard drive before installing.

Getting a working setup back was just a matter of visiting the Startup Disk panel in System Preferences and switching to the clone. A reboot and I was back to where I was before I started, except for one thing that I’ll get to shortly.

The web development-related problems I had were these:

  • The hostnames for my development sites were gone
  • My Apache Virtual Hosts were gone
  • PHP didn’t work
  • MySQL didn’t work

The above were serious enough that after spending many hours trying and failing to get my local web development stuff up and running again, I told myself to get over it and switch back to Tiger. So I did.

When I told my colleagues at work about this I was met with surprised looks and “Well I didn’t have any problems. Everything works fine for me. I just inserted the Leopard disk and upgraded.” It turned out that the difference was that they had all picked the default Upgrade option instead of choosing Archive and install. That’s what I got for trying to be smart.

Not really wanting to leave that brand new copy of Leopard on my shelf to collect dust I decided to try it again, but just upgrading this time.

Preparing for the second try: cloning a disk used by Time Machine

To prepare for the upgrade I wanted to clone my Tiger disk again, and that gave me my next headache: Time Machine. Immediately after installing Leopard the first time I was foolish enough to switch on Time Machine and let it make a full backup of my Leopard disk. Making backups is good after all. But not if you later decide to make a clone of the disk that is used by Time Machine, even after you have rebooted into Tiger.

I deleted a visible folder called “Backups.backupdb” that Time Machine had created, and I thought that was where all the Time Machine data was stored. Apparently not. I tried cloning the disk with Carbon Copy Cloner and SuperDuper!, and both got stuck when they tried to copy a hidden folder called “.HFS+ Private Directory Data”.

Reluctant to delete this folder without being sure that it was harmless I tried cloning everything else, but that also failed. What I did in the end was delete (in the Terminal) these files and folders:

  • Backups.backupdb
  • .HFS+ Private Directory Data
  • .fseventsd

I’m not sure that deleting the .fseventsd folder is necessary, but as far as I can tell it is a Leopard thing, and I wanted to get rid of all traces of Leopard from this disk, so delete it I did.

After that scary episode of deleting files I wasn’t sure that I should be deleting I verified that everything seemed to still be working OK and breathed a sigh of relief. I was then able to clone the disk with Carbon Copy Cloner without any further problems (other than it taking an hour and a half).

I suppose wanting to clone a disk with Time Machine data on it is a somewhat unusual situation, so perhaps there won’t be many others who run into the same problem. Just in case someone does, knowing that deleting these files and folders fixed the issue for me without causing any apparent problems might be helpful.

Disclaimer: In no way do I guarantee that doing this is safe. If you delete the files and folders mentioned here and end up losing valuable data, do not blame me. If there is data that you cannot afford to lose on the disk, make sure you have a reliable backup.

Second try: Upgrade and web server configuration

A quick couple of reboots to verify that the clone really worked and I was finally ready to install Leopard again, this time without doing an Archive and Install.

The upgrade went smoothly, and after about half an hour I had rebooted into Leopard with no noticeable problems. So far so good. Time to get my development sites up and running again. To do that I had to do a number of things.

  • Create a hosts file. I previously used Netinfo Manager to handle hostnames for my development sites. There is no Netinfo Manager in Leopard, so I had to reenter all hostnames into the hosts file. It’s easy though – all I had to do was open /private/etc/hosts and add the hostnames I need, using the same format as the hosts already in the file.
  • Enable PHP. By default PHP is disabled in Leopard, so I had to uncomment the line # LoadModule php5_module libexec/apache2/ in /private/etc/apache2/httpd.conf.
  • Tell Apache where my sites are located. Since I like to keep my sites in a different location than the default /Library/WebServer/Documents, I had to add a new <Directory> block to /private/etc/apache2/httpd.conf (I could also have edited the default).
  • Copy my virtual hosts. Virtual hosts used to be configured in /etc/httpd/httpd.conf, but Leopard comes with Apache 2, where virtual hosts are setup in /private/etc/apache2/extra/httpd-vhosts.conf. To enable virtual hosts I uncommented the line # Include /private/etc/apache2/extra/httpd-vhosts.conf in /private/etc/apache2/httpd.conf.

    I then copied my <VirtualHost> blocks to /private/etc/apache2/extra/httpd-vhosts.conf, but the virtual hosts didn’t work until I enclosed the DocumentRoot paths in quotes (""). As far as I can tell from the Apache 2 documentation, that shouldn’t be necessary, so I’m not sure why I had to do it. Either way, adding the quotes made it work. The NameVirtualHost directive in my httpd.conf file had an argument of * instead of the *:80 that was in the httpd-vhosts.conf file, so I had to change that as well.

  • Tell PHP where the socket for MySQL is. I had to open /private/etc/php.ini and change mysql.default_socket = to mysql.default_socket = /private/tmp/mysql.sock.
  • Increase PHP’s memory allocation. When I tried to access one of my sites I got a PHP Fatal error: Allowed memory size of 8388608 bytes exhausted, which means PHP has run out of memory. The default is 8 MB, which I increased to 16 MB by changing line 232 in /private/etc/php.ini to memory_limit = 16M.
  • Restart Apache. While going through this I restarted Apache several times, but once is enough if you do it after making all of the above changes: sudo apachectl graceful.

Not too bad once you know what to do. It can take forever to find all the info though, so when it’s time to upgrade my office machine I’ll only need to revisit this article to find everything in one place.

After all of that, I finally have a Leopard install that I can use for Web development.


I got the info I needed to get my install of Mac OS X 10.5 Leopard working properly from various sources, including the following:

Posted on November 12, 2007 in Mac, PHP


  1. Is your production site running on Mac OS X?

    Chances are its not, and very likely running a Linux distro. It might be easier to use virtual machines to setup a local development environment. A minimal ubuntu vmware (fusion) instance, takes up a less than a gig of space (with apache2/php5/mysql5), works quite great given as little as 256MB of memory, can run headless and can be started and killed on demand. Its a whole lot easier to manage such an environment.

    Note: Parallels also works, but I’ve found VMWare to be a lot more stable for Linux guests.

  2. Thanks for sharing! Man, am I glad to see that things worked for me, when reading this… :-)

  3. I run Panther, but I don’t use the Apache install that comes with OS X - rather, I use the MAMP. MAMP is a self contained distribution with MySQL, PHP, phpMyAdmin, SQLite and Apache. It’s very easy to set it up and it can do multiple virtual hosts!

    I found it quick to set up.

  4. I’ve been having problems trying to get Apache on Leopard to use a different location for the DocumentRoot, I keep my site files in a ‘Client_Data’ directory that is in my Documents folder in my user account. What I found was that if I changed the DocumentRoot to point to this I got a ‘Forbidden - You don’t have permission to access / on this server’ message.

    I tried to get it working and just gave up for a while and ran the standalone MAMP in the mean time to get working because this had no problem pointing to my custom DocumentRoot location. I eventually figured out that in Leopard Apache’s default user (www) doesn’t have permissions to access my Documents folder. I simply went and changed the User and Group settings in the httpd.conf file to use my user and group and then it worked fine.

    I’m sure you could probably add the default Apache user to a group or some other Users / Groups / Permissions setting but for a development machine this solution works fine!

    Did anyone else run into this issue as well?

    Also, if anyone, like me, did a completely fresh install of Leopard and had problems getting MySQL to work after trying the Tiger downloads from the MySQL website then you might want to check out Dan Benjamin’s blog post “Installing MySQL on Mac OS X”.

  5. I found Patrick Gibson’s virtualhost script pretty handy as a quick way of adding (and removing) test sites.

  6. Remember to test the apache configs before restarting. apachectl -t will test all the config files for you and spit out any errors.

    Rick, check out the rather simple fix.

  7. November 12, 2007 by katylava

    I had a lot of similar issues, but eventually got it all figured out. I can only access MySQL through the terminal now, but that’s no big deal.

    The only thing I haven’t cracked is my clean URLs. All my vhosts rewrite rules work, but they do a real redirect now instead of a transparent rewrite. I’m not using the [R] flag, so I don’t know what’s going on. Have you encountered anything like that?

  8. awesome info!

    My remaining problem is that my (http://localhost/~usernamehere/) is not accessible. I get 403s and I don’t know what needs to be done to fix this… I am assuming permissions are the culprit, but I don’t know how to ‘re-enable’ my personal sites.

    Has anyone run into this?

  9. I wrote up a similar post on Leopard, PHP, MySQL and Apache 2 the weekend Leopard came out. You might find that a useful supplement to this one. I solved some of the same issues from a different angle.

  10. November 12, 2007 by Roger Johansson (Author comment)


    It might be easier to use virtual machines to setup a local development environment.

    Thanks for the tip. I know one of my colleagues uses Parallels to run Linux distros for local development. It’s not an option for me on my home machine though, since it’s not an Intel mac.

    Harold: Thanks, both are good tips.

    katylava: Hmm. All my redirects seem to be working ok, so no, I didn’t encounter that. Not sure what would cause it, sorry.

    Mao: Does the fix Harold linked to in comment 6 help?

    Jeff: Yes, that is a very useful article :-).

  11. “That’s what I got for trying to be smart.”

    The story of my life.

  12. Neato, thanks for all the nuggets. I suspect I’ll be referring back to this article more than once.

    Apologies if you already know this, but the “Archive and Install” option is just like a clean install, except it archives your old installation in a folder instead of wiping it entirely.

    If you want settings from your old installation, you need to manually copy the files across from the archive after installation—or, indeed, figure out how to replicate the settings on all the new software that came with the new OS :)

  13. What version of MySQL did you install?

    I couldn’t find a Leopard version so I’ll try ‘mysql-5.1.22-rc-osx10.4-i686.tar.gz’ for my Intel iMac.

  14. For those who have a new machine and need MySQL 5.0.x (no Leopard binary as of yet on, check out Dan Benjamin’s build instructions. Worked for me.

    There are MySQL Gui Tools from for Leopard yet either. :( I just use my Tiger machine to access MySQL on the Leopard machine. Good enough for now!

  15. Thanks for the info, it saved me a lot of fiddling about. One minor issue, after upgrading to Leopard there was no /private/etc/php.ini. I had to copy the php.ini.default and modify that.

    MySQL worked fine once the socket parameter was added to php.ini.

    @Jeff: I’m using mysql-5.0.45-osx10.4-i686 and the GUI CocoaMySql v0.7 on an intel MacBook. Both seem to work fine on Leopard - so far :)

  16. We hit this in the office this morning. I can’t remember as I did my own upgrade when terribly ill last Friday, but I’m fairly sure I didn’t “Archive and Install”. :s

    Mamp solved a couple of problems for us, too (after I copied over all the <virtualhost> blocks):

    The two big ones were easy PHP4 support (we’re phasing it out, but it aint gone yet) - I didn’t want to hunt to see if Leopard still has the php4 binaries (and still don’t know if it does); and user-editable httpd.conf files - our designers aren’t quite as happy as me to go sudoing and chmodding.

    Thanks for your article, Roger, it gave me a good few quick pointers on a busy Monday morning!

  17. November 22, 2007 by Peter B.

    I second Ben’s suggestions of using MAMP, but take it a step further: MAMP Pro. I use it to set up scores of open source CMS. This way I don’t waste bandwidth and disk space on the remote server.

  18. I was bashing my head against the desk wondering why my virtual sites were giving a ‘Forbidden - You don’t have permission to access / on this server’ message after upgrading to Leopard, despite the file/directory permissions on the web directories being unchanged.

    This happens if your virtual sites aren’t under /Library/WebServer/Documents and there is a solution that doesn’t need the apache user and group to be changed (which could lead to other hassles).

    After actually realising Leopard had changed from using Apache1.3 to Apache2 I (eventually) looked at what differences there were in the httpd.conf files relating to directory access.

    (In what follows I’ll use square brackets to delimit apache directives in case angle brackets aren’t escaped when displaying as HTML).

    In Apache1.3 Apple’s httpd.conf has this:

    [Directory /]
      Options FollowSymLinks
      AllowOverride None
    [Directory "/Library/WebServer/Documents"]
      Order allow,deny
      Allow from all

    The [Directory /] block has an implicit Order Deny, Allow directive (i.e. the default) so that anything below the root of any site is, by default, accessible. (The [Directory “/Library/WebServer/Documents”] block’s directives are explicitly saying that anything within /Library/WebServer/Documents is accessible. This doesn’t change what is already allowed).

    However, in Apache2 Apple’s httpd.conf has this:

    [Directory /]
      Options FollowSymLinks
      AllowOverride None
      Order deny,allow
      Deny from all
    [Directory "/Library/WebServer/Documents"]
      Order allow,deny
      Allow from all

    The [Directory /] block now explicitly makes everything inaccessible below the root of any site by default. Now the [Directory “/Library/WebServer/Documents”] block’s directives are overriding this to grant access to everything under /Library/WebServer/Documents.

    That’s fine if your virtual sites are under /Library/WebServer/Documents but if they’re not you get ‘Forbidden - You don’t have permission to access / on this server’.

    The solution is simply to add an Allow from all directive for each virtual site’s DocumentRoot, e.g.

    [VirtualHost *:80]
      DocumentRoot /some/other/path


    [VirtualHost *:80]
      DocumentRoot /some/other/path
    [Directory /some/other/path]
      Allow from all

    The Allow from all directive overrides the [Directory /] block’s Deny from all directive because it is processed afterwards and the last one processed wins.

  19. March 8, 2008 by Mac Admin

    Neal wrote:

    “The solution is simply to add an Allow from all directive for each virtual site’s DocumentRoot, e.g….”

    Wow…this SO NOT THE WAY. Neal’s method totally undoes the security provided above. It’s not that Neal’s statement that the last command wins is wrong…that’s a correct statement.

    The problem is that you don’t want to simply un-do the deny/allow rules.

    Neal’s method is like taking all the locks off the doors because your son keeps forgetting his house key.

    Not a good thing.

  20. March 24, 2008 by Jeff Murphy

    I have to chime in on MAMP, it works great for me. A snap to set up.

  21. Bummer, reading the RSS Feed I was hoping this was an article on how to install a clean install of PHP, MySQL and setting up the Virtual Hosts

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.