NPM Install - Rename Error on global install

[Zamerick]

Windows Build
Microsoft Windows [Version 10.0.16299.125]

Cause
Running npm install -g for any non-trivial sized package (tried with npx, vue-cli, quasar-cli and yeomen, all fail).

Problem
This appears to be the same or very similiar to #2097. This specifically affects global packages however. I've included the npm-log and what I hope is a strace of an attempt to use the command 'npm i -g npx'

NPM Error Example

npm ERR! path /home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/npx-2656e2c6/node_modules/npm/node_modules/lodash.uniq
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! syscall rename
npm ERR! Error: EACCES: permission denied, rename '/home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/npx-2656e2c6/node_modules/npm/node_modules/lodash.uniq' -> '/home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/lodash.uniq-18a4b
ed1'
npm ERR!  { Error: EACCES: permission denied, rename '/home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/npx-2656e2c6/node_modules/npm/node_modules/lodash.uniq' -> '/home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/lodash.uniq-18
a4bed1'
npm ERR!   cause:
npm ERR!    { Error: EACCES: permission denied, rename '/home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/npx-2656e2c6/node_modules/npm/node_modules/lodash.uniq' -> '/home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/lodash.uniq-
18a4bed1'
npm ERR!      errno: -13,
npm ERR!      code: 'EACCES',
npm ERR!      syscall: 'rename',
npm ERR!      path: '/home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/npx-2656e2c6/node_modules/npm/node_modules/lodash.uniq',
npm ERR!      dest: '/home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/lodash.uniq-18a4bed1' },
npm ERR!   stack: 'Error: EACCES: permission denied, rename \'/home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/npx-2656e2c6/node_modules/npm/node_modules/lodash.uniq\' -> \'/home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/loda
sh.uniq-18a4bed1\'',
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'rename',
npm ERR!   path: '/home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/npx-2656e2c6/node_modules/npm/node_modules/lodash.uniq',
npm ERR!   dest: '/home/zamerick/.nvm/versions/node/v9.3.0/lib/node_modules/.staging/lodash.uniq-18a4bed1' }
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:

strace and npm log

PS: First time using strace, so let me know if I didn't run it correctly, and I'll try again.

Edit: Updated with output from the command @therealkenc gave me.

[therealkenc]

npm ERR! Please try running this command again as root/Administrator.

I assume you've tried sudo, but you didn't mention it so I ask (pretty sure you don't need it because you're using nvm and everything is in /home). I think these rename EACCES are probably all #1529, but shrug. The strace you posted doesn't appear to be threaded. Try strace -f -o npm.strace npm [whatever]. Or post a set of repo instructions from clean install. But a full strace (assuming you can get one) is going to be nightmarish, and the "find the open handle" game is tedious.

[Zamerick]

yea, sudo does the same thing. I figured i might not have done that strace correctly since it was so huge. will do another one after work. I didnt stumble across #1529 in researching this issue, so thanks for pointing me at it :)

[therealkenc]

will do another one after work.

I don't think in this instance (considering the magnitude of 2018-01-11T02_10_29_311Z-debug.log) that you'll be faulted for skipping the threaded strace. Do it if you are feeling highly motivated, or if someone jumps in to ask, with the intent of reading it. Better to post easy to follow CLI repro step from clean install. Practically speaking, it needs to be reproduced locally. Pretend the reader is not familiar with node/npm.

[Zamerick]

Lol, thanks for assuming that it was a conscious choice to skip threading and not just inexperience. I've updated the link in the first post with a new log file, and the output from the strace command you mentioned.

Anyway, to recreate the issue with a clean install of bash:

Install NVM
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash

Reload path
source .bashrc

Install latest node
nvm install v9.4.0

reload path again.
source .bashrc

Try to install a global package.
npm i -g npx (any large package will do. NPX is just an example.)

Strangely, I've found that yarn works for installing global packages, so I at least have a work around for the moment. I find it a bit baffling that yarn doesn't run into the same issues.

[ericblade]

FWIW, Native Windows npm does the exact same thing on a ton of packages, when run on a SMB mounted file system in Windows. Sometimes it's possible to get it to complete by running it a few times, but usually it just keeps dying in the same spot. I've taken to locally installing the modules, and using robocopy to dump them over to the SMB share.

[therealkenc]

native Windows npm does the exact same thing on a ton of packages

I have a working theory about #1529. The question being, why doesn't that bug (which still hasn't gotten a serious response) take the whole WSL edifice down? I think I know why. The reason is Cygwin/MSYS2. Cygwin has been around for 23 years. What has happened, over course of those 23 years, is people have hit the same rename problem when porting their *nix packages to Cygwin/Windows (which is broken). So they "fix" it upstream, and just do whatever it takes to avoid holding a handle open. This never needs an #ifdef WIN32. The code has been changed, and works all the same on Real Linux, which doesn't care. So, in essence, WSL has been coat-tailing on 23 years of Cygwin.

I could be wrong, but it is a working theory.

[ericblade]

@therealkenc A key part of my post though, is "when run on a SMB mounted file system". Native npm works fine on a local drive, but on a network share, it fails miserably for many installations, with the same errors that are failing it in WSL.

[therealkenc]

Ref two-digit #14 which is in effect the same report. Duping #1529.

[gtim04]

2022 still experiencing this issue.

2022-05-25T19_37_12_837Z-debug.log