If session.save_handler is set to files, on systems that have maximum path length limitations, when the session data file's path is too long, php may get you an error like "No such file or directory" and fails to start session, although the session-saving folder really exists on the disk.

You should:

1. Keep the session-saving folder's absolute path not too long2. If you're with PHP 7.1+, don't set session.sid_length to a number too great, such as 255

I once got stuck with this problem on Windows and wasted hours to solve it.

dont forget: if you use session_save_path on the page, that registers a variable, you have also to use session_save_path on all the pages, where you access the session-variable. under win32 you can use the double \\ to specify eg "c:\\temp\\"

This is an absolute must if you have an important login on a shared server. Without it, other users of the server can do the following to bypass login:

* Visit login page, browse through cookies and grab the session id.* Create a PHP script on their account that grabs and sets session variables for a given session id.* Read and change any values for that session id (for example passwords or session keys), and therefore gain access to the protected area.

All users on web hosting should choose an dir below the HTTP directory struct, but within their user area to store the session files.

After a search for the cause of a issue causing users to have to login twice, I've found a call to session_save_path() was the culprit.

What was happening was: the session save path was set, a session was opened, some variables were set and the session was closed. This was resulting in an empty file in the specified session save path and of course no session data on the next page load. Oddly, on the second attempt the data was saved as expected.

I found that removing the call to session_save_path() resolved the issue. My final solution was to replace the call to session_save_path($path) with an equivalent call to ini_set('session.save_path', $path).