Laravel / Heroku，没有用于会话的此类文件或目录

Question

I'm trying to run my application on heroku, but for some requests (only POST, GET are working fine), I've got the following error on my Ajax POST request:

Error: Request failed with status code 419

When I check heroku logs, I get this error:

     production.ERROR: file_put_contents(/app/storage/framework/sessions/r9yIHf3WlKIzROWGPlVOk59rwr6tVyAeCLuJ9wWx): 
failed to open stream: No such file or directory
{"userId":1,"email":"xxx@gmail.com","exception":"[object] (ErrorException(code: 0): 
file_put_contents(/app/storage/framework/sessions/r9yIHf3WlKIzROWGPlVOk59rwr6tVyAeCLuJ9wWx): failed to open stream: No such file or directory at /app/vendor/laravel/framework/src/Illuminate/Filesystem/Filesystem.php:122)

I've checked, the directory /storage/framework/sessions is existing.

I've tried to run chmod 777 -R / (but still this issue)

I've tried the following commands:

php artisan optimize
php artisan config:clear
php artisan cache:clear
php artisan config:cache
php artisan optimize:clear

A touch /app/storage/framework/sessions/r9yIHf3WlKIzROWGPlVOk59rwr6tVyAeCLuJ9wWx is not working either.

I've tried to remove the storage folder and create it again.

Do you have an idea of what could go wrong?

Answer 1

Heroku's filesystem is temporary, and goes away any time your dynos are restarted - ie at least once daily (due to the automatic restarts Heroku does) and after every deploy or config change.

In addition, heroku run bash connects you to a brand new, separate server , so if you're creating/modifying files/folders/permissions in that, it'll literally all go away as soon as you close out of the session. There's no effect on the actual webserver instances.

This means you shouldn't rely on the filesystem for anything intended to be permanent - no file uploads, for example (they should go somewhere like AWS S3). Plus, if you're using more than one dyno, storing session data as files will mean the session only exists on one of the dynos - on the next pageview, there's a good chance it'll be gone, as the user has hit a different dyno.

Solution? Store sessions using a different driver. I prefer the Redis driver, but you could use the database one if you wanted to keep complexity down a bit.