<p>For me the solution required was</p>

<p><code>'requireMatchingUserAgentForSession' =&gt; false</code> in my <code>config/general.php</code></p>

<p>I was debugging the site in Chrome and it was changing my user agent, which was instantly logging me out.</p>

CC BY-SA 3.0
2017-07-04T05:31:08.833Z
2017-07-04T05:31:08.833Z
James Nisbet
<p>These are the steps that solved the problem for me (PHP 5.4 , Nginx):</p>

<ul>
<li>Delete the contents of <code>craft/storage/runtime</code></li>
<li>Set the <a href="http://buildwithcraft.com/docs/installing#step-2-set-the-permissions" rel="nofollow">correct file permissions</a></li>
<li>Added <code>'overridePhpSessionLocation' =&gt; true,</code> to the site configuration</li>
</ul>

CC BY-SA 3.0
2015-01-06T18:50:53.573Z
2015-01-06T18:50:53.573Z
Lars Bilke
<p>For us, we had the same problem but a different root cause.</p>

<p>We noticed that we were getting multiple new session files created for each request, all with the same data in them. After a bit of digging, I noticed session.auto_start was On in php.ini, so tried turning it Off.</p>

<p>And that fixed it, no more surplus session files been created on disk, and no random logging out. </p>

<p>So make sure that php.ini has </p>

<pre><code>session.auto_start = 0
</code></pre>

CC BY-SA 3.0
2015-01-30T14:29:55.433Z
2015-01-30T14:29:55.433Z
OddEssay
<p>Check if you can write in /vagrant/dlfm/craft/craft/storage/runtime/sessions/.
There is where the sessions are being stored. 
To test, try chmod 777 -R /vagrant/dlfm/craft/craft/storage/runtime/sessions and try again.
Those permissions are too wide, but if this works after you might know the cause.</p>

