NPM Install - Rename Error

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<EMAIL_ADDRESS>(node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>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!  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.

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.

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.

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

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?

@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).

I can also confirm that simply closing VSCode (or whatever editor 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.
Windows 10 Pro, Version 1703, Build 15063.413
Ubuntu: 16.04.2 LTS

@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.

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

I get the rename error if I have the project opened in the ide (either storm or vscode, it makes no difference) while running npm install under bash. Once I realized, I always close the editor before runing npm install. Haven't had any npm install rename errors since. Although, I don't see this as "normal behavior" of course - to close the editor before any npm install/update. And if having the project opened in the ide would pose a problem, why not on any file write? I have no idea what's up with that...
Sent from my Samsung SM-G950F using FastHub

@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 [here on stackoverlow], but it doesn't work...(https://stackoverflow.com/questions/9755841/how-can-i-change-the-version-of-npm-using-nvm) At least that may be a good thing, compared to the odd behavior you're experiencing with the editor/ide?

@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."

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

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

@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 instead of rename, so I guess I'm safe for now. Thanks for the help!

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.

@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/npm 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

@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.

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

@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.

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

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)```

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
`

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.

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.

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

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.

Trying to run plain npm in Windows

npm WARN rollback Rolling back<EMAIL_ADDRESS>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!      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)

Don't expect VSCode team to fix this issues anytime soon, it has been almost a full year of people asking for a simple feature ( horizontal scroll in project tree) and nothing was done.

Similar issues also happens when other IDEs are open on directories being used by bash's proccesses (e.g. npm), this is more certainly an issue with Bash/Windows integration than the IDEs themselves.

Similar issues also happens when other IDEs are open on directories being used by bash's proccesses (e.g. npm), this is more certainly an issue with Bash/Windows integration than the IDEs themselves.

Closing Vscode didn't solve the problem, I gave proper permission, cleaned npm cache, followed all possible work arounds, still issue remains

Hey all.
Had this exact same issue... tried many workarounds to no avail.
Ended up doing a "sudo npm install  -g" and it worked.
Cheers!

Ended up doing a "sudo npm install -g" and it worked.

That scenario is Linux behaviour.

celiyah@L-201447:~/Code/connect-dashboard$ sudo npm install -g npm
npm ERR! path /usr/lib/node_modules/.staging/npm-18aca6f9/node_modules/pacote/node_modules/make-fetch-happen/node_modules/socks-proxy-agent/node_modules/socks
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! syscall rename
npm ERR! Error: EACCES: permission denied, rename '/usr/lib/node_modules/.staging/npm-18aca6f9/node_modules/pacote/node_modules/make-fetch-happen/node_modules/socks-proxy-agent/node_modules/socks' -> '/usr/lib/node_modules/.staging/socks-ad028db0'
npm ERR!  { Error: EACCES: permission denied, rename '/usr/lib/node_modules/.staging/npm-18aca6f9/node_modules/pacote/node_modules/make-fetch-happen/node_modules/socks-proxy-agent/node_modules/socks' -> '/usr/lib/node_modules/.staging/socks-ad028db0'
npm ERR!   cause:
npm ERR!    { Error: EACCES: permission denied, rename '/usr/lib/node_modules/.staging/npm-18aca6f9/node_modules/pacote/node_modules/make-fetch-happen/node_modules/socks-proxy-agent/node_modules/socks' -> '/usr/lib/node_modules/.staging/socks-ad028db0'
npm ERR!      errno: -13,
npm ERR!      code: 'EACCES',
npm ERR!      syscall: 'rename',
npm ERR!      path: '/usr/lib/node_modules/.staging/npm-18aca6f9/node_modules/pacote/node_modules/make-fetch-happen/node_modules/socks-proxy-agent/node_modules/socks',
npm ERR!      dest: '/usr/lib/node_modules/.staging/socks-ad028db0' },
npm ERR!   stack: 'Error: EACCES: permission denied, rename \'/usr/lib/node_modules/.staging/npm-18aca6f9/node_modules/pacote/node_modules/make-fetch-happen/node_modules/socks-proxy-agent/node_modules/socks\' -> \'/usr/lib/node_modules/.staging/socks-ad028db0\'',
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'rename',
npm ERR!   path: '/usr/lib/node_modules/.staging/npm-18aca6f9/node_modules/pacote/node_modules/make-fetch-happen/node_modules/socks-proxy-agent/node_modules/socks',
npm ERR!   dest: '/usr/lib/node_modules/.staging/socks-ad028db0' }
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/celiyah/.npm/_logs/2018-05-15T22_43_41_874Z-debug.log
celiyah@L-201447:~/Code/connect-dashboard$ node --version
v10.1.0
celiyah@L-201447:~/Code/connect-dashboard$ npm --version
5.6.0

