Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NPM Install - Rename Error #2097

Closed
sgtoj opened this issue May 13, 2017 · 74 comments
Closed

NPM Install - Rename Error #2097

sgtoj opened this issue May 13, 2017 · 74 comments

Comments

@sgtoj
Copy link

@sgtoj sgtoj commented May 13, 2017

Windows Build

Microsoft Windows [Version 10.0.16193.1001]

Cause

Running npm install against a package.json and/or a single install (typescript or tslint).

Problem

TL;DR: Appears that #14 issue has returned.

On two different computers with the same build, npm has fails to installed packages due npm not able to moving it from node_modules/.staging/ to node_modules/. It's not limited to specific module. The real catch is, if I reboot the system and try again, the issue is resolved. In the last build, when this happen I would closed all editor windows and kill any running conhost, cmd, and bash process then retry with mostly success. Now the issue see to be more frequent and system must be rebooted to resolve.

NPM Error Example

brian@PC-Main:/mnt/c/Users/Brian/OneDrive/Development/GitHub/testdouble.js$ npm install tslint --save-dev
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.1: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm ERR! path /mnt/c/Users/Brian/OneDrive/Development/GitHub/testdouble.js/node_modules/.staging/tslint-07584f89
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! syscall rename
npm ERR! Error: EACCES: permission denied, rename '/mnt/c/Users/Brian/OneDrive/Development/GitHub/testdouble.js/node_modules/.staging/tslint-07584f89' -> '/mnt/c/Users/Brian/OneDrive/Development/GitHub/testdouble.js/node_module
s/tslint'
npm ERR!  { Error: EACCES: permission denied, rename '/mnt/c/Users/Brian/OneDrive/Development/GitHub/testdouble.js/node_modules/.staging/tslint-07584f89' -> '/mnt/c/Users/Brian/OneDrive/Development/GitHub/testdouble.js/node_mod
ules/tslint'
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'rename',
npm ERR!   path: '/mnt/c/Users/Brian/OneDrive/Development/GitHub/testdouble.js/node_modules/.staging/tslint-07584f89',
npm ERR!   dest: '/mnt/c/Users/Brian/OneDrive/Development/GitHub/testdouble.js/node_modules/tslint',
npm ERR!   parent: 'testdouble' }
npm ERR!
npm ERR! Please try running this command again as root/Administrator.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/brian/.npm/_logs/2017-05-13T00_55_06_467Z-debug.log

Strace

4.6k Line Trace

@sgtoj sgtoj changed the title NPM NPM Install - Rename Error May 13, 2017
@thorsteneb

This comment has been minimized.

Copy link

@thorsteneb thorsteneb commented May 31, 2017

@russalex Take a look, please? This is in build 15063. I've seen this happen when running an "npm install" on an actual source tree that's pulling in quite a few packages. npm will install packages, and will fail some of the way through with EACCESS during rename.
Race condition maybe, or as someone suggested, a "timeout" on forked process?

Please let me know whether you'd like an example. I can point you towards the github of the source tree that caused this in my environment.

@sgtoj

This comment has been minimized.

Copy link
Author

@sgtoj sgtoj commented May 31, 2017

Race condition maybe, or as someone suggested, a "timeout" on forked process?

My thoughts, exactly.

Although I have adjusted my development workflow to reduce the need to call npm install, I have not seen this issue occur on Build 16199. I am not sure if it is actually resolved or if I have not seen it because I am not calling npm install as often.

@sgtoj

This comment has been minimized.

Copy link
Author

@sgtoj sgtoj commented May 31, 2017

Spoke too soon. Issue occur again while running npm upgrade against package.json. Had to execute the command several times before it finished updating all the packages.

@thorsteneb

This comment has been minimized.

Copy link

@thorsteneb thorsteneb commented Jun 9, 2017

@sgtoj , this appears resolved in build 16215. Can you confirm?

@sunilmut

This comment has been minimized.

Copy link
Member

@sunilmut sunilmut commented Jun 13, 2017

