Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a shared hosting server, with CentOS linux and cPanel running Apache with mod_php. We use linux's user quotas to enforce that each website stays within their purchased amount of disk space. However, many websites have file upload systems either public or in their admins (CMS software, for example). Because this software runs under mod_php the files that are uploaded end up belonging to the user Apache runs under, and do not count against the user's disk quota.

The only way I can think to solve this is to write a script which looks through every directory in /home and chowns all the files in public_html so they are owned by the correct user, and then have this script run hourly through cron. Before I write such a script, are there any better solutions? (Or does such a script exist?)

EDIT: I must be able to run mod_php. CGI php is not an option.

share|improve this question
up vote 1 down vote accepted

Try using mod_suphp (or mod_suexec where appropriate). Will cause apache to run under the appropriate user, so their file ownerships will be correct.

share|improve this answer
Doesn't mod_suphp require that PHP be in CGI mode? That's not an option... – Josh Aug 31 '09 at 23:29
Why isn't it an option? The transition from mod_php to mod_suphp should be seamless (although you may run into permissions problems on some of your users files). – rodjek Sep 1 '09 at 0:47
The CGI version of PHP isn't an option because it's slower and doesn't have all the functionality of PHP, i.e. it can't send HTTP authentication headers. – Josh Sep 1 '09 at 2:37
mod_suphp doesn't have any issues sending HTTP authentication headers, nor is it noticeably slower than mod_php. Give it a try in your test environment. – rodjek Sep 1 '09 at 4:08
@rodjek, I will set up a test server. I guess I was misunderstanding the documentation regarding HTTP authentication: – Josh Sep 1 '09 at 13:03

Basically, if you can't run PHP in a CGI mode, you're screwed. You can't do a chown on the files because then the webserver can't modify them later (which is important for some applications), unless you want to get really freaky with your permissions and umasks and have to deal with permissions SNAFUs every time something hasn't been pre-configured with the right umask.

Your objections to running PHP in CGI mode are unfounded, though; I work for a company with a number of shared hosting servers and we run PHP through suexec and we don't have customers complaining about a lack of features. Yes, it's slightly slower, but the startup overhead is lost in the noise of most PHP web applications' inefficiencies.

share|improve this answer
I can't chown the files so that the user is the website user and the group is the group apache runs under, and then chmod g+rw? If I did that then the files would count against the user's quota while the webserver will still be able to modify them, right? (And FYI, I have gained customers who switched from hosting companies because they did not support mod_php) – Josh Sep 1 '09 at 13:00
And then find every single place that might create or edit those files and set the umask correctly... it's too much fun for me. – womble Sep 2 '09 at 0:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.