I've tried and tried and now I'm just stuck.
I have a completely clean install. It won't upload attachments or pictures. Yes, the directories exist and are world writeable, when you run the check in the admin menu through config.inc.php it says it is correct. When you try to upload though, nothing gets uploaded. Looking at the php error log it says:
----------
[27-Jun-2002 00:06:41] PHP Warning: open_basedir restriction in effect. File is in wrong directory in /big/dom/xfishingfordeals/www/forums2/changebasic.php on line 121
[27-Jun-2002 00:06:41] PHP Warning: getimagesize: Unable to open '/tmp/phpS5ynMf' for reading. in /big/dom/xfishingfordeals/www/forums2/changebasic.php on line 121
[27-Jun-2002 00:06:41] PHP Warning: open_basedir restriction in effect. File is in wrong directory in /big/dom/xfishingfordeals/www/forums2/changebasic.php on line 139
----------
So I figured it was something FutureQuest (host) would have to change. I wrote them and got this explanation:
[]"That script is generating a lot of errors in your logs_cgi/phperror log, which is highly suspect in itself...
It is true that we run with 'open_basedir' for security reasons, however it appears that the failing program makes provisions for handling the 'open_basedir' environment...
If you look at the output of 'phpinfo()', you will find the 'open_basedir' is set to:
/big/dom/xfishingfordeals:/var/shadowdom/xfishingfordeals/logs_web:/usr/local/lib/php:/PHP4:/big/tmp:/big/dom/tmp
The 'read_dump.php' script is failing on line 252 because it is trying to access a file in '/tmp'... Unfortunately this is not allowed because all sites on the server operate as the same user level of 'apache'... If you wrote temporary files to '/tmp', then others could look at your files for which might contain sensitive data like credit card numbers for orders...
If you look at line 239 of that file, you will see it mentions reading the documentation on how to use the './tmp' directory instead to work around this problem...
The true 'tmp' directory for everyone to use with file uploads is not '/tmp' but rather '/big/dom/tmp', and this is how PHP is configured noted by the above string...
At this junction, you will need to keep working with the script as I am 100% confident that PHP file uploads is working properly for a large number of domains across different servers...
Hope this helps to clarify and expand upon the issue you are seeing...
Well, unfortunately it doesn't clarify anything.
So I opened a support ticket at Infopop. Infopop's response was "When I test an attachment it goes up - but I get a 404 when I try to access it." It doesn't "go up" -- that's the problem! It never sucks the file from your computer to the server. That's why you get a 404 error, because the file ISN'T THERE!
If I want them to check it further it will cost $75.
Between this problem and the email problem (new members don't get an email with their password), I haven't been able to switch our board over. I'm getting pressure to switch to VBulletin, and that just stinks, because I really like ubb.threads.
Does anyone have any suggestions on how to fix this so that the uploads actually upload, short of paying $75 for help with a product that should work already? (PLEASE don't misunderstand me -- I'm not one of those people who complains that this is too buggy, etc., because I don't think that. I'm just frustrated that Infopop wants us to pay extra to get something to work that should already work!) I know it works for most people, because I tested it on my own personal website (different host) and the uploads worked fine. But according to FutureQuest the difference is that they have the cgi-bin above the html tree, so PHP can't access it. Is that extremely unusual? Shouldn't there just be directions on how to get around this if your host is set up this way?
Thank you for any help or suggestions anyone can offer.