Thanks for your post and sorry for the delay. I tried this on build 16215 and ended up with the message ENOENT: no such file or directory, open '/home/wsl/package.json'. That does not look like a repro of the issue. What step am I missing?

untitled

@thorsteneb

This comment has been minimized.

Copy link

@thorsteneb thorsteneb commented Jun 13, 2017

@sunilmut The issue discussed here happens when pulling in a whole bunch of packages that are part of a javascript project. You can use 'npm init' to be walked through creating a dummy package.json if you want to test just installing one package, see https://nodesource.com/blog/your-first-nodejs-package/

If you want to see 'npm install' grabbing a whole bunch of packages, you could fork a javascript project. The one I'm using for testing is at https://github.com/symposion/roll20-shaped-scripts . Fork that, clone it locally, and have at it with 'npm install' (note that this package relies on a private repo for 'npm test' to work, it's normal for 'npm test' to fail out of the box on this one).

@MrCroft

This comment has been minimized.

Copy link

@MrCroft MrCroft commented Jun 17, 2017

I can also confirm that simply closing VSCode (or whatever editor/ide one might have that working folder opened in) allows for npm install to run properly, without any errors. I didn't have to restart anything else.

But this is still a bummer... Having to close the editor means we can't use bash through the integrated terminal that VSCode offers.

Windows 10 Pro, Version 1703, Build 15063.413
Ubuntu: 16.04.2 LTS

@thorsteneb

This comment has been minimized.

Copy link

@thorsteneb thorsteneb commented Jun 30, 2017

@sunilmut I just had this happen to me again in 16232. Running 'npm install' a second time, it completed. There's definitely some form of timeout or race condition here.

@felixnorden

This comment has been minimized.

Copy link

@felixnorden felixnorden commented Aug 1, 2017

Getting this error as soon as i try to update any sort of package, or install a package which seems to have an already existing dependency installed.

I have tried the following:

  • Tried different versions of node/npm through nvm
  • Turned off third party firewall
  • Installation through curl from nodejs website
  • Clean install of WSL itself

Each time the npm update fails, npm then in return gets removed and I have to reinstall the whole node version to get npm back

npm ERR! Linux 4.4.0-43-Microsoft
npm ERR! argv "/home/felixnorden/.nvm/versions/node/v6.11.2/bin/node" "/home/felixnorden/.nvm/versions
/node/v6.11.2/bin/npm" "i" "-g" "npm@latest"
npm ERR! node v6.11.2
npm ERR! npm  v3.10.10
npm ERR! path /home/felixnorden/.nvm/versions/node/v6.11.2/lib/node_modules/.staging/sshpk-0bf1fa9c
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall rename

npm ERR! enoent ENOENT: no such file or directory, rename '/home/felixnorden/.nvm/versions/node/v6.11.
2/lib/node_modules/.staging/sshpk-0bf1fa9c' -> '/home/felixnorden/.nvm/versions/node/v6.11.2/lib/node_
modules/npm/node_modules/request/node_modules/http-signature/node_modules/sshpk'
npm ERR! enoent ENOENT: no such file or directory, rename '/home/felixnorden/.nvm/versions/node/v6.11.
2/lib/node_modules/.staging/sshpk-0bf1fa9c' -> '/home/felixnorden/.nvm/versions/node/v6.11.2/lib/node_
modules/npm/node_modules/request/node_modules/http-signature/node_modules/sshpk'
npm ERR! enoent This is most likely not a problem with npm itself
npm ERR! enoent and is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! Please include the following file with any support request:
npm ERR!     /mnt/c/Users/Felix/npm-debug.log
npm ERR! code 1
@felixnorden

This comment has been minimized.

Copy link

@felixnorden felixnorden commented Aug 1, 2017

@MrCroft The problem for me is that it happens even among the global node modules. I also tried to update the files locally in the global modules folder, as suggested by the accepted answer at stackoverflow, but it doesn't work... At least that may be a good thing, compared to the odd behavior you're experiencing with the editor/ide?

@thorsteneb

This comment has been minimized.

Copy link

@thorsteneb thorsteneb commented Aug 3, 2017

@felixnorden Have you tried this in Insider build 16251? I just tested again, opening two bash windows and running npm install on two separate projects at the same time to really stress the system - and it worked without a hitch.

Since the issue is intermittent, I think 16251 needs more testing before we can say "this appears to be fixed now."

@felixnorden

This comment has been minimized.

Copy link

@felixnorden felixnorden commented Aug 3, 2017

@yorickdowne No, I'm on build 15063.502. Maybe I'll try that and I'll get back with the results!

@thorsteneb

This comment has been minimized.

Copy link

@thorsteneb thorsteneb commented Aug 3, 2017

@felixnorden Be sure to test on a separate install / partition. Insider builds can be temperamental.

@felixnorden

This comment has been minimized.

Copy link

@felixnorden felixnorden commented Aug 3, 2017

@yorickdowne After the update things seem to be working fine. I've tried to do multiple clean installs of different node versions, updating both npm and other global packages and only did it fail once (the first time), which instead gave an ENOENT: No such file or directory, open error instead of rename, so I guess I'm safe for now. Thanks for the help!

@kaiwah

This comment has been minimized.

Copy link

@kaiwah kaiwah commented Aug 9, 2017

So I ended up having the same issue, and realized I had two conflicting NPM versions on my computer.

where npm will reveal if you have multiple npm's installed.

The cause of the issue was doing both apt install nodejs and apt install npm when in reality nodejs package already came with npm. Removing the npm and using the default npm with the nodejs package fixed it for me.

@MrCroft

This comment has been minimized.

Copy link

@MrCroft MrCroft commented Aug 9, 2017

@kaiwah wow, never tried that. Didn't realize you could have 2 versions of npm at the same time :)
To update npm I just simply run npm install -g npm - not saying that you wanted to update npm, I understood that you just didn't realize it came with nodejs.

Plus... I use nvm to manage different node versions. Not that I need multiple versions, but it makes it so easy to install node, set default version to be used (alias default) etc.
I come from windows, so... Installing stuff through command line still seems very weird for me :) actually, still on windows... Just using "bash on Ubuntu on Windows". Starting to like it.

Sent from my Samsung SM-G950F using FastHub

@kaiwah

This comment has been minimized.

Copy link

@kaiwah kaiwah commented Aug 10, 2017

@MrCroft yup! I use NVM now as well to swap between node versions. But when I first installed, I assumed apt install npm would automatically place the same bin as the one within nodejs package but it didn't -- but it definitely caused a problem. So when I tried to update npm, it was updating a different npm than the one that was used by default.

And I love WSL, but unfortunately it seems I will be going back to either Ubuntu native or GitBash as the WSL file system is too slow doubling my build times.

@bart5

This comment has been minimized.

Copy link

@bart5 bart5 commented Aug 25, 2017

I'm new to npm, so I don't know how much of a solution this is for a more experienced user, but it works for me.

The mensioned problem:

...
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! syscall rename
...

Intructions according to source:

mkdir ~/.npm-new  
npm config set prefix '~/.npm-new'  
export PATH=~/.npm-new/bin:$PATH  
source ~/.profile 

+ terminal restart

@thorsteneb

This comment has been minimized.

Copy link

@thorsteneb thorsteneb commented Aug 25, 2017

@bart5, those instructions are for installing global npm packages without the need for sudo, by pointing npm at a local user directory for global files.
I'd just as soon run sudo npm -g install

The issue discusses here is for local, not global, npm install, only happens when a large amount of packages are being installed, and appears to be some kind of timeout or race condition.

And it appears it's fixed in all the current Insider builds.

@sgtoj

This comment has been minimized.

Copy link
Author

@sgtoj sgtoj commented Sep 15, 2017

This may be resolved? I haven't had any issues for awhile.

Edit: Using Windows 10 Insider's Build 16275

@rstaveley

This comment has been minimized.

Copy link

@rstaveley rstaveley commented Oct 3, 2017

Is this likely to address a similar issue in Docker-for-Windows, running npm on a mounted volume from the host?

npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install"
npm ERR! node v6.10.3
npm ERR! npm  v3.10.10
npm ERR! path /data/node_modules/.staging/jmespath-fe653792
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! syscall rename

npm ERR! Error: EACCES: permission denied, rename '/data/node_modules/.staging/jmespath-fe653792' -> '/data/node_modules/jmespath'
npm ERR!     at destStatted (/usr/local/lib/node_modules/npm/lib/install/action/finalize.js:25:7)
npm ERR!     at /usr/local/lib/node_modules/npm/node_modules/graceful-fs/polyfills.js:264:29
npm ERR!     at FSReqWrap.oncomplete (fs.js:123:15)```
@amit-srivastava-007

This comment has been minimized.

Copy link

@amit-srivastava-007 amit-srivastava-007 commented Nov 6, 2017

I am also facing same Issue with WSL Ubuntu in Windows v1709 (build 16299.15)

`npm ERR! Linux 4.4.0-43-Microsoft
npm ERR! argv "/usr/bin/node" "/usr/bin/npm" "install"
npm ERR! node v6.11.5
npm ERR! npm v3.10.10
npm ERR! path /mnt/d/Projects/v2/ui/node_modules/leek
npm ERR! code ENOTEMPTY
npm ERR! errno -39
npm ERR! syscall rename

npm ERR! ENOTEMPTY: directory not empty, rename '/mnt/d/Projects/v2/ui/node_modules/leek' -> '/mnt/d/Projects/v2/ui/node_modules/.leek.DELETE'
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR! https://github.com/npm/npm/issues

