watchpack: Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/...'

Plus another, also with WSL2 + Windows 10

Watchpack Error (initial scan): Error: EACCES: permission denied, lstat ‘/mnt/c/DumpStack.log.tmp’ Watchpack Error (initial scan): Error: EACCES: permission denied, lstat ‘/mnt/c/hiberfil.sys’ Watchpack Error (initial scan): Error: EACCES: permission denied, lstat ‘/mnt/c/pagefile.sys’ Watchpack Error (initial scan): Error: EACCES: permission denied, lstat ‘/mnt/c/swapfile.sys’

Just do what I did. I completely removed Windows, replaced it with Linux. No more WSL, no more Microsoft. I am able to solve most issues, but WSL is not true Linux. Life is so much easier now. As for Lieutu, It isn’t so arbitrary. You should get your facts straight before you add your input.

Okay, finally fixed it. The problem is with the path as already someone said. Your project should not be located at /mnt/d/... or somewhere on your windows machine. Instead just make sure you have did this:

1. cd ~ your path here should be like user@user which means /home/user/ in linux
2. now make git clone/set up project manually

Plus one running into the same issue with WSL2 + Windows 10. I have root mounted as / in WSL, so:

Watchpack Error (initial scan): Error: EACCES: permission denied, lstat ‘/c/DumpStack.log.tmp’ Watchpack Error (initial scan): Error: EACCES: permission denied, lstat ‘/c/hiberfil.sys’ Watchpack Error (initial scan): Error: EACCES: permission denied, lstat ‘/c/pagefile.sys’ Watchpack Error (initial scan): Error: EACCES: permission denied, lstat ‘/c/swapfile.sys’

I am having the same problem. I am in a process of migrating from Gatsby v2 to v3. As far as i understand, this has something to do with WSL2. I just hope that Gatsby team will not forget this issue.

@dbooyah93 is there any fix for this issue?

For many people “simply” moving project is impossible due to various reasons. I also don’t quite understand why any program would go through whole directory listing, this is literally something that is against unix way - users don’t expect project watcher to iterate through whole hierarchy to list and watch every ancestor.

I can put it in the following way: does anyone even expect this behavior? It is counter-intuitive

So for some incredibly rare arbitrary use-case of someone potentially at some point having a minor issue because they might replace a directory with a link at some point, you now watch all the paths above the context and thus cause issues to everyone else except this approx. 0.0001% of potential users?

Maybe do the exact opposite and let that 0.0001% fix the problems they cause by themselves and let everyone else have a functioning system that doesn’t unnecessarily watch for all changes in all their parent directories?

I’m am perturbed that the watcher is trying to watch files out of the immediate project tree. I do not expect this and do not want my development tools to access files that are not a part of my project or the development tool itself.

This feels like behaviour that could lead to wider system insecurity ( what happens if a watcher succeeds on my swapfile and a lot of swapping is happening?) does every swap write trigger a build? It’s like inviting a friend over for dinner and finding them rifling through your underwear drawer.

So the errors are actually irrelevant for watching these the Users directory. It would probably make sense to ignore them internally until these files are actually watched.

@sokra It seems like you had a particular workaround in mind. It would be great if you could implement and release that. As you say, the errors are harmless. But they don’t look like that, and in the face of any (unrelated) issues with Webpack, people will waste lots of time investigating them, and some of the end up here and even take the time to post screenshots and repro-instructions here, which shows how much time they’ve previously spent on debugging. We should save that time by suppressing the errors.

Suggesting folks move their code from /mnt/... to ~ is complete nonsense. The primary OS in all of these examples is Windows and the rules we use must should put Windows first. Especially when virtually every tool use (VSCode, etc.) doesn’t care that you are running [essentially] an emulator on top of the OS. Using a mountpoint under /mnt to access a device outside of Linux is the proper way of connecting to C:\ or any other drive. Guess with the logic above, developers are expected to never use any other drive besides C?

The same holds true for anyone trying to excuse the bad behavior of Watchpack / Webpack. Creating a file watcher at any parent folder to your project means you are allowing the component to examine, and possibly react to, file changes in completely unrelated folder structures. Even if we want to believe that no harm will come to those other files and folders, at a minimum this means that additional processing power is unnecessarily being used watching countless files that are not relevant to our project.

On my Linux and Mac boxes I use ~/Source as it is natural and expected for those operating systems. While on Windows I use C:\_ as my source folder. This decreases the chance of running into a Windows path length limitation as it is not always possible to enable long paths. Any app relying on WSL is just that; an application. This includes an instance of nNix running within WSL. There’s no way I’m going to bury data in any appllication or application-specific location

