Unable to fopen/fwrite

[KrazyBob]

I am sorry that I seem unable to communicate even the simplest thing: the script ran on the first server for years without a problem. The second server has nothing to do with this. Nothing was moved. It was turned off then back on. The script was not changed. But clearly something is different.

Let's approach this differently: if a script can be run as the user in SSH just fine, what condition would keep the script from running from a browser? File permissions? Folder permissions? User permissions?

This is the test code:

Code: Select all

<?php
unlink('test.txt');
$fp = fopen('test.txt', 'w');
$date = strftime('%c');
fwrite($fp, $date);
fclose($fp);
?>

and this is the error_log and how helpful it is

Code: Select all

[client 70.84.230.166] PHP Warning:  fopen(test.txt): failed to open stream: Permission denied in /var/www/vhosts/scannerbuff.net/httpdocs/ticker/test.php on line 3
[client 70.84.230.166] PHP Warning:  fwrite(): supplied argument is not a valid stream resource in /var/www/vhosts/scannerbuff.net/httpdocs/ticker/test.php on line 5
[client 70.84.230.166] PHP Warning:  fclose(): supplied argument is not a valid stream resource in /var/www/vhosts/scannerbuff.net/httpdocs/ticker/test.php on line 6

If I 777 ticker/ apache creates the file and owns it. This is not the previous behavior. As I said I've downloaded the file and uploaded a copy back over and that means as the userid and not apache. If I chown test.txt back to userid:psacln and then run the script from the browser again it is again owned by apache.

[hostingguy]

Keep in mind that no changes were made to the server. I simply FTP'd the site to another server and changed the NS records. I decided to keep it back on the original server and switched the NS back.

Sorry, i took this to mean that you were using a different server and had those problems on the other server.

Let's approach this differently: if a script can be run as the user in SSH just fine, what condition would keep the script from running from a browser? File permissions? Folder permissions? User permissions?

when you run it from ssh you are running as root right?
Assuming so, root has the right to do anything, even on files owned by others. However when running from a browser it is running as either apache (through mod_php) or as the user ID (php via fcgi/cgi) - and if the user you running under doesnt have the permissions to get to the folder the file is in, or the file itself then you would see that error.

Obviously something has changed as scripts typically dont stop working out of the blue, but based on what you have told us there really isnt much we can help you with since every suggestion people give gets shot down immediately.

At this point all we can offer is a solution, but unfortunately I Think all of those are ones that you are already aware of (change to use cgi for php, or change file permissions or ownership).