npm ERR! Please include the following file with any support request:
npm ERR! /mnt/d/Projects/v2/ui/npm-debug.log`

@therealkenc

This comment has been minimized.

Copy link
Collaborator

@therealkenc therealkenc commented Dec 2, 2017

It looks like the original report, EACESS, was resolved some time back. 16275 was cited, so let's call it Fall Creators. There was also a tangent about having files opened elsewhere on the Win32 side (VS Code), but that's another matter. npm install in general sure works or people would have a fit; not withstanding presently open issues unrelated to the EACESS way above.

@amit-srivastava-007 & @Jefftopia - your ENOTEMPTY would be different. If you are still having difficulty, please open a new issue# and be sure to fill out the template including repro steps and an strace. Kernel programmers are not necessarily node experts so you'll need baby steps in order to get a lot of attention.

@therealkenc therealkenc closed this Dec 2, 2017
@EvanDarwin

This comment has been minimized.

Copy link

@EvanDarwin EvanDarwin commented Dec 14, 2017

I have been experiencing what I believe to be the same issue with npm. For the last month or so this issue has been infuriating me but it only occurs once in a while, and my workaround has been to use yarn from within PowerShell because that will build the node_modules/ properly, and then do npm rebuild node-sass to get the WSL/Linux bindings to work in VS Code.

However, at this point I've had to resort to rebooting Windows when I start getting EACESS in Linux, because I am also unable to modify or delete the files even in Windows as Administrator. I am almost positive that these issues have something to do with the WSL's filesystem.

  1. Moving node_modules/ in PowerShell as Admin
PS C:\Users\Eva\Documents\Code\MyCode> move .\node_modules\ old_modules
move : Access to the path 'C:\Users\Eva\Documents\Code\MyCode\node_modules\' is denied.
At line:1 char:1
+ move .\node_modules\ old_modules
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (C:\Users\Eva\Do...Z\node_modules\:DirectoryInfo) [Move-Item], IOException
    + FullyQualifiedErrorId : MoveDirectoryItemIOError,Microsoft.PowerShell.Commands.MoveItemCommand
  1. Trying to run yarn in Windows
PS C:\Users\Eva\Documents\Code\MyCode> yarn
yarn install v1.3.2
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
error An unexpected error occurred: "EPERM: operation not permitted, lstat 'C:\\Users\\Eva\\Documents\\Code\\MyCode\\node_modules\\.yarn-integrity'".
info If you think this is a bug, please open a bug report with the information provided in "C:\\Users\\Eva\\Documents\\Code\\MyCode\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
  1. Trying to run plain npm in Windows
npm WARN rollback Rolling back pure-color@1.3.0 failed (this is probably harmless): EPERM: operation not permitted, unlink 'C:\Users\Eva\Documents\Code\MyCode\node_modules\pure-color\convert\cmyk2rgb.js'
npm ERR! path C:\Users\Eva\Documents\Code\MyCode\node_modules\pure-color
npm ERR! code EPERM
npm ERR! errno -4048
npm ERR! syscall rename
npm ERR! Error: EPERM: operation not permitted, rename 'C:\Users\Eva\Documents\Code\MyCode\node_modules\pure-color' -> 'C:\Users\Eva\Documents\Code\MyCode\node_modules\.pure-color.DELETE'
npm ERR!  { Error: EPERM: operation not permitted, rename 'C:\Users\Eva\Documents\Code\MyCode\node_modules\pure-color' -> 'C:\Users\Eva\Documents\Code\MyCode\node_modules\.pure-color.DELETE'
npm ERR!   cause:
npm ERR!    { Error: EPERM: operation not permitted, rename 'C:\Users\Eva\Documents\Code\MyCode\node_modules\pure-color' -> 'C:\Users\Eva\Documents\Code\MyCode\node_modules\.pure-color.DELETE'
npm ERR!      errno: -4048,
npm ERR!      code: 'EPERM',
npm ERR!      syscall: 'rename',
npm ERR!      path: 'C:\\Users\\Eva\\Documents\\Code\\MyCode\\node_modules\\pure-color',
npm ERR!      dest: 'C:\\Users\\Eva\\Documents\\Code\\MyCode\\node_modules\\.pure-color.DELETE' },
npm ERR!   stack: 'Error: EPERM: operation not permitted, rename \'C:\\Users\\Eva\\Documents\\Code\\MyCode\\node_modules\\pure-color\' -> \'C:\\Users\\Eva\\Documents\\Code\\MyCode\\node_modules\\.pure-color.DELETE\'',
npm ERR!   errno: -4048,
npm ERR!   code: 'EPERM',
npm ERR!   syscall: 'rename',
npm ERR!   path: 'C:\\Users\\Eva\\Documents\\Code\\MyCode\\node_modules\\pure-color',
npm ERR!   dest: 'C:\\Users\\Eva\\Documents\\Code\\MyCode\\node_modules\\.pure-color.DELETE',
npm ERR!   parent: 'test-project' }
npm ERR!
npm ERR! Please try running this command again as root/Administrator.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Eva\AppData\Roaming\npm-cache\_logs\2017-12-14T22_58_22_383Z-debug.log

I was going to attach the output of WSL running npm, but I can't even get bash to give me a prompt and stop hanging, and I'm about to leave work.

I'm running Windows Version 1709 (OS Build 16299.125)

@mredbishop

This comment has been minimized.

Copy link

@mredbishop mredbishop commented Jan 26, 2018

I can also confirm that closing VSCode (the native linux one running in WSL) allows the npm install to run without error and I'm running Windows build 17074.rs_prerelease_flt.180116-1539.

Side note, mine is not a global install just a local install.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

@therealkenc therealkenc commented Jan 26, 2018

If VSCode is the blocker, then file an issue with the appropriate VSCode group.

It is not. #1956 #966 #2836 etc etc aka #1529

@angelul

This comment has been minimized.

Copy link

@angelul angelul commented Dec 18, 2018

@therealkenc I also insist, can you reopen this issue? I had the same problem.

Windows 10.0.17134.471

@thernstig

This comment has been minimized.

Copy link

@thernstig thernstig commented Dec 18, 2018

@yorickdowne @russalex since @therealkenc seems to have gone AWOL, could you please look at this? We are experiencing this even though it has been closed. And even though we have the version that is said to contain the fix.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

@therealkenc therealkenc commented Dec 18, 2018

The status of this issue has been covered already. There are three possibilities commonly observed with npm EACCES problems. (a) #1529 (b) tag linux-behavior, usually from people new to npm, and a non-zero but nevertheless epsilon probability (c) something new. If you believe you fall into category (c), then feel encouraged to open a new issue: ensuring it includes CLI repro steps that can be cut-and-paste verbatim from a clean-install into Ubuntu 18.04 on Real Linux in a VM and a clean Ubuntu 18.04 from the Store on Windows/WSL 1809, that clearly demonstrates in the strace log it isn't #1529.

[ed, clarification] I suspect it would take an issue submitter the better part of a day's effort to demonstrate theoretic (c) - because, narrowing the npm sequence to something reproducible and actionable would be a nontrivial exercise, even in the (very small but nonzero) chance it was possible to demonstrate a problem that was novel. Bonne chance.

@pitill

This comment has been minimized.

Copy link

@pitill pitill commented Jan 22, 2019

Had the same issue and made Resolving EACCES permissions.
Now, have a problem with PATH for node-sass, for example.

On WSL:
whereis node-sass
returns
node-sass: /home/username/.npm-global/bin/node-sass

On Windows it returns empty parh:
wsl whereis node-sass
returns
node-sass:

So, when i try to run script from WebStorm - WSL can't find node-sass and returns appropriate Error.

@shun-yoshida

This comment has been minimized.

Copy link

@shun-yoshida shun-yoshida commented Feb 10, 2019

I had a similar problem and resolved it by simply stepping down the heuristics setting of third-party antivirus software by a notch. Even if the files don't get quarantined it messes with file I/O enough to cause a problem it seems. I recommend those who are having the erratic behavior where repeating the same npm command will eventually let it through.

Directory white-listing should work also but I prefer not to mess with it.

@rainabba

This comment has been minimized.

Copy link

@rainabba rainabba commented Feb 11, 2019

I think that further strengthens my theory that the IO system below WSL (or below the POSIX layer?) is reporting completion prematurely. It's like write-through vs write-back cache on a storage constroller. In one case, the IO REALLY is complete and every other operation dependent on it is safe. In the other case, the calling system believes it's complete and proceeds accordingly, but ONLY the controller knows different.

This feels like the controller is claiming completion, but other systems have different visibility so they can find the IO in a state not consistent with expectations.

Put another way, it's as if IO calls are async, but the callers are assuming it's sync (to put it in JavaScript terms).

Anyhow... I'll stop with my theories now since I'm sure I can't word it any better and don't know how to test it any further :) In the meantime, thank goodness for Docker and Docker Volumes!

@hanzhangyu

This comment has been minimized.

Copy link

@hanzhangyu hanzhangyu commented Mar 24, 2019

I meet this bug too with the newest npm(6.9.0). So I tried sudo, and it works
Emmm, just try this.

where node
sudo ln /home/paul/.nvm/versions/node/v10.7.0/bin/node /usr/bin/node
where npm
sudo /home/paul/.nvm/versions/node/v10.7.0/bin/npm install -D coveralls
sudo rm /usr/bin/node

Now, It should be works.

@suprsidr

This comment has been minimized.

Copy link

@suprsidr suprsidr commented Mar 24, 2019

Giving up on WSL for now :(
Every time I get this error I have to reboot and that's not very productive.

This thread started May 2018 and the issue still persists today.

@notsoluckycharm

This comment has been minimized.

Copy link

@notsoluckycharm notsoluckycharm commented Mar 26, 2019

Just throwing a contribution in since I hit this issue myself. I had sublime text open on the directory I was attempting to install to. Adding "node_modules" to the excluded directories and no problems since. Perhaps if you've got any editors looking at the directory, close them or add node modules to the exclude list?

@Kogam22

This comment has been minimized.

Copy link

@Kogam22 Kogam22 commented Jun 25, 2019

@etamponi :
Is there a way to run npm install on WSL without closing my editor? It is kind of annoying to have to close VSCode every time I have to run npm install :(

Same issue in 2019.

@Kogam22

This comment has been minimized.

Copy link

@Kogam22 Kogam22 commented Jun 25, 2019

@suprsidr :
Giving up on WSL for now :(
Every time I get this error I have to reboot and that's not very productive.

This thread started May 2018 and the issue still persists today.

Full linux then ?

@notsoluckycharm

This comment has been minimized.

Copy link

@notsoluckycharm notsoluckycharm commented Jun 25, 2019

@Kogam22

This comment has been minimized.

Copy link

@Kogam22 Kogam22 commented Jun 25, 2019

@notsoluckycharm
Have you tried to exclude the folder from your editor? I’m replying from mobile, but does this help?

https://stackoverflow.com/questions/33258543/how-can-i-exclude-a-directory-from-visual-studio-code-explore-tab

Nope, it does not help.

How I got it to work :
Earlier, I opened VSCode- Remote WSL(via the extension button) which seems to be the cause. Now I open VSCode, and access the Linux File System through \\wsl$\home\username\ (GUI - Network tab in This PC) and the Ubuntu terminal.

@therealkenc

OS Build : 18362.175
The problem still persists.

@vlomocso-fullscale

This comment has been minimized.

Copy link

@vlomocso-fullscale vlomocso-fullscale commented Jul 9, 2019

Also here to report having the same problem with VSCode using WSL.
Any time VSCode is open with WSL an error occurs (ENOENT no such file or directory, rename...)

I've already added node_modules to file.exclude and watcher.exclude settings but the issue still occurs.
OS Build : 18362.175
VSCode : 1.36.0

@dark-swordsman

This comment has been minimized.

Copy link

@dark-swordsman dark-swordsman commented Oct 10, 2019

Just wanted to add fuel to the fire here. I have confirmed that closing VSCode works for me, but that is still not acceptable.

I don't know a ton about lower level programming, symlinks, OS programming, etc. as a lot of you seem to have, but considering that in the past with things like the Bash terminal that used MYSYS2 haven't worked properly, I am not surprised that a Windows Linux implementation still doesn't work.

Don't get me wrong, I think it's awesome that I can use my natural instinctive linux commands. Honestly the only issues I have had with WSL are that I can't do multiple tabs with CMD (MobaXterm isn't a good replacement either with the hotkeys compared to Ubuntu 18.04) and this npm issue.

However, it's obvious that this Ubuntu "subsystem" is still subject to all of Windows's woes.

It's a shame this hasn't been fixed after having multiple issues open for over 3 years, but I guess npm install is a smaller issue than others they may have to deal with.

Hopefully this gets fixed at some point. I really love being able to develop on Windows as the Ubuntu Gnome UI isn't the best in comparison, but these small headaches add up to a poor experience. I haven't been developing for long, but I know a speed bump in workflow is a serious motivation killer.

@kdolan

This comment has been minimized.

Copy link

@kdolan kdolan commented Oct 16, 2019

I solved this by mounting C:/ with default permissions bound to my user instead of root. I followed the guide here: https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/

sudo umount /mnt/c
sudo mount -t drvfs C: /mnt/c -o metadata,uid=1000,gid=1000,umask=22,fmask=111

This mounts all files on the C drive as my user instead of root. Therefore sudo is not needed to run npm i

@OneHoopyFrood

This comment has been minimized.

Copy link

@OneHoopyFrood OneHoopyFrood commented Nov 14, 2019

Still seeing this today.

@dz-s

This comment has been minimized.

Copy link

@dz-s dz-s commented Nov 14, 2019

Still having this issue

@indieocean

This comment has been minimized.

Copy link

@indieocean indieocean commented Nov 20, 2019

+1

@jared-m-combs

This comment has been minimized.

Copy link

@jared-m-combs jared-m-combs commented Nov 20, 2019

This issue occurs for me when the number of dependencies I install reaches a certain point. Its almost as if the filesystem isn't able to keep up and falls behind at a certain point. Very strange.

@markuspeloquin

This comment has been minimized.

Copy link

@markuspeloquin markuspeloquin commented Nov 24, 2019

I have this problem, and I do not use VSCode. It occurs when I npm upgrade -g npm. Installing other things (npm install -g tslint) seems to work just fine.

I use https://github.com/tj/n to manage my node install (with N_PREFIX=$HOME/.local), and the bundled npm is sometimes outdated. Beside, I just like running npm upgrade -g and everything is updated.

I don't know if it's related, but I recently ran wsl --upgrade Debian, which migrated from LxFs to WslFs. The problems started happening around when I 'upgraded'. I wish there was a --downgrade option.

@gilly3

This comment has been minimized.

Copy link

@gilly3 gilly3 commented Dec 5, 2019

This seems to be related to #4537, which in turn may be related to #1529. Neither of those are closed.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

@therealkenc therealkenc commented Dec 5, 2019

#4537 was given different treatment because it's a BSOD, and thus given some hope a minidump will make it's way though the works somehow. That the underlying problem experienced in this thread is #1529 + #1956 has been covered a few times.

The OP repro was:

$ npm install tslint --save-dev

Which you'll almost certainly find works. Hence the closed status here. This goes double for WSL2 which addresses #1529 on lxfs.

[Notwithstanding someone (paraphrasing) "taking the better part of a day's effort to narrow a test case to something reproducible and actionable, in the (very small but nonzero) chance it was possible to demonstrate a problem that was not #1529 or #1956". The caveat being largely academic, mind, at least until those two flip status.]

@gilly3

This comment has been minimized.

Copy link

@gilly3 gilly3 commented Dec 5, 2019

I appreciate the work you're doing here. I just wanted to leave a signpost for future travelers who, like me, found this issue first, and were frustrated to discover it was closed, despite the steady stream of "me too" replies. The root cause seems to be under investigation, even if this higher level issue is closed.

Upon closer inspection, I see you provided links to some potentially related issues earlier in the thread. I missed those links on my first quick read through.

@phortonssf

This comment has been minimized.

Copy link

@phortonssf phortonssf commented Jan 15, 2020

@kdolan Thank you solved my problem!

I solved this by mounting C:/ with default permissions bound to my user instead of root. I followed the guide here: https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/

sudo umount /mnt/c
sudo mount -t drvfs C: /mnt/c -o metadata,uid=1000,gid=1000,umask=22,fmask=111

This mounts all files on the C drive as my user instead of root. Therefore sudo is not needed to run npm i

@TheEssem

This comment has been minimized.

Copy link

@TheEssem TheEssem commented Jan 16, 2020

Just encountered this issue after reinstalling WSL, and none of the listed solutions seem to be working. Here's my logs:
2020-01-16T21_14_52_622Z-debug.log

@jacobopolavieja

This comment has been minimized.

Copy link

@jacobopolavieja jacobopolavieja commented Jan 17, 2020

Issue here too. Closing VSCode and redoing npm install from WSL directory went ok. Not ideal at all and I hope the team can find a solution to this. It interrupts the normal workflow with Node.

@davidcostadev

This comment has been minimized.

Copy link

@davidcostadev davidcostadev commented Jan 21, 2020

@AngelJSD

This comment has been minimized.

Copy link

@AngelJSD AngelJSD commented Jan 26, 2020

Giving up on WSL for now :(
Every time I get this error I have to reboot and that's not very productive.

This thread started May 2018 and the issue still persists today.

When I read this answer I realized that this issue only happened to me after I open VSCode from WSL. Reboot Windows worked fine for me, thanks @suprsidr. I think it could be a problem with the WSL extension of VSCode.
Note: Closing VSCode didn't work for me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.