EnglishLaravel error
Laravel: Please provide a valid cache path
The error
InvalidArgumentException: Please provide a valid cache path.The view compiler could not write to storage. It is almost always a deploy that shipped the application without its storage directories, or shipped them owned by the wrong user.
InvalidArgumentException: Please provide a valid cache path.
in vendor/laravel/framework/src/Illuminate/View/Engines/CompilerEngine.php
The Blade compiler needs a directory to write compiled templates into, cannot find or cannot write to the one it was given, and refuses to start. The path is storage/framework/views.
It appears on a fresh deploy, in a new container, or after someone cleaned a server, and essentially never during normal running.
The directory is missing
storage is in .gitignore for good reasons, and the skeleton Laravel ships keeps the structure with per-directory ignore files. A deploy that builds from a clone, or an archive that dropped empty directories, arrives without them:
mkdir -p storage/framework/{views,cache/data,sessions,testing}
mkdir -p storage/{app/public,logs} bootstrap/cacheThis belongs in the deploy script. A server that needed it once will need it on the next fresh instance, and remembering is not a strategy.
The directory exists and the wrong user owns it
The second cause and the more common one in practice. Two identities touch the application - the web server process, and whoever runs the deploy or the cron - and whichever created the directory owns it.
sudo chown -R deploy:www-data storage bootstrap/cache
sudo chmod -R 775 storage bootstrap/cacheA group both belong to, write permission for that group. Not chmod 777: that grants write to every process on the machine, including anything that gets a foothold through something else, and this directory is executed as PHP afterwards.
If you are running php artisan as root during deploys, that is the thing to stop. Root-owned files in storage break the web server quietly and are tedious to find.
Read-only or ephemeral filesystems
In a container with a read-only root, or a platform where the filesystem resets, none of the above applies - there is nowhere to write by design.
Compiled views are derived from your source, so the right answer is to build them into the image rather than to make the path writable:
php artisan view:cache # at build time, in the DockerfileThen mount a writable volume for the paths that hold genuine runtime state - logs, sessions if they are on disk, uploads - and keep sessions and cache in Redis where they belong for anything running more than one instance.
Why it shows up after a deploy that "changed nothing"
Because view:cache and the directory check run at boot, and the previous release had a directory that this one does not. The code is identical; the filesystem under it is not.
That pattern - an error that belongs to the deployment rather than the application - is most of what maintenance work actually consists of, and the fix is usually to make the deploy reproducible rather than to repair the server by hand.