CC BY-SA 3.0
2014-07-11T20:41:54.590Z
I double-checked /storage and /storage/* and they're at 777, and the problem is continues to happen..
Jason D
CC BY-SA 3.0
2014-07-13T10:13:52.270Z
I dont think this is related to Craft but to your Vagrant configuration, where you mount the shared folder into the VM. Can you post your Vagrantfile here? I created this VM provisiones with Ansible and is the one we are using to develop Craft, feel free to test it: https://github.com/miguelbalparda/vm
mbalparda
CC BY-SA 3.0
2014-07-11T20:21:59.020Z
2014-07-11T20:21:59.020Z
mbalparda
<p>Here's more on PHP sessions &amp; Craft if it helps: </p>

<p><a href="https://nystudio107.com/blog/the-case-of-the-missing-php-session" rel="nofollow noreferrer">The Case of the Missing PHP Session</a></p>

CC BY-SA 3.0
2017-07-04T06:38:54.727Z
2017-07-04T06:38:54.727Z
andrew.welch
<p>I've had the same problem for the past few weeks with my windows vagrant setup, it's been driving me crazy. Works fine on our staging server.</p>

<p>I think I finally got it working :)</p>

<p>I did 2 things not sure yet which fixed it:</p>

<ol>
<li><p>added this to my vagrant file
config.vm.synced_folder "./craft/storage/runtime", "/var/www/craft/storage/runtime", 
disabled: true</p></li>
<li><p>destroyed my vagrant instance (vagrant destroy) and recreated it (vagrant up)</p></li>
</ol>

CC BY-SA 3.0
2014-10-24T00:47:29.350Z
Nah still having problems, but I have narrowed it down...
When I first setup my vagrant instance it all works fine,then after a few hours craft admin starts complaining that cUrl is not installed (I guess it's trying to check for updates), so I install cUrl and that's when I start having problems, the sessions files don't write and the only fix I can find is to destroy my instance and start again
Andrew Wisener
CC BY-SA 3.0
2014-10-08T08:18:37.270Z
2014-10-08T08:18:37.270Z
Andrew Wisener
<p>OK I have a definite answer to this issue this time...</p>

<p>The problem is caused because craft fails to write out the session files in /craft/storage/runtime/sessions, if you look in there you will see zero byte files :(</p>

<p>The issue seems to be because of vagrant/virtual box syncing files between the host and my pc. So the trick is to get vagrant not to sync the sessions folder. For me this was not that easy, it seems that if you sync the /craft folder it syncs all subfolders even if you tell it not to (by creating another sync and disabling it). So I had to explicitly state which craft folders to sync - ugh! It works which is great, but I am predicting trouble down the track if craft adds another folder to it's top level structure.</p>

<p>Anyway here is what I put in my vagrant file to get it work</p>

<pre><code>config.vm.synced_folder "./public", "/var/www/public", :mount_options =&gt; ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/app", "/var/www/craft/app", :mount_options =&gt; ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/plugins", "/var/www/craft/plugins", :mount_options =&gt; ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/config", "/var/www/craft/config", :mount_options =&gt; ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/templates", "/var/www/craft/templates", :mount_options =&gt; ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/backups", "/var/www/craft/storage/backups", :mount_options =&gt; ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/userphotos", "/var/www/craft/storage/userphotos", :mount_options =&gt; ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/runtime/assets", "/var/www/craft/storage/runtime/assets", :mount_options =&gt; ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/runtime/cache", "/var/www/craft/storage/runtime/cache", :mount_options =&gt; ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/runtime/compiled_templates", "/var/www/craft/storage/runtime/compiled_templates", :mount_options =&gt; ['dmode=777', 
</code></pre>

<p>'fmode=777']
    config.vm.synced_folder "./craft/storage/runtime/logs", "/var/www/craft/storage/runtime/logs", :mount_options => ['dmode=777', 'fmode=777']
    config.vm.synced_folder "./craft/storage/runtime/state", "/var/www/craft/storage/runtime/state", :mount_options => ['dmode=777', 'fmode=777']
    config.vm.synced_folder "./craft/storage/runtime/temp", "/var/www/craft/storage/runtime/temp", :mount_options => ['dmode=777', 'fmode=777']</p>

CC BY-SA 3.0
2014-11-11T04:42:24.043Z
2014-11-11T04:42:24.043Z
Andrew Wisener
<p>My solution was to run:</p>

<p><code>sudo chown -R ec2-user /var/lib/php/session/</code></p>

<p>Obviously your mileage would vary depending on your setup</p>

CC BY-SA 4.0
2019-10-31T17:59:02.617Z
2019-10-31T17:59:02.617Z
Matt Fletcher
<p>My solution is to add:</p>

<pre><code>'overridePhpSessionLocation' =&gt; false
</code></pre>

<p>Into <em>craft/config/general.php</em></p>

<p>This tells Craft to use the default location to write sessions, instead of craft/storage/runtime/sessions</p>

<p>For whatever reason, even though  craft/storage/runtime/sessions has CHMOD 777, PHP was saving the session file with 644. When it tried to write to the same file again, it got and error and logged me out.</p>

<p>I also (unsuccessfully) tried giving PHP ownership of the folder, which should in theory fix the problem too.</p>

<pre><code> sudo chown -R www-data:www-data sessions
 chown: www-data: illegal group name
</code></pre>

<p>I am assuming it's a Vagrant/OSX thing. </p>

CC BY-SA 3.0
2014-07-13T00:52:29.973Z
Ahh... nice catch.  I had forgotten about that config setting.  It was originally added because some edge case hosts were doing crazy things like storing PHP session in memcache.
Brad Bell
CC BY-SA 3.0
2014-07-13T01:01:52.583Z
don't forget to mark your answer as correct :)
Tyler Willingham
CC BY-SA 3.0
2014-07-13T20:55:58.693Z
Nice job tracking this down, Jason!
Matt Stein
CC BY-SA 3.0
2014-08-18T09:42:43.940Z
I was running into the same problem when I enabled NFS on Vagrant, and this answer fixed it. Thanks!
mohd4482
CC BY-SA 3.0
2014-10-09T04:18:28.173Z
I was wondering how this affects Craft or the security of the site, if at all. I think I'm currently having this same problem. I'm constantly being logged out from the server (dev and pro).
cballenar
CC BY-SA 3.0
2014-10-09T13:54:13.730Z
Did you try the 'overridePhpSessionLocation' => false setting? Notice PHP is not capitalized. The setting used to work with PHP in all caps (recently it started happening again until @BradBell figured it out).
Jason D
CC BY-SA 3.0
2014-10-09T13:57:33.557Z
Also it shouldn't the security of the site at all. All it does is change where the session data file is stored back to the default location.
Jason D
CC BY-SA 3.0
2014-07-13T00:43:44.053Z
2014-10-07T18:07:23.047Z
2014-10-07T18:07:23.047Z
Jason D
<p>While working in the Craft admin area, on a fresh install, I get logged out every once in a while. It makes the CMS unusable. </p>

<p>I have tried:</p>

<ol>
<li>Clearing cookies</li>
<li>Resetting the cache in the backend</li>
</ol>

<p>Sometimes it logs out after 1 pageview, sometimes after 10. </p>

<p>I am using a Macbook Pro, 10.9.3 Mavericks. This happens in both Chrome and Safari (haven't tried Firefox).</p>

<p>I am running Vagrant with: PHP 5.5.12, Ubunutu 14.04, Nginx. Accessing the project locally via <a href="http://project.craft.dev">http://project.craft.dev</a> </p>

<p>Has anyone experienced something similar? Are there any error logs for this kind of thing?</p>

<p>Update: in the craft.log I get a few errors:</p>

<pre><code>2014/07/11 19:38:56 [trace] [system.db.CDbCommand] Querying SQL: SELECT count(`id`) FROM `craft_tasks` WHERE (level = 0) AND (status = :status). Bound with :status='error' 
in /vagrant/dlfm/craft/craft/app/etc/db/DbCommand.php (79) 
in /vagrant/dlfm/craft/craft/app/services/TasksService.php (420) 
in /vagrant/dlfm/craft/craft/app/controllers/TasksController.php (57)
</code></pre>

<p>and</p>

<pre><code>2014/07/11 19:38:55 [error] [php] session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/vagrant/dlfm/craft/craft/storage/runtime/sessions/) (/vagrant/dlfm/craft/craft/app/services/HttpRequestService.php:852)
Stack trace:
#0 /vagrant/dlfm/craft/craft/app/framework/web/actions/CInlineAction.php(49): Craft\TasksController-&gt;actionRunPendingTasks()
#1 /vagrant/dlfm/craft/craft/app/framework/web/CController.php(308): CInlineAction-&gt;runWithParams()
#2 /vagrant/dlfm/craft/craft/app/framework/web/CController.php(286): Craft\TasksController-&gt;runAction()
#3 /vagrant/dlfm/craft/craft/app/framework/web/CController.php(265): Craft\TasksController-&gt;runActionWithFilters()
#4 /vagrant/dlfm/craft/craft/app/framework/web/CWebApplication.php(282): Craft\TasksController-&gt;run()
#5 /vagrant/dlfm/craft/craft/app/etc/web/WebApp.php(863): Craft\WebApp-&gt;runController()
#6 /vagrant/dlfm/craft/craft/app/etc/web/WebApp.php(252): Craft\WebApp-&gt;_processActionRequest()
#7 /vagrant/dlfm/craft/craft/app/framework/base/CApplication.php(180): Craft\WebApp-&gt;processRequest()
#8 /vagrant/dlfm/craft/craft/app/index.php(196): Craft\WebApp-&gt;run()
#9 /vagrant/dlfm/craft/public/index.php(14): require_once()
REQUEST_URI=/index.php/admin/actions/tasks/runPendingTasks
in /vagrant/dlfm/craft/craft/app/services/HttpRequestService.php (852)
in /vagrant/dlfm/craft/craft/app/controllers/TasksController.php (37)
in /vagrant/dlfm/craft/craft/app/etc/web/WebApp.php (863)
</code></pre>

<p>but this one looks most suspect:</p>

<pre><code>24. 2014/07/11 19:41:47 [error] [application] Tried to restore session from a cookie, but the given login name does not match the given uid. UID: 9d515b08-1073-4872-a0e2-155c389a2991 and loginName: Jason.

24. 2014/07/11 19:41:47 [error] [application] Tried to restore session from a cookie, but the given hashed database token value does not appear to belong to the given login name. Hashed db value: 37bb858b4b13b688c4034fe5eb127f75f4931387czozNjoiNDBlNTk0YWQtNGYxZS00NjAxLWEwY2UtZDJlY2NhNDkwMmQ1Ijs= and loginName: Jason.
in /vagrant/dlfm/craft/craft/app/services/UserSessionService.php (797)
in /vagrant/dlfm/craft/craft/app/services/UserSessionService.php (64)
in /vagrant/dlfm/craft/craft/app/etc/web/WebApp.php (592)
</code></pre>

CC BY-SA 3.0
2014-07-11T19:17:41.313Z
You can check /admin/utils/logs, if you're logged in of course.
Matt Stein
CC BY-SA 3.0
2014-07-11T19:18:21.300Z
That's just a shortcut to your craft/storage/runtime/logs folder.  The reason you're getting logged out should be in there.
Brad Bell
CC BY-SA 3.0
2014-07-11T19:27:35.270Z
What should I look for in here? I don't see any errors, just a long list of what is being loaded or queried.
Jason D
CC BY-SA 3.0
2014-07-11T23:36:24.987Z
@JasonD Did I see you find the problem in today's Craft chat? If so, please add your answer for posterity! :)
Matt Stein
CC BY-SA 3.0
2014-07-12T18:24:19.393Z
@MattStein, thanks for your help on the chat! Unfortunately I am still experiencing this problem... I will add an answer as soon as I get one. For anyone else that ends up here: the current guess (that we had in the chat) is it's a Nginx/Vagrant issue not giving PHP the correct permissions to write the session data to craft/storage/runtime/sessions
Jason D
<users>
Craft constantly logging out from admin area
# Craft constantly logging out from admin area

(Asked by: username_0 on 2014-07-11)

While working in the Craft admin area, on a fresh install, I get logged out every once in a while. It makes the CMS unusable. 
I have tried:

Clearing cookies
Resetting the cache in the backend

Sometimes it logs out after 1 pageview, sometimes after 10. 
I am using a Macbook Pro, 10.9.3 Mavericks. This happens in both Chrome and Safari (haven't tried Firefox).
I am running Vagrant with: PHP 5.5.12, Ubunutu 14.04, Nginx. Accessing the project locally via http://project.craft.dev 
Has anyone experienced something similar? Are there any error logs for this kind of thing?
Update: in the craft.log I get a few errors:
2014/07/11 19:38:56 [trace] [system.db.CDbCommand] Querying SQL: SELECT count(`id`) FROM `craft_tasks` WHERE (level = 0) AND (status = :status). Bound with :status='error' 
in /vagrant/dlfm/craft/craft/app/etc/db/DbCommand.php (79) 
in /vagrant/dlfm/craft/craft/app/services/TasksService.php (420) 
in /vagrant/dlfm/craft/craft/app/controllers/TasksController.php (57)

and
2014/07/11 19:38:55 [error] [php] session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/vagrant/dlfm/craft/craft/storage/runtime/sessions/) (/vagrant/dlfm/craft/craft/app/services/HttpRequestService.php:852)
Stack trace:
#0 /vagrant/dlfm/craft/craft/app/framework/web/actions/CInlineAction.php(49): Craft\TasksController->actionRunPendingTasks()
#1 /vagrant/dlfm/craft/craft/app/framework/web/CController.php(308): CInlineAction->runWithParams()
#2 /vagrant/dlfm/craft/craft/app/framework/web/CController.php(286): Craft\TasksController->runAction()
#3 /vagrant/dlfm/craft/craft/app/framework/web/CController.php(265): Craft\TasksController->runActionWithFilters()
#4 /vagrant/dlfm/craft/craft/app/framework/web/CWebApplication.php(282): Craft\TasksController->run()
#5 /vagrant/dlfm/craft/craft/app/etc/web/WebApp.php(863): Craft\WebApp->runController()
#6 /vagrant/dlfm/craft/craft/app/etc/web/WebApp.php(252): Craft\WebApp->_processActionRequest()
#7 /vagrant/dlfm/craft/craft/app/framework/base/CApplication.php(180): Craft\WebApp->processRequest()
#8 /vagrant/dlfm/craft/craft/app/index.php(196): Craft\WebApp->run()
#9 /vagrant/dlfm/craft/public/index.php(14): require_once()
REQUEST_URI=/index.php/admin/actions/tasks/runPendingTasks
in /vagrant/dlfm/craft/craft/app/services/HttpRequestService.php (852)
in /vagrant/dlfm/craft/craft/app/controllers/TasksController.php (37)
in /vagrant/dlfm/craft/craft/app/etc/web/WebApp.php (863)

but this one looks most suspect:
24. 2014/07/11 19:41:47 [error] [application] Tried to restore session from a cookie, but the given login name does not match the given uid. UID: 9d515b08-1073-4872-a0e2-155c389a2991 and loginName: Jason.

24. 2014/07/11 19:41:47 [error] [application] Tried to restore session from a cookie, but the given hashed database token value does not appear to belong to the given login name. Hashed db value: 37bb858b4b13b688c4034fe5eb127f75f4931387czozNjoiNDBlNTk0YWQtNGYxZS00NjAxLWEwY2UtZDJlY2NhNDkwMmQ1Ijs= and loginName: Jason.
in /vagrant/dlfm/craft/craft/app/services/UserSessionService.php (797)
in /vagrant/dlfm/craft/craft/app/services/UserSessionService.php (64)
in /vagrant/dlfm/craft/craft/app/etc/web/WebApp.php (592)

**Tags:** users

> **Comments:**
> **username_1**: You can check /admin/utils/logs, if you're logged in of course.  
> **username_2**: That's just a shortcut to your craft/storage/runtime/logs folder.  The reason you're getting logged out should be in there.  
> **username_0**: What should I look for in here? I don't see any errors, just a long list of what is being loaded or queried.  
> **username_1**: @JasonD Did I see you find the problem in today's Craft chat? If so, please add your answer for posterity! :)  
> **username_0**: @MattStein, thanks for your help on the chat! Unfortunately I am still experiencing this problem... I will add an answer as soon as I get one. For anyone else that ends up here: the current guess (that we had in the chat) is it's a Nginx/Vagrant issue not giving PHP the correct permissions to write the session data to craft/storage/runtime/sessions  

---

## 9 answers

### Answer by username_0 on 2014-07-13. Score: 26 | Accepted answer

My solution is to add:
'overridePhpSessionLocation' => false

Into craft/config/general.php
This tells Craft to use the default location to write sessions, instead of craft/storage/runtime/sessions
For whatever reason, even though  craft/storage/runtime/sessions has CHMOD 777, PHP was saving the session file with 644. When it tried to write to the same file again, it got and error and logged me out.
I also (unsuccessfully) tried giving PHP ownership of the folder, which should in theory fix the problem too.
 sudo chown -R www-data:www-data sessions
 chown: www-data: illegal group name

I am assuming it's a Vagrant/OSX thing.

> **Comments:**
> **username_2**: Ahh... nice catch.  I had forgotten about that config setting.  It was originally added because some edge case hosts were doing crazy things like storing PHP session in memcache.  
> **username_10**: don't forget to mark your answer as correct :)  
> **username_1**: Nice job tracking this down, Jason!  
> **username_11**: I was running into the same problem when I enabled NFS on Vagrant, and this answer fixed it. Thanks!  
> **username_12**: I was wondering how this affects Craft or the security of the site, if at all. I think I'm currently having this same problem. I'm constantly being logged out from the server (dev and pro).  
> **username_0**: Did you try the 'overridePhpSessionLocation' => false setting? Notice PHP is not capitalized. The setting used to work with PHP in all caps (recently it started happening again until @BradBell figured it out).  
> **username_0**: Also it shouldn't the security of the site at all. All it does is change where the session data file is stored back to the default location.  

---

### Answer by username_3 on 2017-07-04. Score: 4

For me the solution required was

`'requireMatchingUserAgentForSession' => false` in my `config/general.php`

I was debugging the site in Chrome and it was changing my user agent, which was instantly logging me out.


---

### Answer by username_4 on 2015-01-06. Score: 4

These are the steps that solved the problem for me (PHP 5.4 , Nginx):

* Delete the contents of `craft/storage/runtime`
* Set the [correct file permissions](http://buildwithcraft.com/docs/installing#step-2-set-the-permissions)
* Added `'overridePhpSessionLocation' => true,` to the site configuration


---

### Answer by username_5 on 2015-01-30. Score: 3

For us, we had the same problem but a different root cause.
We noticed that we were getting multiple new session files created for each request, all with the same data in them. After a bit of digging, I noticed session.auto_start was On in php.ini, so tried turning it Off.
And that fixed it, no more surplus session files been created on disk, and no random logging out. 
So make sure that php.ini has 
session.auto_start = 0


---

### Answer by username_6 on 2014-07-11. Score: 2

Check if you can write in /vagrant/dlfm/craft/craft/storage/runtime/sessions/.
There is where the sessions are being stored.
To test, try chmod 777 -R /vagrant/dlfm/craft/craft/storage/runtime/sessions and try again.
Those permissions are too wide, but if this works after you might know the cause.

> **Comments:**
> **username_0**: I double-checked /storage and /storage/* and they're at 777, and the problem is continues to happen..  
> **username_6**: I dont think this is related to Craft but to your Vagrant configuration, where you mount the shared folder into the VM. Can you post your Vagrantfile here? I created this VM provisiones with Ansible and is the one we are using to develop Craft, feel free to test it: https://github.com/miguelbalparda/vm  

---

### Answer by username_7 on 2017-07-04. Score: 2

Here's more on PHP sessions & Craft if it helps:

[The Case of the Missing PHP Session](https://nystudio107.com/blog/the-case-of-the-missing-php-session)


---

### Answer by username_8 on 2014-10-08. Score: 1

I've had the same problem for the past few weeks with my windows vagrant setup, it's been driving me crazy. Works fine on our staging server.

I think I finally got it working :)

I did 2 things not sure yet which fixed it:

1. added this to my vagrant file
   config.vm.synced\_folder "./craft/storage/runtime", "/var/www/craft/storage/runtime",
   disabled: true
2. destroyed my vagrant instance (vagrant destroy) and recreated it (vagrant up)

> **Comments:**
> **username_8**: Nah still having problems, but I have narrowed it down... When I first setup my vagrant instance it all works fine,then after a few hours craft admin starts complaining that cUrl is not installed (I guess it's trying to check for updates), so I install cUrl and that's when I start having problems, the sessions files don't write and the only fix I can find is to destroy my instance and start again  

---

### Answer by username_8 on 2014-11-11. Score: 1

OK I have a definite answer to this issue this time...
The problem is caused because craft fails to write out the session files in /craft/storage/runtime/sessions, if you look in there you will see zero byte files :(
The issue seems to be because of vagrant/virtual box syncing files between the host and my pc. So the trick is to get vagrant not to sync the sessions folder. For me this was not that easy, it seems that if you sync the /craft folder it syncs all subfolders even if you tell it not to (by creating another sync and disabling it). So I had to explicitly state which craft folders to sync - ugh! It works which is great, but I am predicting trouble down the track if craft adds another folder to it's top level structure.
Anyway here is what I put in my vagrant file to get it work
config.vm.synced_folder "./public", "/var/www/public", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/app", "/var/www/craft/app", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/plugins", "/var/www/craft/plugins", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/config", "/var/www/craft/config", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/templates", "/var/www/craft/templates", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/backups", "/var/www/craft/storage/backups", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/userphotos", "/var/www/craft/storage/userphotos", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/runtime/assets", "/var/www/craft/storage/runtime/assets", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/runtime/cache", "/var/www/craft/storage/runtime/cache", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/runtime/compiled_templates", "/var/www/craft/storage/runtime/compiled_templates", :mount_options => ['dmode=777', 

'fmode=777']
    config.vm.synced_folder "./craft/storage/runtime/logs", "/var/www/craft/storage/runtime/logs", :mount_options => ['dmode=777', 'fmode=777']
    config.vm.synced_folder "./craft/storage/runtime/state", "/var/www/craft/storage/runtime/state", :mount_options => ['dmode=777', 'fmode=777']
    config.vm.synced_folder "./craft/storage/runtime/temp", "/var/www/craft/storage/runtime/temp", :mount_options => ['dmode=777', 'fmode=777']


---

### Answer by username_9 on 2019-10-31. Score: 1

My solution was to run:

`sudo chown -R ec2-user /var/lib/php/session/`

Obviously your mileage would vary depending on your setup


---

