-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
[BUG] EPERM issues since v6.11.0 #476
Comments
It looks like the issue is involving a git repo dependency that has a prepare script of some kind. Can you share some details about your dependencies? I know that they're private git deps, but how are you referencing them? What are they doing? |
Hi @isaacs, thanks for the quick response. In addition to public npm registry dependencies, we have two types of private modules:
Does that answer your question? |
I think this issue is related to #286 Since v6.11 npm calls Examples: Another example is for docker. I have docker container for build and mount
|
Ok, thanks. So this isn't about prepare scripts, it's just failing to run I think the problem here is that it's mixing "folder owner uid" with "euid of child process" under the same uid/gid config param. We'll need to dig into it a bit more, because if we just roll that back, we'll be back to the state of checking out root-owned files in user-owned locations. Setting an effective uid on the spawned process does make the files default to being owned by that user, which is nice, but we should be skipping that unless the current user is root. So, it might still fail if the |
Note (for myself, mostly) that means you'll end up with files being owned by user2 in a folder owned by user1, but since the files checked out are owned by user2, then user2 should have permission to chown them over to user1. |
+1 npm 10.-12.
|
Yes, 775. I have write access to workdir. |
I believe this is also related to issue #296 . |
I am seeing similar issues too. What is strange is that if I run npm install w/ the package locks removed, npm install succeeds with 6.12.0. At that point I will have fresh package-lock files. I then wipe node_modules and re-run npm install and it fails with the EPERM error. If I roll back npm versions v10.16.2 (the version I was on previously) - no issues. |
Two questions on the above comment that I don't quite understand. (1) Why is this not seen on an |
I'm encountering this issue too in a directory created by docker (I think, it's been a while). I've fixed that by changing the group of the directory to my default user group, all runs fine now |
One example way to reproduce:
In my ubuntu environment, my default username/group might be bertrama/bertrama and I’m a member of a group cdrom. Steps for me to reproduce are: mkdir -m 2775 eperm-test
chgrp cdrom eperm-test
cd eperm-test
npm init -y
npm add left-pad@git://github.com/left-pad/left-pad I haven't tested, but you may be able to substitute |
Fix: npm/cli#476 PR-URL: #23 Credit: @isaacs Close: #23 Reviewed-by: @darcyclarke
Fixed in pacote 9.5.10, will be included in the next npm v6 release. |
Really appreciate the quick turn-around on this. Thank you. Is there any rough (and I mean rough 😄 ) estimate as to when the next release is targeted for? |
in about an hour |
Confirmed fixed! TY! |
I'm still getting this issue on NPM 6.14.4 with a container volume mount in Jenkins. Jenkins docker runs with a user that doesn't exist on the container, but the volume mounts are owned by that user, and I end up using root for unrelated reasons. NPM then fails because the owner of the dir doesn't exist. In brief, where user 11028 doesn't exist:
NPM is the only thing that ends up having this behavior. Copying the dir to a temp dir and running let's me continue with the build. |
What / Why
We recently upgraded from npm 6.0.1 to 6.12.0 and several of our engineers are encountering persistent
EPERM
issues when they runnpm install
.From all angles the folders in question have the right permissions set, and we've ruled out
nvm
as a possible reason for this failure too. No combination of uninstalling and reinstalling or cache clearing has resolved it.Whenever they run
npm install
, they get output like this:I walked back the version of npm until 6.10.3, where installs work again. The mention of
pacote
in the above logs seems suspicious when you compare it to the release notes for 6.11.0:Note that upgrading to 6.13.0 does not fix the problem.
Also note that we have some private git+ssh urls in our package.json
Where
npm public registry
How
Current Behavior
Install fails with above error output,
EPERM
Steps to Reproduce
npm i -g npm@6.11.0 && npm install
Expected Behavior
Install works as before
The text was updated successfully, but these errors were encountered: