Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

kenprogrammer's avatar

Cache Issues on an API-based project

Can someone shed light on why these errors occur in an API-based project? The project serves an Angular frontend and a mobile app. For authentication I'm using Sactum. fopen(/var/www/html/storage/framework/cache/data/85/91/859101d82a88b25b9d26729b082dc2b6022ccf2d): Failed to open stream: No such file or directory

fopen(/var/www/html/storage/framework/cache/data/19/82/198290ff4dc4b92182639c6b7ec3ac7e01d95cd6): Failed to open stream: Permission denied

To my understanding these are supposed to occur on blade based projects.

0 likes
10 replies
Glukinho's avatar

Tune permissions on /var/www/html/storage/ so your web server user has read/write rights.

Try this, if the problems goes away, tune permissions more accurately (755 for appropriate user/group):

chmod -R 777 /var/www/html/storage/
kenprogrammer's avatar

@Glukinho The permissions and storage folder ownership are set correctly. It's the newly generated cache folders under framework/cache/data that are not inheriting the permissions and parent folder ownership.

Glukinho's avatar

@kenprogrammer Which user/group your web server is working as? Which permissions exactly are set on /var/www/html/storage/? Which permissions are set on /var/www/html/storage/framework/cache/data/19/82/198290ff4dc4b92182639c6b7ec3ac7e01d95cd6?

Do you have artisan commands (maybe scheduled) or queue workers that work as root, not web server? They can mess web servers's permissions.

kenprogrammer's avatar

@Glukinho Linux user belonging to sudoers and www-data

Permission and ownership on storage folder:

drwxrwxr-x  6 linux-user www-data   4096

I've a bash deployment script triggered by Git post receive hook after successful push to production. The script contains commands to run migration, seed database, clear config, application and view cache among other commands

Glukinho's avatar

@kenprogrammer When an error appears, get permissions of exact object (file or folder) the error says about. Compare them to default permissions you set on storage folder. Try to understand why they are different (if they are).

I would say this is about scheduled commands/queued jobs which execute as a user other than www-data.

1 like
JussiMannisto's avatar

@kenprogrammer

The permissions and storage folder ownership are set correctly.

I doubt this.

Storage files and directories must be owned by the web server user, which is often www-data, apache or http. So not linux-user, let alone root. But you didn't mention which web server you're using or what user it's running as.

You should also run Artisan commands as the web server user. Otherwise, any files or directories created by the commands will have the wrong owner, the Laravel app can't write to them, and you'll get errors like the one you showed.

# Incorrect:
sudo php artisan cache:clear

# Correct, assuming the server is running as www-data:
sudo -u www-data php artisan cache:clear

On another point, your Laravel project is at /var/www/html/, which is the default root directory of Apache. Have you configured the document root to /var/www/html/public? If it's at /var/www/html/, that's a huge security issue.

kenprogrammer's avatar

@JussiMannisto When the project or storage directory is explicitly owned by web server user the deployment script is denied permission to push code updates since it's owned by linux-user.

Here is how I usually set directory ownership and permissions after deploying a fresh project to production:

sudo chown -R linux-user:www-data project-directory

sudo chmod -R 775 project-directory

In this case I'm using nginx as a web server.

By the way /var/www/html/ is just an example

JussiMannisto's avatar

@kenprogrammer The error message is very clear. Your file/directory permissions are not correct if you're getting Failed to open stream: Permission denied.

If you run Artisan commands as sudo or linux-user, any created directories or files won't have the correct owner until you chown them again. Running artisan commands as www-data would get rid of this issue. I use aliases on staging/live servers:

# In a user dotfile:
alias art='sudo -u www-data php artisan'

# Usage:
art migrate
1 like

Please or to participate in this conversation.