By default, suPhp is compiled in "paranoid" mode. This means that the settings in the user httpd.conf files:

suPHP_UserGroup username username

will require all php files to be owned by username or suPhp will throw a "500 Internal Server Error".
This does not apply to domains, when used normally, because each domain has it’s own VirtualHost with the suPHP_UserGroup inside it using the correct settings.
The ~username (UserDir) method will fail in paranoid mode, because there is not a virtualhost for each ~username path, and no suPHP_UserGroup settings for each user, hence you get the 500 error.
The solution to this is to compile suPhp in "owner" mode instead of "paranoid" mode.
To do that, run these commands.

cd /usr/local/directadmin/custombuild
mkdir -p custom/suphp
cp -fp configure/suphp/configure.suphp custom/suphp/configure.suphp
perl -pi -e ‘s/paranoid/owner/’ custom/suphp/configure.suphp
./build clean
./build suphp
cd /usr/local/directadmin/data/templates/custom
cp -f ../virtual_host* .
perl -pi -e ‘s/suPHP_UserGroup/#suPHP_UserGroup/’ virtual_host*.conf
perl -pi -e ‘s/suPHP_UserGroup/#suPHP_UserGroup/’ /etc/httpd/conf/httpd.conf
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue

Which will change all references of suPHP_UserGroup to #suPHP_UserGroup, basically, just commenting them out.

Incoming search terms:

Related posts:

1. Apache won’t start after update on FreeBSD An issue with php/apache is causing apache not to start...
2. How to downgrade from apache 2 back to apache 1.3 If you need to go back to apache 1.3 after...
3. Apache stops responding but is running A few things that could cause that are: Possible Causes:...

Related posts brought to you by Yet Another Related Posts Plugin.