ah! it works on reboot with sudo (yes the command above had sudo, but no reboot)

quoth: from two-digit #14 that was closed but remains unaddressed:

Y'all have been rebooting and discovering "works fine now", because you've closed all the handles.

I was not able to fix this problem with any of the above solutions (unsafe-perm, prefix, etc.). I do believe the issue is with open filehandles.
I installed yarn and it worked straight away.

I found a temporary solution that worked for me. Is to close all open folders with directory in which node_modules is being present and all editors (Idea, VS Code etc.). Then just run bash.exe and npm i.

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 :(

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 :(

@etamponi  you can set vscode to use bash with its terminal. Is that what you're looking for? You shouldn't need to close your editor to run a bash command, that would be super annoying.

Thanks for your reply, but I was referring to the fact that npm install
fails to run if vscode is running, open on the same directory on which I am
running npm install.
Apparently it's a limitation caused by NTFS, but it sounds a bit strange to
me.
Il sab 22 set 2018, 22:33 PelagicSoft<EMAIL_ADDRESS>ha scritto:

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 :(
@etamponi https://github.com/etamponi you can set vscode to use bash
with its terminal
https://code.visualstudio.com/docs/editor/integrated-terminal. Is that
what you're looking for? You shouldn't need to close your editor to run a
bash command, that would be super annoying.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/WSL/issues/2097#issuecomment-423771297, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAjUNE10Xdb1BwoQOK2tsOY_4fzYb1QXks5udp6JgaJpZM4NZ6sQ
.

@etamponi that makes more sense. I ended up doing the same as @codinguncut  and just switched to yarn for now.

Running sudo npm install as a non-root user solves my issue.

RE: rstaveley  Agreed entirely. Here's what I've seen (and apparently I provided this info on the wrong issue a couple weeks ago, because it was meant to be here)...
Using Windows 1803 and Ubuntu 18.04, Docker for Windows on host, Docker CE in WSL...
If I npm install or yarn install in WSL, I get random failures indicating files should exist, but don't, can't be deleted, or can't be renamed. Each run might have none or die quickly.
If I then bind a host folder into my Docker container using a properly setup / root (wsl.conf) so that my path in wsl is /c/foobar and c:\foobar exists, then I CAN get proper 2-way binding inside my container, but I see the exact same failures when I run yarn install or npm install inside my container.
If COPY my contents in (rather than binding, which I do for develpment) OR I just cp package.json /tmp/ && cd /tmp && yarn install inside my container (/tmp isn't bound, it's ENTIRELY inside the container), then it succeeds.
As I understand it, that 3rd scenario makes sense because it doesn't actually involve WSL at all (Docker for Windows is on Windows and runs there with no user of WSL). When I bind though, WSL IO is involved because the path translations and such have to be involved given my my app doesn't know anything about the host, just the most immediate filesystem (WSL) which then has to be translated back to WIndows.
Can anyone confirm this observation or provide any info that would bust this theory?

I've got another behavior/observation that further strengthens my theory about rapid/lagged I/O. My Node.js app (running in WSL directly, or in Docker via a folder-bind, but NOT if it's running inside Docker storage) regularly has I/O errors (files not found, files can't be deleted/moved/renamed). I've been building node-cloudfs-drive for a few months and have discovered that Google has offloaded handling of their touchy API (touchy in terms queuing/quota/load) and so I've had to add throttling/retries and it occurred to me to test my IO theory by wrapping my I/O calls with the same retry library.
The result is no more unexpected I/O errors. What there is gets handled by retry transparently and never fails the retries, so I don't see the errors. This is exactly what my theory predicted.
To me it appears that WSL is telling services that I/O is handled, but it is not in reality. It feels like a failing, write-back cache, but it's never far from being available (I suspect ms, but haven't tested down below 50ms for my retries), more of a phase-difference :)

I do encounter this issue as well from time to time, it happens often with large node_modules folders. The only thing that helps for me is to remove the folder entirely and run npm install again. This is quite a hassle as it makes installation unpredictable.

@therealkenc you closed this issue citing it was fixed in 16275. I've got 16299.785 and the problem still persists when trying to install with npm under /home/users/test on Ubuntu 16.04.

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

@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.

The status of this issue has been covered already. There are three possibilities commonly observed with npm EACESS 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 on 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. I suspect it would take the better part of a day's effort to demonstrate (c). Bonne chance.

I had a similar problem and resolved it by simply stepping down the heuristics setting a 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.

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 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!

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

Now, It should be works.

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.

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?

@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.

@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 ?

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
On Tue, Jun 25, 2019 at 8:53 AM Yahyaa Abdullah<EMAIL_ADDRESS>wrote:

@suprsidr https://github.com/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 ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/WSL/issues/2097?email_source=notifications&email_token=AAEUYPKTPA6FYGZDE2QYKSTP4IIONA5CNFSM4DLHVMIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYQEH7A#issuecomment-505431036,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEUYPJD62QCAPT6ZAY4RG3P4IIONANCNFSM4DLHVMIA
.

@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.

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

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 and 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 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

Still seeing this today.

Still having this issue

+1

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.

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.

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

#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.]

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.

This issue still exists for me.

The cause of the issue for me was having a out of date package installed, in the package.json.
So, likely you've broken your npm by trying to fix your issue, so follow the below; worked for me.

close all editors
2)reboot vscode command: >Reload Window.
3)In the directory you are in , install a clean node.js:
https://nodesource.com/blog/installing-node-js-tutorial-using-nvm-on-mac-os-x-and-ubuntu/
check: whereis npm --> to see if duplicate versions are installed.
sudo chown -R $USER:$(id -gn $USER) /home/adduser/.config
Reinstall the latest versions of your package.json -- The cause of the issue for me was having a out of date package installed.