The bottom line is that a project folder is created to ensure only the files in that structure are ever touched. No utility has any business touching, watching, or examining any other folder or file on the system. Doing so is unethical and, at a minimum, incredibly lazy. Stop excusing bad behavior.

Hello I have a workaround that doesn’t involve migrating into the linux filesystem:

You have to catch the offending files on the /node_modules/watchpack/lib/DirectoryWatcher.js by dropping them from the scan set. After line 594 on WatchPack module version: 2.2.0 (below the itemPaths Set creation)

itemPaths.delete('/mnt/c/DumpStack.log.tmp');
itemPaths.delete('/mnt/c/hiberfil.sys');
itemPaths.delete('/mnt/c/pagefile.sys');
itemPaths.delete('/mnt/c/swapfile.sys');

Basically you are catching the files so that the doScan will not try to lstat them on line 653.

This should work as long as you don’t update the module. Moreover, I have tested that it is only a warning like @sokra mentioned. I had issues with BrowserSync not being configured. I don’t have any issues now.

Also check you have BrowserSync declared on your laravelMix/js file, with it’s source and proxy. And remember there are two different node_modules. You want either browser-sync or browsersync, depending on your tools.

I’m having same issue. Here is the takeout I can contribute:

Takeout 1:

Not legit to require me to move the project - this is how my customer wants it for their own reasons. Their project, their machine their rules.

Takeout 2:

that my WSL is configured to mount /c/ and not /mnt/c. So assuming the /mnt prefix is not legit - it’s a user setting.

Takeout 3:

I understand the need to watch the tree up, I don’t understand why it tries to list files that are not direct parents of the paths it watches - this sounds like a bug. It may work, sure - but it probably watches much more than it has to, resulting with an unecessarily big footprint, and probably watches that are irrelevant but do succeed that we do not know of…

Not to mention the case that it might someday succeed watching any of:

Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/c/DumpStack.log.tmp'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/c/hiberfil.sys'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/c/pagefile.sys'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/c/swapfile.sys'

Takeout 4

Last takeout you might want to pickup - It’s does not look like a warning. If it was a warning I would have known to ignore it.

It sais “Error” up there. Twice per file… 😛 - don’t blame me for taking you seriously. Error = demands attention. For the least of it - when you emit this message - emit a warning in the spirit of

Warning - some paths could not be watched: changes in them will not trigger the expected behavior
 - /c/DumpStack.log.tmp 
 - /c/biberfil.sys
 - /c/pagefile.sys
 - /c/swapfile.sys 

(and yes, emitting the title once and an entry per file is totally something I do in the outputs of CLI tools I author)

Keep up the good work, Thank you for your service, 'n all that stuff 😉

cheers.

So for some incredibly rare arbitrary use-case of someone potentially at some point having a minor issue because they might replace a directory with a link at some point, you now watch all the paths above the context and thus cause issues to everyone else except this approx. 0.0001% of potential users?

Maybe do the exact opposite and let that 0.0001% fix the problems they cause by themselves and let everyone else have a functioning system that doesn’t unnecessarily watch for all changes in all their parent directories?

Your lack of empathy makes sense until a patron is hit with the realization that this is a thread meant for supporting users.

It’s normal that these directories are watched. The relevant entry is /mnt/c/Users which is watched because the Users directory could theoretically change to a symlink to some different location. Watchpack always watches to complete directory instead of single files for performance reasons.

The directory /mnt/c/Users is absolutely irrelevant. Maybe relevant is $HOME. And panicing about “the user directory might change during a session, so I better watch it” is pure nonsense.

I had a similar issue with Windows 10 and WSL 2, moving the project to the Ubuntu filesystem fixed it for me.

This is also recommended from Microsoft as stated above.

We recommend against working across operating systems with your files, unless you have a specific reason for doing so. For the fastest performance speed, store your files in the WSL file system if you are working in a Linux command line (Ubuntu, OpenSUSE, etc). If you’re working in a Windows command line (PowerShell, Command Prompt), store your files in the Windows file system.

So if you have your files in C:\Users\YourName\workspace\your-project just move it to \\wsl$\Ubuntu\home\YourName\workspace\your-project and you should be fine. The files can still be accessed comfortably from Windows, especially if you create a bookmark to \\wsl$\Ubuntu in Quick Access. To be sure nothing odd happens I did not copy package-lock.json and node_modules and did a fresh npm install after copying.

Note: The folder workspace is just what I personally use as a container for my projects. You can also move the project to any other folder in the Ubuntu filesystem, preferrably someting in you home directory of course.

The downside, though, is that PHPStorm now is complaining about the network mount, but I did not feel any big difference yet:

Maybe running PHPStorm native in Ubuntu using WSLg would be a viable solution for this issue in the Future.

Your project should not be located at /mnt/d/... or somewhere on your windows machine.

The project sometimes must be located on windows for some reason.

Same here: WSL 2, win 10

Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/d/DumpStack.log.tmp'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/d/pagefile.sys'

This was happening to me. I am using WSL2 and on Windows I have the GUI program Github Desktop installed. Because it likes managing the repo, I had just symlinked it to my WSL2 directory.

To reproduce open up the Terminal which starts in the WSL2 context (I am using WIndows Terminal from the App Store) You will be as stated in the OS context you installed (Ubuntu, Kali, etc…)

ln -fs /mnt/c/Users/cjensen/Documents/GitHub/my_repo ~/projects/
cd ~/projects/my_repo
npm install
npm run dev

That is where I get the error

Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/DumpStack.log.tmp'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/pagefile.sys'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/hiberfil.sys'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/swapfile.sys'

I don’t know even after reading the above why WebPack is interested in the above files, but in my case unlinking the symlink and moving the entire project to my WSL2 Linux directory worked.

cd ~/projects/
unlink ./my_repo
cp -rf /mnt/c/Users/cjensen/Documents/GitHub/my_repo ~/projects
cd ~/projects/my_repo
npm run dev

No longer getting error/warning message. Maybe that will help anyone else.

It’s normal that these directories are watched. The relevant entry is /mnt/c/Users which is watched because the Users directory could theoretically change to a symlink to some different location. Watchpack always watches to complete directory instead of single files for performance reasons.

So the errors are actually irrelevant for watching these the Users directory. It would probably make sense to ignore them internally until these files are actually watched.

It’s only a warning and won’t affect watching in any way. We want to fix that problem eventually in watchpack, by ignoring these errors for files you are not directly watching.

Agreed with @jmereardon17 It is working on Powershell but since WSL2 is gaining some popularity, I think we need to figure out a way to make it work there too. I also prefer ubuntu + zsh as my personal favorite.

As @lightmyfire17 said, you should be working in the /home/user/ folder if you are using WSL 2. Windows recommends that and it solves the issue.

You can read more here: https://docs.microsoft.com/en-us/windows/wsl/compare-versions under Performance across OS file systems

I had been using mnt/c/repos/myapp/ and when I switched to /home/{User}/repos/myapp, not only did the error go away with files but the compile time improved substantially.

Aside from the dangers of have to operating systems having access to the same files, the performance benefit is worth noting.

As @lightmyfire17 said, you should be working in the /home/user/ folder if you are using WSL 2. Windows recommends that and it solves the issue.

You can read more here: https://docs.microsoft.com/en-us/windows/wsl/compare-versions under Performance across OS file systems

nobody reads your content of files, it is just lstat and mostly related to WSL logic and described above why it happens

The problem is, since Next.js uses this version, it doesn’t handle Fast Refresh in Next.js App, because of which we need to stop and restart the servers every time I make any change.

Hey guys. Try:

• Delete your node_modules.
• Move your project folder to /home/$USER and install node_modules again. It’s worked for me.

# delete node_modules
mv (your_project_folder) /home/$USER
cd /home/$USER/(your_project_folder)
yarn install
yarn start # or yarn dev

If don’t work install webpack global package and try again. I’m using Windows 11 with WSL 2.

Would like to know a solution as well, I prefer using ubuntu with zsh as my terminal, alongside node etc being installed there. I am a user who can’t move projects under the home/user directory, because my work uses Visual Studio with IIS to build and run ASP.NET MVC based solutions, this is impossible as far as I am aware to run under a linux environment even possibly with reverse-proxies etc.

I am forced to keep my projects under Windows but I prefer to use ubuntu + zsh as my terminal, there has to be a solution for users with the same env as me.

I think we can ignore (on code level, so you will not see them) these warning, i.e. all above context

I have this issue on WSL2 path to project: /mnt/c/Users/username/Documents/Projects/gatsby-blog

 ERROR

Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/DumpStack.log.tmp'


 ERROR

Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/hiberfil.sys'


 ERROR

Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/pagefile.sys'


 ERROR

Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/swapfile.sys'

Can reproduce like this

gatsby new my-blog-starter https://github.com/gatsbyjs/gatsby-starter-blog
cd my-blog-starter
gatsby develop

FWIW I found this thread after running into the same error on Arch Linux. I use pCloud which puts a fuse mount in my home directory and was getting Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/home/whoops/pCloudDrive'. Needless to say, my project isn’t in that directory and has no dependency on it. After reading this thread and confirming with some console.logs sure enough WatchPack was trying to lstat that mount point when watching my home directory.

