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

Already on GitHub? Sign in to your account

Mac OSX Installer messes up persmissions of ~/.npm #3821

Closed
BonsaiDen opened this Issue Aug 3, 2012 · 6 comments

Comments

Projects
None yet
5 participants

We recently got two new 10.7.4 Macs for employees and in both cases after installation, ~/.npm ended up being owned by root and had to be chown'ed manually afterwards.

On a fresh 10.7.3 Machine, this did not happen though.

I don't have tested with with 0.8.5, but since I did not see a mention of this in the release notes, I assume this might still be a problem.

isaacs commented Aug 4, 2012

That's very strange, and definitely not intended behavior. The .npm dir shouldn't even exist until the first time npm is run, and if it's being created with root ownership, then that's an npm bug.

Still a problem with 10.8.3 and node-v0.10.5.pkg

I think I have found when this problem arrises. If the first package you install uses sudo (to install globally) then ~/.npm is created and owned by root.

@francoisfrisch francoisfrisch added a commit to francoisfrisch/npm that referenced this issue Jun 1, 2013

@francoisfrisch @francoisfrisch francoisfrisch + francoisfrisch use getCacheStat before lock, fixes nodejs/node-v0.x-archive#3821
Previous code did not handle the cache dir's permissions consistently.
If the first lock was done as sudo, the cache directory was not user
writable.
7e1f7e3

@francoisfrisch francoisfrisch added a commit to francoisfrisch/npm that referenced this issue Jun 1, 2013

@francoisfrisch @francoisfrisch francoisfrisch + francoisfrisch use getCacheStat before lock, fixes nodejs/node-v0.x-archive#3821
Previous code did not handle the cache dir's permissions consistently.
If the first lock was done as sudo, the cache directory was not user
writable.
9604ee7

@francoisfrisch francoisfrisch added a commit to francoisfrisch/npm that referenced this issue Jun 3, 2013

@francoisfrisch @francoisfrisch francoisfrisch + francoisfrisch use getCacheStat before lock, fixes nodejs/node-v0.x-archive#3821
Previous code did not handle the cache dir's permissions consistently.
If the first lock was done as sudo, the cache directory was not user
writable.
Removed the now unnecessary guard and collapsed the then function.
dd9ddb5

@domenic domenic added a commit to npm/npm that referenced this issue Aug 14, 2013

@francoisfrisch @domenic francoisfrisch + domenic use getCacheStat before lock, fixes nodejs/node-v0.x-archive#3821
Previous code did not handle the cache dir's permissions consistently.
If the first lock was done as sudo, the cache directory was not user
writable.
Removed the now unnecessary guard and collapsed the then function.
7ac339c

This appears to have been fixed by npm.

(also npm issues should go to the npm/npm repo; I only keep an eye on Node issues for "fun", not for npm stuff)

Thanks, I'll keep that in mind next time I know the root cause before
filling a bug.

On Wednesday, November 19, 2014, Forrest L Norvell notifications@github.com
wrote:

(also npm issues should go to the npm/npm repo; I only keep an eye on Node
issues for "fun", not for npm stuff)


Reply to this email directly or view it on GitHub
joyent#3821 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment