Solved it be adding --unsafe-perm.

In my case with sails:

sudo npm install --unsafe-perm --verbose -g sails

Works well!

If I remember correctly, set unsafe-perm to true when running as sudo is a fix it’s obstructing.

The issue here is that npm normally drops privileges when run as root (e.g. through sudo) before executing node-gyp. As a result, node-gyp may not have access to the the directory containing the node sources. It then logs that warning and tries to soldier on but as often as not, it’ll fail.

--unsafe-perm runs everything as root, including all package pre- and post-install scripts. It probably “fixes” the issue in most cases but I don’t really recommend it, it’s better to not run npm as root.

Closing, not a bug, just a quirk.

why should I set 'unsafe-perm ’ =true ,what’s the meaning of “unsafe-perm”?

Try sudo npm install -g PackageName --allow-root

Hi everyone, This guide fixed the problem for me perfectly. https://github.com/sindresorhus/guides/blob/master/npm-global-without-sudo.md

I will copy the text here for future reference

Install npm packages globally without sudo on OS X and Linux

npm installs packages locally within your projects by default. You can also install packages globally (e.g. npm install -g <package>) (useful for command-line apps). However the downside of this is that you need to be root (or use sudo) to be able to install globally.

Here is a way to install packages globally for a given user.

1. Create a directory for your global packages

mkdir "${HOME}/.npm-packages"

2. Reference this directory for future usage in your .bashrc/.zshrc:

NPM_PACKAGES="${HOME}/.npm-packages"

3. Indicate to npm where to store your globally installed package. In your $HOME/.npmrc file add:

prefix=${HOME}/.npm-packages

4. Ensure node will find them. Add the following to your .bashrc/.zshrc:

NODE_PATH="$NPM_PACKAGES/lib/node_modules:$NODE_PATH"

5. Ensure you’ll find installed binaries and man pages. Add the following to your .bashrc/.zshrc:

PATH="$NPM_PACKAGES/bin:$PATH"
# Unset manpath so we can inherit from /etc/manpath via the `manpath`
# command
unset MANPATH # delete if you already modified MANPATH elsewhere in your config
MANPATH="$NPM_PACKAGES/share/man:$(manpath)"

Check out npm-g_nosudo for doing the above steps automagically

NOTE: If you are running OS X, the .bashrc file may not yet exist, and the terminal will be obtaining its environment parameters from another file, such as .profile or .bash_profile. These files also reside in the user’s home folder. In this case, simply adding the following line to them will instruct Terminal to also load the .bashrc file:

source ~/.bashrc

---

See also: npm’s documentation on “Fixing npm permissions”.

–unsafe-perm works Ach Linux

How come this is still an outstanding issue? Why is gyp even used by NPM if it’s this broken with no clear solution? I’ve seen people recommend rm -rf ~/tmp and using --unsafe-perm but those haven’t made a difference for me on my CentOS server.

Doesn’t look like the project maintainer cares much about this issue

Let me rephrase: if it doesn’t work without root, chances are you are doing something wrong.

If npm install -g in your case means ‘install to /usr/local’, ask yourself why /usr/local and not your home directory. Node, npm and node-gyp don’t mandate that packages are installed system-wide.

If sitespeed.io does, that’s a bug in that package, but you are in the wrong bug tracker in that case.

Hi there. I’ve solved those terrible issue for my

# cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"

with this:

yum groupinstall 'Development Tools'
npm i --unsafe-perm

Hope this helps.

Thanks for the explanation about root & nobody; that wasn’t clear in the output and it explains the problem. I worked around it by temporarily clowning the (in my case) $HOME/.node-gyp/6.1.0 to nobody, and that let the install/compile proceed.

I agree that running with --unsafe-perm is not advisable, and thus I would not consider that a valid workaround.

It seems like, if it’s going to drop privs to “nobody” before continuing, it should probably, before it drops privs, set up a directory that it knows it will be able to write to – rather than dropping privs and then trying to write to a directory it almost certainly won’t be able to write to as “nobody” (a dir under $HOME or /usr/local, in my case).

Could it not “mkdir /tmp/whatever; chown nobody /tmp/whatever” and then proceed with the build using that directory?

FWIW - sudo npm install --unsafe-perm solved this problem for me as well on Ubuntu 14.04, Node 0.10.24.

I recommend just using nvm

1️⃣ Install with a line of code 2️⃣ Use

$ nvm ls
$ nvm ls-remote
$ nvm install
$ nvm use
$ nvm exec

✅ Enjoy your life 😉

For anyone else coming across this thread, I recommend just using nvm, which avoids these issues. Using --unsafe-perm (running random module install scripts as root) is a pretty terrible idea.

---

Well, I tried option 2 with the custom path / directory and it did not fix the issue.

A global modules directory that is owned by the user (not by root) is the default for every install method that isn’t a Linux package manager, and it works fine.

npm always reset the directory

Unless you’re still running with sudo npm then I’ve never known it do that. Difficult to debug without more info though.

For me: rm -rf /root/.node-gyp/ npm install --unsafe-perm --verbose -g <package-name> Solved my problem.

And before that, I deleted node_modules and reinstalled Node.js.

I had this problem because of using sudo. Works if you first change to the root user : as normal user $: su root#: npm install …

After removing /root/.node-gyp, sudo npm install --unsafe-perm --verbose -g solved this problem