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

vatsake's avatar

Unable to create lockable file

I'm using files to save session data. Occasionally I get error "Unable to create lockable file: .... storage/framework/cache/data...

But when i look the folder, the file exists (with session data).

BTW, I'm using windows.

0 likes
3 replies
_Philip's avatar

I have the same issue, I think.

I'll share my situation, so we can try to find the underlying problem.

Set-up

I have some API resource routes that get fetched by my React (Redux Toolkit Query) frontend.

I'm running XAMPP for the PHP dev server and Vite for the frontend HMR.

Re-creating the issue

  1. I have my dev servers running and my app open in the browser.
  2. I leave it for a while.
  3. I come back and make + save some changes in one of my React components files.
  4. The issue occurs:
    • (Without manually reloading the page) HMR does reload some component stuff
    • My updated components are loaded just fine
    • BUT: some requests to the API routes return status 500 with this exception:
Unable to create lockable file: D:\path\to\my\app\storage\framework/cache/data/c0/71/c071...etc.... Please ensure you have permission to create files in this location.

(from vendor\\laravel\\framework\\src\\Illuminate\\Filesystem\\LockableFile.php)

Very strange, since the entire app was first created as the same (and only) user on my pc and file and directory permissions are fine.

Also, not all API routes return status 500 with this exception and different ones each time.. Redux' retry attempt fetches the API just fine after the initial errored request.

Possible problem?

Could it be that the HMR reloading interferes with PHP's file access? As in: while PHP is trying to access the cache, Vite is also accessing those files or directories (checking for changes to push to HMR)?

Anyway, I have not yet found a solution.

Running:

  • Laravel v9.33.0
  • HMR Server: Vite v3.2.2
  • PHP Server: XAMPP v3.3.0 - PHP v8.1.10
  • OS: Windows 11 Pro
_Philip's avatar

Ah, okay. For me that is a bit inconvenient, so I am hoping someone can shed a bit more light on why this exception is thrown at all.

I also noticed the irregularity of which requests fail and if they fail at all. So it seems like a race condition issue between Apache/PHP and Vite.

Anyone have any idea on what is causing this and/or what the solution might be?

NB: This exception is mentioned here as well, but, as I mentioned, there can't be a user access related issue.

Please or to participate in this conversation.