500 Internal Server Error with PHP file

[LSteamGeo]

Hello,

My PHP files all display a 500 Internal server error when i'm attempting to access PHP files through the temp-URL http://serverName/~username/index.php

I try http://serverName/~username/test.html with a basic HTML and it works correctly.

How can I fix this?

Thank you

 

[ChrisRHS]

Is this your dedicated or VPS server, or, are you on a shared hosting?

 

[LSteamGeo]

Hi ChrisRHS,

It's my dedicated server.

 

[ChrisRHS]

How is your PHP configured? suPHP, FastCGI, CGI or DSO? You should also be able to take a look at the error logs for Apache:

tail -n 200 /usr/local/apache/logs/error_log

That will list the last 200 lines. You need to be looking for the 500 error. I suspect its due to permissions, so you may also want to check out the suexec log:

tail -n 200 /usr/local/apache/logs/suexec_log

Chris

 

[mohit]

tail the logs, then try to restart apache and look for errors.

check if your log files have outgrown the allowed size.

 

[LSteamGeo]

The logs :

apache Log Error_Log

[Sun Mar 07 16:19:33 2010] [error] [client xx.xx.xxx.xxx] SoftException in Application.cpp:422: Mismatch between target UID (506) and UID (500) of file "/home/myAccount/public_html/index.php"
[Sun Mar 07 16:19:33 2010] [error] [client xx.xx.xxx.xxx] Premature end of script headers: index.php
[Sun Mar 07 16:19:33 2010] [error] [client xx.xx.xxx.xxx] File does not exist: /home/myAccount/public_html/500.shtml


What does it mean?

Thanks

 

[asent]

It looks like a suPHP error. Ownership of the index.php does not match the domain owner. Does it work when accessing the domain directly?

As root, do a 'chown -R siteuser:siteuser /home/siteuser/public_html'

See who users 500 and 506 are if you don't know. Check the /etc/passwd

cat /etc/passwd |grep 500

 

[thewebhosting]

After changing the ownership of all your files and folders inside the public_html you will again have to change the ownership only for the public_html folder to username:nobody.

Also make sure that you have also assigned the appropriate permissions to your folders and files.

 

[madaboutlinux]

If you have a large number of accounts, you can use the following script to correct the ownership of the files/directories of all the accounts

for i in `cat /etc/trueuserdomains | awk '{print $2}'`
do
chown $i.$i /home/$i/public_html -R;
chown $i.nobody /home/$i/public_html;
done;

 

[LSteamGeo]

Hello,

Thank you for all. It works now.

Sorry for my bad English...

Thanks !!!

 

[cwalke32477]

If you have a large number of accounts, you can use the following script to correct the ownership of the files/directories of all the accounts

How does one use this script?
Directly inthe command line did nothing.
sorry, I am total server n00b

 

[garrettp]

It's a Bash one-liner. I believe it's not working because the OP forgot the semi-colon after the for statement and before the do loop:

for i in `cat /etc/trueuserdomains | awk '{print $2}'`; do chown $i.$i /home/$i/public_html -R; chown $i.nobody /home/$i/public_html; done

 

[Spiral]

How does one use this script?
Directly inthe command line did nothing.
sorry, I am total server n00b

Don't run any of the script commands listed in this thread as all the commands as posted in this thread are very poorly written and makes me cringe a bit just looking at those. Nice effort but no cigar.

Anyway though, if you are having the same issue as this thread namely trying to use "/~username/" to access sites and getting error 500 problems, it is more likely that your server is configured as non-DSO and in that case, I would avoid using mod_userdir (~username access) entirely for a great many technical reasons.

 

[garrettp]

Don't run any of the script commands listed in this thread as all the commands as posted in this thread are very poorly written and makes me cringe a bit just looking at those. Nice effort but no cigar.

Anyway though, if you are having the same issue as this thread namely trying to use "/~username/" to access sites and getting error 500 problems, it is more likely that your server is configured as non-DSO and in that case, I would avoid using mod_userdir (~username access) entirely for a great many technical reasons.

Glad to see you provided a better one!

@OP:

Personally I like to treat them on case-by-case basis. You can always run a for loop, but generally I'm only dealing with 1 issue site a a time. 500 errors do not always mean a permission issue of course, and if it is, you will usually see errors in the log to indicate incorrect permissions on files/directories. My preferred method to fix this is to use find:

find /home/user/public_html/ -user nobody

To automatically correct ownership:

find /home/user/public_html/ -user nobody -exec chown user:user {} \;

