permission denied when doing fopen on a 777 permission file in php

Im not new to php or file permissions. But i just migrated an extremely simple script to a new server I setup.

The folder which the script runs is in the document root. The permissions for the folder are set to 755.

The owner of the folder is gsta. The owner of the file is gsta.

I turned on error_reporting and am getting:

Warning: fopen(log.txt): failed to open stream: Permission denied in /var/www/html/log.php on line 13

I've tried:

chmod("log.txt", 0777)

in php and also get permission denied.

Ive done:

ps -u | grep httpd

and got:

gsta      1012  0.0  0.0 108608   808 pts/3    S+   22:45   0:00 grep --color=auto httpd

Code:

$filename = 'log.txt';
$handle = fopen($filename,"a+");
echo "fh:" . fwrite($handle, $payload . "\n") . $handle . "<br/>";
fclose($handle);

even though it shouldnt matter PHP safemode is off

I tried setting the owner of the file to nobody (apache often runs under nobody, i also tried setting the owner to apache.

I have looked at every posting in google and its always the basic things, all of which I have tried. This was a known working script on a different server. I tried checking php.ini looking for some setting that would cause this issue. I have tried deleting the file (as it should create it in that case)

Does anyone have any ideas? Ive tried everything I can think of.

I don't know what it could be, but have your tried creating the file from within your script. just rename the file, make sure fopen is set to read write mode (a should be fine) and have php create it for you.

If that doesn't work then your folder permissions are wrong, try setting the folder to 777

also on my box for some reason I have to use two zeros for chmod, 00777

Is there any possibility that some security stuff, like SELinux, stopped these actions?

I've run into a similar problem and the command setenforce 0, which would shut down SELinux, successfully resolved it.

"log.txt" are you sure the file you're setting to 777 is the same one? Without a path to it, if the page thinks its running from say the root directory of your site, not the one you're in, you could get errors that way, the Some calls tend to also need the directory to have write permission - I dont think I ever got to the bottom of why some do, some dont.