FCGI PHP upload_tmp_dir is not working correctly

I'm setting the temp upload directory for each site as /$home/tmp.

When actual upload happens it still goes to /tmp. When I run phpinfo() it tells me that upload_tmp_dir directory is /$home/tmp - just like expected.

When file is being uploaded it goes to /tmp. though and as apache:apche and I thought that may be this is the reason. How do I fix it right?

Closed (fixed)


Hmm, what you're describing makes it sound as if it's being processed as mod_php, rather than FCGID.

You may want to verify that the PHP Execution Mode is set as expected.

You can verify that in Server Configuration -> Website Options -- in there, what is "PHP Execution Mode" set to?

Also, if you run the command "rpm -qa | grep php", what output do you receive?

Ilia's picture
Submitted by Ilia on Fri, 03/29/2013 - 11:28

It set to FCGId of course and settings are correct at Website Options!

Output is:


Ah, it looks like your PHP version came from a third party repository (the REMI repository).

Software from third parties can cause configuration problems, such as what you're seeing.

It looks like you may still be having the issue that we tried to fix here:


Can you verify that in the file /etc/httpd/conf.d/php.conf, that there are no lines beginning with the word "SetHandler"?

Any line starting with SetHandler should be commented out. Otherwise, all incoming traffic would be processed as mod_php, and not FCGID.

Once you make that change, restart Apache to activate those changes.

Ilia's picture
Submitted by Ilia on Fri, 03/29/2013 - 11:45

I remember our conversation!! :) There is nothing there in /etc/httpd/conf.d/php.conf as SetHandler

The funny thing is that PHP and Smarty temporary files have domain owner group/name but when it uploads the file it goes to /tmp with apache:apache?

What else am I missing?

That's definitely an odd one! What you're describing shouldn't actually be possible... it shouldn't be possible for a website to execute anything as apache:apache if it's set to use FCGID. There are security checks in place that actually prevent that from happening, as that's considered a security risk.

Is it possible that uploads are being performed via a different domain, that is set to use mod_php?

The only other thing I can think of is that if certain security measures are removed, it may be possible to force mod_php via a .htaccess file.

Are there any .htaccess files in any of the directories for this website that could be causing that?

Ilia's picture
Submitted by Ilia on Fri, 03/29/2013 - 12:36

There is NOT a single line in my domain folder containing mod_php and not in php.ini

If I try to install fcgi via yum here is what I get:

Package mod_fcgid-2.3.7-1.el6.x86_64 already installed and latest version

I outline that the file goes to my $HOME/tmp directory AFTER it was uploaded with domainOwner:domainOwner permissions - this part is fine! BUT while it's uploading it goes to /tmp and permissioned as apache:apache AND then MOVED to $HOME/tmp with proper permissions. But with mod_php it was going directly to $HOME/tmp and then renamed after upload is finished!

Imaging what happens if 20 people finish uploading at the same time of a file that is around 1GB? They will be moved from /tmp to my $HOME/tmp, thus I thought that moving is much more resourceful and renaming is not resourceful at all?! Besides /tmp is mounted as ext3 and home as ext4 and what is even worse that /tmp partition is even 16 GB of space which is total disaster for what I have imagined above?

What should I do? Am I right with my presumptions?

Out of curiosity, are you seeing that same behavior if you change the PHP Execution Mode to CGI? Or does it only occur when using FCGID?

Ilia's picture
Submitted by Ilia on Fri, 03/29/2013 - 12:52

I haven't try CGI. But mod_php puts it directly to what upload_tmp_dir is and then just renames the file?

Is this me or it's CGId?

What would be the solution for me?

It would be really helpful if you could try it with CGI :-)

That will assist us in understanding the behavior you're seeing.

Ilia's picture
Submitted by Ilia on Fri, 03/29/2013 - 13:33

OK, I tried it for you! If you run it as CGI then it acts normally, just like mod_php that I described above - it puts it directly to $HOME/tmp and then renames it!

I tried again with FCGI - same issue! It goes first to /tmp and then move to what upload_tmp_dir is. By the way it oes to /tmp as fcgid.tmp.liOotY?

Thanks, that helps!

What that tells me is that there's something in the way that FCGID works, where it uses /tmp as temporary place to store files, before handing over control to PHP.

That would explain why the files are owned by apache:apache while in /tmp.

What that means is that we're looking for a change in FCGID, and not in PHP.

FCGID doesn't actually offer the ability to set a temp directory though. At least, not as part of the fcgid configuration.

I've asked Jamie if he's run into that issue before, and if he has a suggestion for a workaround.

Ilia's picture
Submitted by Ilia on Fri, 03/29/2013 - 13:48

Will look forward to it! Thanks!

Okay, here's what I've figured out so far.

It looks like when FCGID receives an upload request that's too large to fit in memory, it stores it in a hard coded temp directory, /tmp. Once the upload is complete, it passes control over to PHP, which in turn copies it to $HOME/tmp, and changes the permissions on the file.

Your concern was that you didn't want it storing the uploaded files in /tmp, due to the limited space you had there.

Jamie and I talked this over -- and we're unfortunately not aware of a good way to resolve the problem you're having while using FCGID.

FCGID doesn't provide a documented way to change the temp directory it uses.

The easiest thing you could do to resolve that would be to use CGI mode, instead of FCGID.

Another solution would be to increase the size of your /tmp directory.

