-
Notifications
You must be signed in to change notification settings - Fork 30k
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
Node 10, npm gives an EPERM on every operation #20112
Comments
EPERM means "permissions issue." Could be a number of things, from an overzealous virus scanner to wrong file permissions. |
My guess is wrong file permissions are set by the installer, since Node 9 (both npm 5.6 and 5.8) work as expected. File location doesn't seem to be changed between versions, and this happens consistently on multiple machines, and keeps happening even after an hour. |
I can repro the same issue easily. I tried to debug npm, but turns out this is before it even gets to running npm (as can been seen from the stack above, where it's just trying to open the npm-cli.js file to load it). I have the latest v10.x branch built locally, and stepping through the code it appears to be due to the recent libuv, which is requesting write access to any opened file. As npm (along with the rest of Node.js) is installed under You can see the change causing this here: ae2b5bc#diff-4a14951fd12c46802543f3a8aa54a620R437 . If I comment out that exact line (" This seems fundamentally busted on Windows if you can't run npm commands. (Odd/concerning if this has been in the v10.x branch for 15 days without being caught!) |
cc @nodejs/libuv @nodejs/platform-windows |
Corresponding libuv PR: libuv/libuv#1777 cc @bzoz |
Can reproduce on Windows 7 x64.
|
cc @jasnell as this can block v10 release. |
This reverts commit aa1beaa. This commit was causing EPERM errors in Node.js. Fixes: nodejs/node#20112
PR to revert the libuv commit in libuv/libuv#1800. Unless a better solution is available quickly, I'd like to land the revert and cut a new libuv release. |
@vsemozhetbyt can you PR a failing test case and mark it blocked? |
@cjihrig I am not sure. I can try, but if anybody is sure enough to make it quickly and confidently, please, do. |
It's a bit late at night for me, but I think a rough test case would involve:
I suspect the complications will be getting the right parameters to icacls, and whether access needs to be restored so that the |
Ouch. @cjihrig ... we can float a patch if a libuv update cannot be landed this week. Really need to try to get the commits locked down by end of week. |
Proposed release for tomorrow - libuv/libuv#1801. In addition to fixing this, I'd really like to get the fix for #19903 out. |
Trying also to read https://ss64.com/nt/icacls.html ... |
Strange. When I deny writing permissions for all via GUI dialog, I can run with v4-v9 and not with v10. execFileSync('icacls', [scriptName, '/deny', '*S-1-1-0:W']); I cannot run with any version ( Will investigate more if nobody will succeed sooner. |
I just wrote up the below test, and this is performing as expected for me (i.e. fails with the current bits, works after building with my fix above). I can turn this into a test-case and submit if you like. (I haven't contributed a test before, but I'm happy to give it a go). Let me know if you have any guidance on where/how this test should live, and any consideration that should be added. const os = require('os');
const fs = require('fs');
const path = require('path');
const cp = require('child_process');
if (os.type() == 'Windows_NT') {
// mymod.js should be a module in the same folder with default (inherited) permissions
const mymodPath = path.join(__dirname, "mymod.js");
// Removed any inherited ACEs, and any explicitly granted ACEs for the current user
cp.execSync(`icacls.exe "${mymodPath}" /inheritance:r /remove "%USERNAME%"`);
// Grant the current user read & execute only
cp.execSync(`icacls.exe "${mymodPath}" /grant "%USERNAME%":RX`);
// Attempt to load the module. Will fail if write access is required
const mymod = require('./mymod');
// Remove the expliclty granted rights, and reenable inheritance
cp.execSync(`icacls.exe "${mymodPath}" /remove "%USERNAME%" /inheritance:e`);
} |
cc @nodejs/testing |
Test up for review in #20116 (may want to merge this in with the fix to avoid any failing tests). |
This reverts commit aa1beaa. This commit was causing EPERM errors in Node.js. Fixes: nodejs/node#20112 PR-URL: libuv#1800 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Bartosz Sosnowski <[email protected]>
Reopening until the libuv update lands here :) |
Adds a test-case to cover loading modules the user does not have permission to write to. Covers issue logged in #20112 PR-URL: #20138 Refs: #20112 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Vse Mozhet Byt <[email protected]> Reviewed-By: Bartosz Sosnowski <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: #20129 Fixes: #20112 Fixes: #19903 Reviewed-By: Myles Borins <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Richard Lau <[email protected]>
Adds a test-case to cover loading modules the user does not have permission to write to. Covers issue logged in #20112 PR-URL: #20138 Refs: #20112 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Vse Mozhet Byt <[email protected]> Reviewed-By: Bartosz Sosnowski <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
Port test from nodejs/node#20138 to libuv. Refs: nodejs/node#20112 Refs: nodejs/node#20138
PR-URL: #20129 Fixes: #20112 Fixes: #19903 Reviewed-By: Myles Borins <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Richard Lau <[email protected]>
PR-URL: nodejs#20129 Fixes: nodejs#20112 Fixes: nodejs#19903 Reviewed-By: Myles Borins <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Richard Lau <[email protected]>
Backport-PR-URL: #24103 PR-URL: #20129 Fixes: #20112 Fixes: #19903 Reviewed-By: Myles Borins <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Richard Lau <[email protected]>
Version: v10.0.0-nightly201804175eb9f3c91c
Platform: Windows 10 64-bit and 32-bit
Subsystem: npm
Both node and npm are installed in default location, and on the path.
This works as expected in Node 9, which is why I filed an issue here.
Any npm command results in the following error on several machines:
The text was updated successfully, but these errors were encountered: