This problem has occurred to me also. The behaviour was different on Windows vs Linux.
On both platforms the problem occurred when I had two sessions open from the same server in the same browser.
Apart from multiple sessions I had the same problem when I migrated the instance, after an upgrade or after a fresh install.
On Linux I always managed to resolve it by resetting permissions, clearing the browser cache and repairing and rebuilding all I could (including the .htaccess file).
In case of a migration I also previously edited the values pointing to host, url, db, etc in config.php.
On windows I have not been able to understand how to solve it consistently. In the case of a fresh install I noticed that unzipping the suitecrm install .zip directly in the webserver folder worked well. On the other hand if I copied the folder after having unzipped it elsewhere, nearly always gave me permissions problems and if I tried to reassign them it never worked.
I took the time to check the config.php file. PGR wrote (and other agreed) that I need to check the .htaccess file for this:
echo ini_get(âsession.save_pathâ);
There is nothing like that in my .htaccess file.
I need to add this?
As well, the idea of running out of disk space? Not an issue.
I didnât write anything about .htaccess files. Thatâs the last thing to check for permissions problems, not the first.
That echo command is for you to find out which path is your effective session path. Then you go and use chmod/chown to fix permissions on it, so that the web server can write to it.
Leave the Firefox issue for another thread, please.
The $sugar_config fix would apply only if your problem was occasional (when your ISP changes your IP address), but not if itâs a problem that happens every time you access the log in screen.
Start by making sure you can write to the session save path.
No, you didnât read that post carefully enough. Itâs not for .htaccess, and itâs not for php.ini.
What is said was âcheck your php.ini for a session.save_path setting, if you donât find one, make a new php file with that echo command and call it from the browserâ.
This way every user in group client2 should be able to write there, and create new writeable files under that folder. And âworldâ users get no access at all.