I’m also not sure why it was getting permission denied when it tried, but it was certainly confusing and sent me down some rabbit holes trying to figure out what I misconfigured to make it even try.

I wrote a Hack plugin to workaround this issue:

import {Compiler} from 'webpack';
...
apply(compiler: Compiler) {
const lookupSet = new Set<string>(['/', '/data', '/data/data']; // Those EACCES directories
compiler.hooks.done.tap('TermuxIssueResolve', stats => {
      for (const item of stats.compilation.fileDependencies) {
        if (lookupSet.has(item)) {
          // eslint-disable-next-line no-console
          console.log('[TermuxIssueWebpackPlugin] remove unaccessible fileDependency', item);
          stats.compilation.fileDependencies.delete(item);
        }
      }
    });
}
...

This was the answer for me

On Mon, Jul 26, 2021 at 7:04 PM Michael Spackman @.***> wrote:

I got this to work by running npm from a PowerShell terminal. I think that means I have node installed both on Windows and on WSL2, but because it’s Node running on windows from a windows command with windows permissions it doesn’t provide the error that it can’t see files in the parent directory.

So I get something like this: C:\code\my_project>npm run watch

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/webpack/watchpack/issues/187#issuecomment-887109204, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMMF3N45V4KWTFXI2PWUWCLTZXZZJANCNFSM4VS3LWJA .

I got this to work by running npm from a PowerShell terminal. I think that means I have node installed both on Windows and on WSL2, but because it’s Node running on windows from a windows command with windows permissions it doesn’t provide the error that it can’t see files in the parent directory.

So I get something like this: C:\code\my_project>npm run watch

I am facing this exact same problem but with the Next.js official documentation tutorial. I am running in WSL2 and by default Next.js uses Webpack 5. I am not sure if this is because of version 5 or not. On running the dev server, it shows this exact same error.

However, the issue doesn’t come up if I use Powershell on Windows 10.

For more details, I have mentioned the issue in this post: https://github.com/vercel/next.js/issues/27479

Well i also run into the same error. Running windows 10 x64 bit

Watchpack Error (initial scan): Error: UNKNOWN: unknown error, lstat ‘C:$360Section’

Nothing here worked for me, my source is within wsl2 filesystem (/home/<user>/git/<project> but still it tries to scan the entire filesystem including /mnt/, /proc/

.... Watchpack Error (initial scan): Error: EACCES: permission denied, scandir '/proc/1/fd' Watchpack Error (initial scan): Error: EACCES: permission denied, scandir '/proc/1/fdinfo' Watchpack Error (initial scan): Error: EACCES: permission denied, scandir '/proc/1/map_files' .... Watchpack Error (watcher): Error: EACCES: permission denied, watch '/mnt/c/Windows/SysWOW64/sru' Watchpack Error (watcher): Error: EACCES: permission denied, watch '/mnt/c/Windows/appcompat/Programs' Watchpack Error (watcher): Error: EACCES: permission denied, watch '/mnt/c/Windows/security/audit' Watchpack Error (watcher): Error: EACCES: permission denied, watch '/mnt/c/Windows/security/cap' Watchpack Error (watcher): Error: EACCES: permission denied, watch '/var/cache/apt/archives/partial' ....

the list goes on, I think it extends every file in wsl2 (including windows filesystem in /mnt/) At first I just moved the project dir from windows to wsl2 but then I tried to remove everything, git clone and npm install again but without success.

Are we close to figure this out?

Okay, finally fixed it. The problem is with the path as already someone said. Your project should not be located at /mnt/d/... or somewhere on your windows machine. Instead just make sure you have did this:

1. `cd ~` your path here should be like `user@user` which means `/home/user/` in linux

2. now make git clone/set up project manually

This one fixed it for me! Thank you!

The downside, though, is that PHPStorm now is complaining about the network mount, but I did not feel any big difference yet

After working a little bit more with this setup I do feel a difference, it’s not ideal. Sometimes syntax highlighting takes a long time to take effect.

PhpStorm complains that it can’t watch the files. What this might mean is that, after commands like git checkout or npm install it won’t show the latest state in the file system.

Besides that, I’m not even using WSL2 myself because cross-OS file system performance is worse. With WSL1 that’s not the case, but it also means that I can’t keep my files in \\wsl$\.... With WSL2, I would have to decide between fast npm and fast PhpStorm, but can’t have both. (Unless PhpStorm were on Ubuntu as well, as you said. Not sure if / how well that would work.)

Also running into this. My watch options are only ignoring node_modules so I’m not sure why this would be happening.