Here’s an interesting problem I came across just now. I was setting up a new domain with CakePHP and noticed that the stock copy did not run, neither did identical files I copied from another working domain. Before this, each time I uploaded CakePHP to my server, everything ran out of the box, so why not now? It’s been a while since I’ve added a new domain to the system, so right away I thought it must be PHP or DirectAdmin causing the problem (they were the latest updates done to the server). The error message I was getting from CakePHP was the following:

Warning: session_start() [function.session-start]: open_basedir restriction in effect. File(/var/tmp/) is not within the allowed path(s): (/home/user/:/tmp:/usr/local/lib/php/) in /home/user/domains/domain.com/public_html/cake/libs/session.php on line 154

Fatal error: session_start() [<a href=’function.session-start’>function.session-start</a>]: Failed to initialize storage module: files (path: ) in /home/user/domains/domain.com/public_html/cake/libs/session.php on line 154

Doing a quick check on Google brought some insight to the matter, but nothing concrete. I decided to check phpinfo() and see what the open_basedir restriction was set to. Since I had a copy of phpinfo() on another domain of mine, the result of open_basedir came up to “no value”. I mumbled “WTF” to myself and was totally puzzled. Now, quick note on my mistake here: always run phpinfo() on the same user and domain that you are trying to troubleshoot. Fortunately, I didn’t give up just yet: I ran phpinfo() on the troubleshooting domain and right away notice that open_basedir had values, none of which would work with CakePHP. Finally, something! So where were these values coming from?

The next step was to check Apache’s httpd.conf. Since DirectAdmin organizes the httpd.conf files of every user account seperate (it Includes user-httpd.conf at the end of the main httpd.conf file) I went to the troubling user’s configuration and scrolled all the way to the bottom to the latest added domain. Bingo! It had the following line added:

php_admin_value open_basedir /home/user/:/tmp:/usr/local/lib/php/

And it was the only domain that had that line too. A quick sigh of relief after, I silently commented that line out and crossed my fingers, restarted Apache, refreshed the homepage and… yep, everything worked as usual. It seems that the latest version of DirectAdmin (1.31.0 at the time of this writing) has some extra security features enabled (which is a good thing) but a bit unnecessary for people who run their sites on their own servers. So, this is a heads up for everyone out there that might come across this error one day and not know what to do. I hope it works for you.

Update: DirectAdmin actually has a built-in control panel feature that allows you to turn on/off open_basedir restrictions and PHP safemodes per domain name. Just go to the control panel main page and click on PHP Safemode Configuration (available as of 1.31.4, maybe earlier).