|
When i try to access a certain php file directly by typing its path into the address bar like so http://www.mysite.com/path/to/my/file.php, I get
No other errors, just that... if I upload a simple php file that just echos 'test', I can access it, the two files are in the same folder. VPS CentOS 5.5 apache mod_security enabled, ASL installed. The permissions are the same for both files. What can be the difference? |
||||
|
|
|
The only way I can get Firefox to say "File not found: Firefox can't find file at" is to use a file: URL like: "file:///tmp/does-not-exist". So the error you mention seems to indicate that you are using a file: URL to try to access a file on a remote computer. Perhaps the file that works is a file that you ALSO have on your workstation as well as the server, and the file that doesn't exist does not exist on the server? You can verify that it is actually requesting the file from the server by looking at the server logs (as I'll mention below). When Firefox reports "File not found", what is the URL in the URL bar at the top? Is it "file:" or "http:"? If you go into a shell window or file browser, does a file with either of the names you are trying to access (the .php file that works or the file that doesn't) exist on your workstation? The URL you are using should look like: http://serverhostname.example.com/filename Here are some other general Apache troubleshooting ideas using the logs on the server, which may provide more information and verify if you are actually hitting the server or not. The first thing to do is look in the Apache error logs, typically in "/var/log/httpd/error_log". Try accessing the file that gives the error, then look in the error_log and "/var/log/httpd/access_log and see what they contain related to that request. Note that if you have made configuration changes to Apache and are serving files out of a different directory, your error/access logs may be in a different location. Normally, if it is a permissions problem on the server, Firefox would respond "You don't have permission to access on this server". The error_log would say "(13)Permission denied". In this case you may just need to "chmod 644 " so that it is readable by the web server. If that doesn't work, sometimes it's SELinux blocking the access. You can test that by running "setenforce 0" and trying to access the file again. If it now succeeds, the problem is related to SELinux. Use "setenforce 1" when you are done to re-enable SELinux. If it can't match the URL to a file on the file-system, firefox would normally respond with "Not Found: The requested URL was not found on this server", and the error_log would say "File does not exist". This would normally be caused by a naming or typo issue, verify what the logs say against the file name in the file-system. |
|||
|
|
|
Unless Firefox itself is running directly on the VPS itself, and not on your PC, any direct file access URL like file://some/path/filename.php is going to be looking in the wrong computer. If this doesn't explain your problem please provide further information about the computers and URLs etc. The message "File not found Firefox can't find the file at" suggests that Firefox has been asked to look into the local filesystem of the computer running firefox (and not elsewhere via, say HTTP). For a file that can't be found, most servers return a 404 and a server-specific message that does not mention "Firefox". The message you quoted can be caused by, for example, a Javascript error in a page, even one retrieved using HTTP. But there are many possible causes. If the server returned a 404 for http://www.mysite.com/path/to/my/file.php, I'd look for some useful information in the server's error log. |
|||||||||||
|
|
We have alot of trouble here with Firefox's caching behavior when doing web development or sys admin tasks. Perhaps Firefox has cached a negative result from visiting the URL before it was fully setup? You could try a different browser or just wget to retrieve the file to eliminate the effect of the Firefox cache. |
|||
|
|
|
Thanks to the input from the answers to my question, I was able to track the problem to it's cause. The case was solved as follows: The page that could not be opened (returning only a 500 or no error at all) was a script using 'proc_open' and 'proc_close' which had been disabled by ASL. As to why there were no log entries whatsoever to be found related to the problem in any logs I don't have an answer yet. After taking the two functions out of the disable_functions directive of the php.ini, everything was fine. |
|||
|
|