You'll also want to make sure directories are 755 when using SuPHP. Similar code to fix this:

find /home/user/public_html/ -type d -perm 777 -exec chmod 0755 {} \;

 

[mambovince]

Glad to see you provided a better one!

@OP:

Personally I like to treat them on case-by-case basis. You can always run a for loop, but generally I'm only dealing with 1 issue site a a time. 500 errors do not always mean a permission issue of course, and if it is, you will usually see errors in the log to indicate incorrect permissions on files/directories. My preferred method to fix this is to use find:

find /home/user/public_html/ -user nobody

To automatically correct ownership:

find /home/user/public_html/ -user nobody -exec chown user:user {} \;

You'll also want to make sure directories are 755 when using SuPHP. Similar code to fix this:

find /home/user/public_html/ -type d -perm 777 -exec chmod 0755 {} \;

Can we replace /user/ with /*/ to do all at once?
thanks,

- Vincent

 

[Spiral]

Can we replace /user/ with /*/ to do all at once?
thanks,

- Vincent

Yes, you indeed can!

For security reasons I'm not going to try to waste time explaining the intimate details at the moment as already covered elsewhere, it is better to pipe the find output through 'xargs' than use the internal exec functions but that is a side footnote --- whatever you feel more comfortable with.

The following is the most ideal permissions for a NON-DSO environment:

• 755 -- **ALL** Folders (Including those that script authors tell you to set 777)
• 644 -- Non Script Files (Images, Basic HTML, Templates, Etc)
• 600 -- PHP Scripts (*.php, *.php4, *.php5)
• 755 -- CGI and Shell Scripts (*.cgi, *.pl, *.pm, *.py, *.e, *.sh)
• 400 -- RARE When PHP scripts **DON'T** want to be writable
• 755 -- RARE PHP Scripts used under CLI as a shell script

 

[Spiral]

Mambovince:

Addendum follow up to my previous post above and your question, in case you didn't quite follow, this would be a very basic example of what you might use to set the permissions on you folders and php script files:

# cd /home
# find /home/*/public_html -type f -name '*.php' | xargs chmod 0644 -- 
# find /home/*/public_html -type d | xargs chmod 0755 --

You can adapt those examples as you need. :D

 

[mambovince]

Mambovince:

# cd /home
# find /home/*/public_html -type f -name '*.php' | xargs chmod 0644 -- 
# find /home/*/public_html -type d | xargs chmod 0755 --

Thanks spiral.
Would all directories need 755?
The following I found in another post here suggests to only change those with 777

find /home*/*/public_html -type d -perm 0777 -exec chmod 755 {} \;

By the way, now I have a few websites that when accessed they bring up a file download option instead of the website.

Any help appreciated.

- Vincent

 

[Spiral]

Would all directories need 755?

When running SuPHP or FCGI ......

You are actually going to want all folders set to 755 though looking for 777 might save you a few milliseconds over processing time over updating all of the folders but for that one isn't going to be much gain.

(**Sole exception to 755 is 'public_html' itself which is normally 750)

By the way, now I have a few websites that when accessed they bring up a file download option instead of the website.

What you just said tells me that your PHP is broken and is not working!

And what I mean by that is that your web server isn't parsing PHP scripts so the scripts themselves are just read as plain text download files by the web browsers that don't know what to do with them either.

A broken PHP installation like the one you just described can have many causes but the most common ones are selecting the wrong combination of options when compiling PHP given some options don't play happy with others. Another common issue is when the PHP binaries or symlinks get mixed up or places in the wrong directories. You also get it by failing to load the appropriate Apache configuration for your PHP type as well such as failing to load the correct module or forgetting to set the handler.

In any of the above cases, PHP itself will be broken and that will cause your PHP scripts to be treated as regular download files.

You can start with the following:

# /usr/local/cpanel/bin/rebuild_phpconf --current

(Shows you what your server thinks it's supposedly running now)

Note also the permissions that I gave you in the previous post are for non-DSO systems which specifically would be phpsuexec (cgi w/ suexec), suphp, or fcgi. It does NOT include dso (Apache module).

 

[mambovince]

Hi Spiral,
really appreciate your response.
Regarding the possibility that my VPS PHP is broken, not sure.
You see, nearly 50 sites are working fine and they are a mix of Wordpress, Joomla, and custum PHP scripts.

Just a handful of sites are trying to download file when accessed.
I have never run a server with SuPHP but need to learn due to improved security.

Any particular settings or tests I can do?

thanks,

- Vincent