Or, if you have a serious amount of RAM in your server, you may be able to configure FCGID to keep the uploads in memory, rather than storing them in /tmp. However, with the concern you shared above, where 20 people could all be uploading a file at the same time -- you'd need well over 20GB of RAM to handle that scenario. So that's probably not a good idea :-)

Using CGI mode, instead of FCGID, would be the simplest way to fix the problem you're seeing.

Ilia's picture
Submitted by Ilia on Sat, 03/30/2013 - 02:27

I have 64 GB or RAM! What is the speed dfference we're talking about?


64GB is quite a bit of RAM!

You can read about the FCGID option that will keep requests in memory here:


If you wanted to set that, you could edit /etc/httpd/conf.d/fcgid.conf, and set fcgidmaxrequestinmem to the largest size you'd want it to store in memory.

After you make that change, you'd need to restart Apache for it to take effect.

Regarding your speed question -- copying a 1GB file from one partition to another would take some time, and storing those requests in memory would save that step.

So you should see a speed improvement.

Alternatively, if you didn't put /tmp on it's own partition -- you'd probably see a similar speed improvement if both /home and /tmp were on the same partition.

Ilia's picture
Submitted by Ilia on Sat, 03/30/2013 - 10:09

So far it takes about 4-5 seconds to copy 1GB! But if it was in memory that would be much faster and just what I wanted though! I'll try it!!

You must mount and format /tmp as different partition and filesystem to prevent possible security issues!

Thanks a lot!


Ilia's picture
Submitted by Ilia on Sun, 03/31/2013 - 04:22

Please read here, if you don't understand what they say please use Google Chrome and their translation bar:


It appears that FCGI has TMPDIR directive but it doesn't work for me for some reason, could you please investigate and tell me what is the best thing to do?

Thanks, Ilia

Ilia's picture
Submitted by Ilia on Sun, 03/31/2013 - 05:51


I have one more question:

If I run as Apache php_mod only sites that I have will this still be a security issue?

Let's say I'm the server administrator and let's say I have onesite.com than I will run as php_mod. And if I have other users running FCGI is this ok? Tell me more what you think and how you see it and what you would have done if you were me!?

Yeah, we're familiar with that TMPDIR environment variable... the problem is that setting it in the FCGID wrapper script, as mentioned in your link, would set that after FCGID has already begun processing the upload. So that wouldn't actually solve the problem you're trying to solve.

We were unable to find an example of anyone using that environment variable successfully to solve your particular issue.

Regarding mod_php -- that does indeed raise a potential security issue. If all the users on your system are trusted, it's not really a problem... but on a system where some users may not be trusted, we would recommend against mod_php. Any user using mod_php can effectively see most other files in /home.

You asked what we would do in your situation --

I would see if using CGI provided a similar website experience. Do the page load times seem similarly fast between CGI and FCGID? If so, I'd just switch to CGI.

If they didn't, if FCGID seemed much faster, I'd remove the /tmp partition, and combine /tmp and / into one partition.

We don't feel a separate /tmp partition provides any significant security benefit. It's actually capable of causing quite a few administrator headaches though (especially since a lot of folks putting that on a separate partition also set the noexec mount flag).

Ilia's picture
Submitted by Ilia on Sun, 03/31/2013 - 10:24

Regarding mod_php -- that does indeed raise a potential security issue. If all the users on your system are trusted, it's not really a problem... but on a system where some users may not be trusted, we would recommend against mod_php. Any user using mod_php can effectively see most other files in /home.

Andrey if I got you correctly:

  1. Let's say I have 5 sites and I will run them as mod_php - these are my and I'm a trusted user, correct? I can not pose security thread?

  2. If I start having other people/users on my server I will set up their accounts as FCGI and my server will be as secure as I would also used FCGI?

P.S. Concerning number 1: but if somebody get's control of enviroment under those site that are running with mod_php by using some flaws in php scripts of those (my sites) than the security issue arises, correct? But if PHP is properly coded with safty in mind then it's alright?? :)

Yes, if you trust the users using mod_php, and you feel the sites are sufficiently secure, then running your own sites under mod_php, and untrusted users under FCGID, would work. That is more secure than having all users use mod_php.

Personally, I would still use one of the two other options I mentioned (CGI, or combining /tmp with /), but if you don't like those options then you could certainly use mod_php.

Ilia's picture
Submitted by Ilia on Sun, 03/31/2013 - 10:59

Andrey, I tested CGI and it runs visually well and fast! Why do you stand so much for CGI rather then mod_php?

You should use whatever tool solves the problem best for your usage. If you prefer mod_php, than you can certainly use it.

Regarding why I prefer CGI -- despite the best efforts of software developers, software can still have security issues.

I believe in security in layers -- I'd rather have several secure components on my system (such as both a secure web app, and a secure PHP Execution Mode), rather than relying on one to be secure, when I know what's underneath it is not.

But if your preference is mod_php, please feel free to use it :-)

Ilia's picture
Submitted by Ilia on Sun, 03/31/2013 - 13:43

Alright! I agree with you about security!

Could you please tell me one more thing:

What is the real difference in nature between CGI and FCGI as they both seem to refer to /usr/bin/php-cgi? Do the use the same PHP module? Does FCGI also uses Apache mod_fcgid.so but CGI not?

The biggest difference between the two is that FCGID does some request caching, where CGI does not.

However, if you find the performance of FCGID and CGI to be similar, then that caching isn't making a big difference for your particular sites.

Ilia's picture
Submitted by Ilia on Mon, 04/01/2013 - 10:53

I think the subject received exhaustive explanation!

Thank you very much, Ilia