Guest Posted December 30, 2004 Posted December 30, 2004 After one successful year of use, I have these warnings appear on the top and bottom of my page. Also existing customers can not log in. Warning: session_start(): open(/tmp/sess_195aad39c6bee981075dc761d1ab3ee8, O_RDWR) failed: Permission denied (13) in /www/X/XXXXXX/htdocs/osCommerce/catalog/includes/functions/sessions.php on line 67 Warning: I am not able to write to the sessions directory: /tmp. Sessions will not work until the right user permissions are set. at the bottom of the page here is whats written: Warning: session_write_close(): open(/tmp/sess_195aad39c6bee981075dc761d1ab3ee8, O_RDWR) failed: Permission denied (13) in /www/X/XXXXXX/htdocs/osCommerce/catalog/includes/functions/sessions.php on line 106 Warning: session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in /www/X/XXXXXX/htdocs/osCommerce/catalog/includes/functions/sessions.php on line 106 I have blocked out the name of the website at the moment. Anyone have an idea? I successfully installed a contribution for protecting the admin panel and catalog. Everything was wonderful for two weeks then the scripts appeared. Help...I am slow at this and need help!!! Stuart
Guest Posted December 30, 2004 Posted December 30, 2004 something has changed, either from your host or you made changes in the admin/configuration/logging, sessions or cache. you should set store_sessions to mysql in your configure.php files. you can also create a tmp directory in your document root path with 700 file permissions.
Guest Posted December 30, 2004 Posted December 30, 2004 Sounds like your server configuration has changed. You can use Database for Session Storage instead of using Files.
dad7732 Posted December 30, 2004 Posted December 30, 2004 CHMOD sessions.php 777 Leaving it at 777 can be dangerous but this may tell you that it at least works. If it does then back down to 640. If THAT doesn't work then move up to 755.
♥Vger Posted December 31, 2004 Posted December 31, 2004 Hosting companies all over the world (the good ones at least) are upgrading their versions of PHP as fast as they can - because of the phpInclude.worm This often leads to changes in file pathways. I would check with your hosting company, and also follow the advice to store sessions in your database. Always good practice when on a shared server. Vger
dad7732 Posted December 31, 2004 Posted December 31, 2004 Latest is v4.3.10 and has one minor little annoyance. Register_Globals=OFF OFF by default A lot of sites are using ON and now scratching their collective heads over what's wrong with their PHPNuke sites ... bummer For security purposes it's best to be OFF and edit your pages likewise. Another caveat is that if you're running an old version of MySQL you may have to upgrade. Welcome to computers !!!! :'(
♥Vger Posted December 31, 2004 Posted December 31, 2004 4.3.10 came out on the same day as the first version of php5. Whether or not register_globals is set to 'off' or 'on' is down to what setting the hosting company applies in php.ini Vger
dad7732 Posted December 31, 2004 Posted December 31, 2004 4.3.10 came out on the same day as the first version of php5. Whether or not register_globals is set to 'off' or 'on' is down to what setting the hosting company applies in php.ini Vger <{POST_SNAPBACK}> Depends on your hosting provider. I run several dozen VPS-2 client accounts and I do it for them. However, when Verio broadcasts the update message, you're on your own, they don't do it for you. You even have to do the upgrade and all other tweaks yourself.
♥Vger Posted December 31, 2004 Posted December 31, 2004 Okay. Although this has nothing to do with the thread - what you are saying is you run Virtual Private Servers - in which case you have your own version of php.ini and it's up to you as to what you set register_globals to. So ...YOU are your hosting provider, and this applies to you Whether or not register_globals is set to 'off' or 'on' is down to what setting the hosting company applies in php.ini Vger
Guest Posted December 31, 2004 Posted December 31, 2004 so back to the original question, have you solved it? and where did the 777 permissions on the tmp come into play? 700 should work fine. creating the tmp in the document root (almost anyway) path means this: /home/usernamefromhost/public_html you create the tmp in: /home/usernamefromhost/tmp this way it is outside the public area and you set your paths accordingly in the admin/logging, sessions, cache area.
New 
Recommended Posts
Archived
This topic is now archived and is closed to further replies.