Update Jan 2020
Seems there is an easy solution to all of this. Using this answer https://serverfault.com/a/96349 as a reference, you can set the gid bit on the parent folder so that all subsequent files & folders created under ./storage/*
are writable by anyone in the correct group regardless of who created them; thereby overcoming the group security permission issues as explained below.
This works for me:
# Assumes all required users belong to the www-data group
sudo chgrp -R www-data /path/to/storage
sudo chmod g+s /path/to/storage
Short answer
Use sudo: sudo rm -r ./storage/framework/cache
Long answer
Make sure all processes writing to the cache use the same user (and not just belong to the same group) because it turns out that Laravel writes cache files with privileges something along the lines of 0755 which restricts writes to the owner.
If like me you use a different user for each of these:
- PHP process
- Artisan CLI
- Artisan via supervisor (for jobs)
You end up with files that belong to different users and cannot be written to or deleted by the other users even if they belong to the required group (www-data as an example).
Hopefully someone can find a way to set new cache file privileges in Larvel to something like 0775. It would be nice if it just inherited from the parent.
Side note
This for me was also causing a problem with Cache::remember()
between the supervisor process & the PHP process such that I was getting put_file_contents
errors because the cached files couldn't be written to by the different users.
Original answer
I was having the same problem and in my case the files weren't being deleted because they were write protected. When I went to delete them manually using rm -r ./storage/framework/cache
I got the warning rm: descend into write-protected directory 'cache/c5'?
. I wasn't going to type yes for every file in the cache so I ran the same command as sudo & it worked without a hitch sudo rm -r ./storage/framework/cache
.
This answers your question as to why they aren't being deleted by Artisan cache:clear
& running rm
is an easy enough work-around; although it doesn't solve the problem of why the files are being written as write-protected.
After deleting the cache Laravel again creates the cache as write-protected. This means it is probably a bug & requires someone to submit a bug report to the Laravel developers. Since the work-around is trivial I'll leave that for someone else to do.