PHP 500 Internal Server Errors

500 Internal Server Errors are one of the most common PHP issues that I see customer experience, and it will occur mostly on servers with suPHP or PHP running as CGI.  These errors can be caused by something on the server, or an issue on the user’s site. Here ‘s what you should do if you see errors:

Check the logs

You can solve most problems quickly just by looking at the logs:



Here are some common errors:

SoftException in Application.cpp:357: UID of script "/home/demo/public_html/test.php" is smaller than min_uid

SoftException in Application.cpp:422: Mismatch between target UID (511) and UID (510) of file "/home/demo/public_html/test.php"

SoftException in Application.cpp:264: File "/home/demo/public_html/test.php" is writeable by others

These are all permission/ownership issues, indicating that the owner of the PHP file being called in incorrect, or the permissions are higher than what is allowed in suphp.conf.

Invalid directions in .htaccess

If you’re running PHP in CGI or suPHP mode, you can’t use php_flag or php_value directives in .htaccess – you either need to use htscanner to allow Apache to parse those commands, or make php-related changes in php.ini within the user’s account. You can check the Apache error log in /usr/local/apache/logs/error_log to see if you get something like this:

/home/demo/public_html/.htaccess: Invalid command 'php_flag', perhaps misspelled or defined by a module not included in the server configuration

If the error log indicates a problem with .htaccess, you need to remove the directives indicated and make sure your ssyntax is correct, and that they are in the correct places.

Incorrect ownership or permissions

PHP scripts and their immediate parent folder will usually have permissions limits when PHP runs in CGI/suPHP mode. By default, PHP files and their parent folders can not have group or ‘other’ writable permissions, and cannot be owned by a user on the system other than than the user that owns the home folder it is located in. Additionally, cPanel’s implementation of suPHP does not allow PHP to execute via browser from locations that are not inside a user’s home folder. The first thing you should check is that the PHP script and its parent folder(s) are not writable by ‘group’ or ‘other’, or owned by a different system user. You can usually see if this is an issue by tailing the suphp log in /usr/local/apache/logs/suphp.log, or whatever the suphp.conf has set as the log location.

You can adjust suPHP’s permissions allowances in /opt/suphp/etc/suphp.conf to allow ‘group’ and ‘other’ writable permissions if it’s necessary by modifying these values:


If the problem is with the min_uid value being too low (such as if you’re running a PHP script as root), you can also modify the “min_uid” and “min_gid” values to be more permissive. Changing anything in the suphp.conf requires a restart of Apache.

SuPHP binary missing its “sticky” permissions

Take a look at the suphp binary. It should look a bit like this, and in most shells, will be highlighted in red:

-rwsr-xr-x 1 root root 341K Mar 30 12:25 /opt/suphp/sbin/suphp*

If it’s missing the ‘s’ in the permissions column, you need to re-add the sticky bit to allow users on the system to execute it properly:

chmod +s /opt/suphp/sbin/suphp


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your 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 )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s