Repository navigation
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/...' #187
Description
Activity
Can you provide structure of your project?
@Philipp91 Yep, please try to provide, and I will investigate this problem, I think something wrong in plugins/loaders/webpack-dev-server, because we are warning
/mnt/and it should not happens# Use WSL 1 cd /mnt/c/Users/.... mkdir watchpack-reproduce cd watchpack-reproduce npm init -y && npm install webpack webpack-cli --save-dev mkdir src echo Test > index.html echo 'console.log(window)' > src/index.js NODE_ENV=development webpack --watch --watch-options-stdin # Now the 4 errors posted above appear.compilation.fileDependenciescontains:[ '/mnt/c/Users/Philipp/repos/watchpack-reproduce/package.json', '/mnt/c/Users/Philipp/repos/watchpack-reproduce/src', '/mnt/c/Users/Philipp/repos/watchpack-reproduce/src/index.js', '/mnt/c/Users/Philipp/repos/watchpack-reproduce', '/mnt/c/Users/Philipp/repos', '/mnt/c/Users/Philipp', '/mnt/c/Users', '/mnt/c', '/mnt', '/' ]This may be a new behavior in webpack v5. Is it okay for webpack to tell watchpack to watch all those directories up to the root?
What is
cwdwhen you runNODE_ENV=development webpack --watch --watch-options-stdin?It's
/mnt/c/Users/Philipp/repos/watchpack-reproduce, I ran it quite exactly as posted above.It's normal that these directories are watched. The relevant entry is
/mnt/c/Userswhich is watched because theUsersdirectory 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
Usersdirectory. It would probably make sense to ignore them internally until these files are actually watched.Reacted by Stefan "Bebbo" Franke, Matthew D. Scholefield, gnubyte, Emman Ruaza, Bohdan Yurov, Leonardo Wijaya and Slava DobromyslovOkay that makes sense. I find it a bit complex to implement due to the series of
DirectoryWatcherinstances. Now the instance withpath="/mnt/c"needs to know that it should suppress all (?) kinds of errors for all (?) files except the/mnt/c/Userssubdirectory (which this particular watcher instance doesn't know about, or at least doesn't that it's special).which this particular watcher instance doesn't know about
Each instances knows which files are watched on this instance. So there is a
/mnt/cinstance where onlyUsersis watched. Suppressing the warnings is probably the easy part. More tricky is that someone might start watchinghiberfil.sysat a later time. In this case we need to show the warning at this later time.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 someconsole.logs sure enough WatchPack was trying tolstatthat 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.
Reacted by Osher El-Netanany, William, Andrew Kessinger and scourgetheoneWhat terminal do you use? I have Windows and I am having the same issue with wsl. Try to use cmd instead. It worked for me. Good luck.
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.
Reacted by Caleb Faruki, Bianca Medeiros, Grzegorz Domaradzki, Meryem Yanar, Ilham Wahabi, roblframpton, Brent, Adrian Ulloa, chaud, Aleksandr Hovhannisyan and 16 moreAlso running into this. My watch options are only ignoring node_modules so I'm not sure why this would be happening.
Reacted by Osher El-NetananyPlus 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'Reacted by Mohammad Ebrahimi Aval, Ffatheranderson, Daniel Tamkin, César Vargas Escorcia, Morgan Leininger, Jacob Byers, Elaine Shannon, Codi Huston, aplotor, Meotimdihia and 19 more69 remaining items
This is still happening in latest next js 13.4
Just for completeness' sake, since most people seem to have this problem on Windows, I got it on Mac.
System: MacOS Ventura Version 13.4.1
Node: v18.16.0Watchpack Error (watcher): Error: EACCES: permission denied, watch '/Volumes/code/.fseventsd' Watchpack Error (initial scan): Error: EACCES: permission denied, scandir '/Volumes/code/.fseventsd'
The project(s) are in a
/Volumes/code/PROJECT_FOLDER.Interestingly enough: The problem doesn't occur when I copy the project to my main volume. So since many WSL users have it, might it be related to running on a different volume then the user?
Hi @essenmitsosse I'm using a different volume too on MacOS,
/Volumes/codeand I get the same error as you.
I haven't tried out putting it on my main volume yet, but thanks for the heads up!For those who have the same error on an angular project, might be worth loking at this answer. it fixed my project that has been given me headaches since the start of this post
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); } } }); } ...
Where did you put this code tho? Thanks
Hi @irisma00! you can add this code directly in the "plugins" attribute of your webpack.config.js like so:
// Example webpack.config.js file module.exports = { entry: { app: "./src/index.js", }, ... plugins: [ { apply: function(compiler) { const lookupSet = new Set(["/", "/data", "/data/data"]) // Those EACCES directories compiler.hooks.done.tap("WatchpackBugWorkaroundPlugin", (stats) => { for (const item of stats.compilation.fileDependencies) { if (lookupSet.has(item)) { console.log( "[WatchpackBugWorkaroundPlugin] remove inaccessible fileDependency", item ) stats.compilation.fileDependencies.delete(item) } } }) } }, ],
Replace the file paths in
const lookupSet = new Set(["/", "/data", "/data/data"])with the actual file paths where you see theEACCES: permission denied..."logs when you run webpack/webpack-dev-server. So for example, if you seeWatchpack Error (watcher): Error: EACCES: permission denied, watch '/var/www'in the output of your webpack command, then add"/var/www"to the lookupSet of the custom plugin we made above.I don't understand Webpack enough to judge if @liujingbreak's code does the job, perhaps those who try out this hack can test it out together.
Update: I tested out the code, and it works: it removes the chosen directories from being watched. I tested that it works as intended using 2 ways. First, I deliberately added the path to a source file in my project in the
lookupSet, ranwebpack-dev-server, made some changes in said file, and saw that the dev server did not recompile/reload at all! The second way I was able to verify, is by running the following command to get the list of files being watched by webpack usingstrace(note: this command works only on Linux):strace -fe inotify_add_watch ./node_modules/.bin/webpack-dev-server --mode development 2>&1 | sed -u "s#$(pwd)#.#g" | grep -o --line-buffered '".*"' | tr -d '"'
Source: https://hassansin.github.io/Finding-out-Which-Files-Are-Watched-by-Webpack-Using-Strace
I also tweaked our hack plugin abit to only include files from my project's UI source code folder:
apply: function (compiler) { const sourceCodeDirectory = path.resolve(__dirname, "src") compiler.hooks.done.tap( "WatchpackBugWorkaroundPlugin", (stats) => { for (const item of stats.compilation.fileDependencies) { if (!item.includes(sourceCodeDirectory)) { stats.compilation.fileDependencies.delete(item)
So this hack plugin works as intended! Now I no longer need to worry about webpack watching unrelated files outside my project folder whichexausts the system's
fs.inotify.max_user_watcheslimit thus preventing recompile/live-reload when it's actually needed like my source code changes.P.s: I have this issue on both Ubuntu server 22.04 and Termux on Android. The testing of the hack plugin was only done on Termux on Android.
I have the same on Linux, with Docosaurus, which uses webpack underneath. My project is in
/home/cumpsd/...., a regular folder, but when I start it I get the following:Watchpack Error (initial scan): Error: ENODEV: no such device, lstat '/efi'It makes no sense why this would try to touch
/efiI'm trying to find out how I can apply the above Hack plugin, but since webpack is hidden from me in this case, it's a whole lot harder
Reacted by Bertrand Bordage and The LouieSince Node 22.17.0 I have similar problem on Windows 11 24H2 in React project, webpack version is 5.93, watchpack 2.4.1, checked with Node 22.17.0/22.17.1/22.19.0:
Watchpack Error (initial scan): Error: EINVAL: invalid argument, lstat 'C:\DumpStack.log.tmp'
Watchpack Error (initial scan): Error: EINVAL: invalid argument, lstat 'C:\hiberfil.sys'
Watchpack Error (initial scan): Error: EINVAL: invalid argument, lstat 'C:\pagefile.sys'
Watchpack Error (initial scan): Error: EINVAL: invalid argument, lstat 'C:\swapfile.sys'Despite this, build finishes and app starts properly. There are no such errors if Node 22.16.0 is been used. Also, there is a thread in Angular repo on this error, where people say that the problem is reproduced only if elevated terminal window is been used.
Reacted by Eli BlackI started noticing the same warnings as @UncleJart (
EINVAL) a few days ago. Not sure what changed. I'm using bare Windows (no WSL), and I've never seen theEACCESversion of the error.The project continues to work fine, though -- as mentioned elsewhere in this thread, this seems to indeed just be a warning :)
I run
webpack --watch --watch-options-stdin ...and amidst its initial build (not the subsequent builds triggered by changed files), it prints:Someone already reported the problem here, so I'll refer to those details for reproduction. Key elements are webpack v5 and WSL1 under Windows.
The directory
/mnt/cmaps to the Windows root driveC:\, which contains these special files like the swapfile, to which the user doesn't have access. That is, the commandls /mnt/cfails on the command line too. So it's not surprising that it fails for watchpack too.What is surprising (to me) is that watchpack attempts to list that directory to begin with. I have no config telling webpack/watchpack what to watch, only that
--watchflag. Can someone explain this to me?