same here. freshly installed windows 10 (build 18363), node 12 installation using nvm, just rebooted, vsc is not started, trying to install latest npm - getting the same error.
I've never started anything related to node with sudo or as root, I am not installing it on a mounted drive, but in my users home directory - so nether symlinks nor access rights should be an issue. out of ideas..

FWIW: Working in Docker (from WSL) largely solves these issues and is good practice for any number of reasons so perhaps that's a workaround that may make sense for you also? WSL went from unusable to more-than-sufficient. Also, working directly with the FS in WSL is slow while Docker runs in Windows-proper so it's FAR faster (especially for npm i).

My colleague was having the same "rename error eacess" errors, but we found that he has been using a Ubuntu 16.04 WSL version. After uninstalling it and installing Ubuntu 18.04 WSL version, the problem ceased.
The command which originated the issue was yarn eslint --init.

In my case I was having 2 npm versions installed. One version was installed on WSL , another one on Windows. After removing Windows version I`ve got no errors yet..

I'm having the same issue on WSL 2, the project folder is in my home directory, not a mounted NTFS partition.

One thing you might want to try is disable the vscode's file watcher on node_modules.
We have an older project that still uses gulp and part of the gulp serve:dev command was to rm -rf ./dist
since vscode was watching ./dist it failed
something like:
files.watcherExclude": {
	"**/dist/**": true,
	"**/shared/**": true,
	"**/.git/objects/**": true,
	"**/.git/subtree-cache/**": true,
	"**/node_modules/**": true
}

WSL v1, Win 10 (1909) build 18363.778, Ubuntu 18.04
I had a clean system and updated node from default 8 to 12.x with apt as described in the official instructions. Then I got many errors like almost for every package:
npm WARN tar ENOENT: no such file or directory, open '<...>/node_modules/.staging/rxjs-c9f024ea/_esm2015/internal/operators/windowToggle.js'

Tried to close VS Code and use just a console - no immediate success.
The thing that helped was apt autoremove, which removed a bunch of node dependencies left after the previous (default) installation:
 gyp libc-ares2 libhttp-parser2.7.1 libjs-async libjs-inherits libjs-node-uuid libjs-underscore libssl1.0-dev libuv1  libuv1-dev node-abbrev node-ansi node-ansi-color-table node-archy node-async node-balanced-match node-block-stream node-brace-expansion node-builtin-modules node-combined-stream node-concat-map node-cookie-jar node-delayed-stream node-forever-agent node-form-data node-fs.realpath node-fstream node-fstream-ignore node-github-url-from-git  node-glob node-graceful-fs node-gyp node-hosted-git-info node-inflight node-inherits node-ini node-is-builtin-module  node-isexe node-json-stringify-safe node-lockfile node-lru-cache node-mime node-minimatch node-mkdirp  node-mute-stream node-node-uuid node-nopt node-normalize-package-data node-npmlog node-once node-osenv  node-path-is-absolute node-pseudomap node-qs node-read node-read-package-json node-request node-retry node-rimraf  node-semver node-sha node-slide node-spdx-correct node-spdx-expression-parse node-spdx-license-ids node-tar  node-tunnel-agent node-underscore node-validate-npm-package-license node-which node-wrappy node-yallist

For me, the following 2 solutions worked -

Run Powershell/CMD or whatever terminal you use as an Administrator.
Or follow the instructions here - https://www.turek.dev/post/fix-wsl-file-permissions/

Turn on file polling in VSCode or use WSL 2.
https://code.visualstudio.com/docs/remote/wsl#_i-see-eaccess-permission-denied-error-trying-to-rename-a-folder-in-the-open-workspace

@therealkenc Still having exactly this issue and many others are too. Any reason this isn't in your backlog?

Still having exactly this issue

No yer not. The exact - issue would be:
brian@PC-Main:/mnt/c/Users/Brian/OneDrive/Development/GitHub/testdouble.js$ npm install tslint --save-dev

It does not EACCES.

Your inexact issue is #1529 #1956 et al.


Refresh proxy list from webshare every 20 minutes

Contribution
I've created a python script to make things easiers for users who have their WebShare proxy list refresh periodically. The script periodically downloads a user's proxy list from WebShare every 20 minutes to config/proxies.txt and reformats each proxy address to username:password@ip:host form. Any feedback would be appreciated :)

WebShare Proxy List API
In your WebShare dashboard, click Download Proxy List

Then, copy the Proxy List API URL:

Setup

🔧 Below is the setup process for the proxy-refresh.py file.

Change the url variable here to your WebShare Proxy List API url:
def get_proxies():
    dir_path = os.path.dirname(os.path.realpath(__file__))
    url = 'your-webshare-url'
    filename = dir_path + '/' + 'config' + '/' + 'proxies.txt'

Adjust the regex pattern using the username and password values from your WebShare dashboard:
pattern = re.compile("(^.*)(:)(username:password)")

If you'd like to adjust the scheduling interval, you can do so by changing 20 to some other value here:
schedule.every(20).minutes.do(get_proxies)
while 1:
    schedule.run_pending()
    time.sleep(1)

Run Script
Finally, you can run the script using the following command:
> python3 proxy-refresh.py

💡  Congratulations! Your proxy list will automatically refresh every 20 minutes.

Hey @alif-munim, thanks for your contribution!
Sorry for the super late feedback. Excuse my ignorance, but doesn't Webshare allow you to use a rotating proxy that essentially fixes the issue you're trying to solve. They provide you with one proxy endpoint which assigns a random IP address from your proxy list. Plus, it gives you the option to rotate and refresh that proxy list. You can simply place that one proxy endpoint in config/proxies.txt.