npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

Is running npm via sudo safe?

What I Wanted to Do

Run npm install

What Happened Instead

$ npm install --save react react-dom next
Unhandled rejection Error: EACCES: permission denied, mkdir '/home/user/.npm/_cacache/index-v5/40/1e'

npm ERR! cb() never called!

npm ERR! This is an error with npm itself. Please report this error at:
npm ERR!     <>

Reproduction Steps

I have seen this error numerous times in various variations, and so have others I’ve talked to.

Many of the files in /home/user/.npm/_cacache/index-v5/* are owned by root/root after running npm under sudo, where /home/user is my Linux home directory. This means operations subsequently that don’t use sudo will fail.

I suspect this: when I updated npm as per “sudo npm update -g npm” - which is the instructions npm gives, then npm uses ${HOME} and starts writing to /home/user/.npm/_cacache without changing the ownership post facto.


0 info it worked if it ends with ok
1 verbose cli [ '/usr/bin/node',
1 verbose cli   '/usr/bin/npm',
1 verbose cli   'install',
1 verbose cli   '--save',
1 verbose cli   'react',
1 verbose cli   'react-dom',
1 verbose cli   'next' ]
2 info using npm@6.9.0
3 info using node@v11.15.0
4 verbose npm-session 478b77b89d5c5e24
5 silly install loadCurrentTree
6 silly install readLocalPackageData
7 http fetch GET 200 175ms
8 http fetch GET 200 224ms
9 silly pacote tag manifest for react-dom@latest fetched in 251ms
10 silly pacote tag manifest for next@latest fetched in 252ms
11 timing npm Completed in 1052ms
12 error cb() never called!
13 error This is an error with npm itself. Please report this error at:
14 error <>

Platform Info

All Linux platforms. I’ve seen this on, at least, Ubuntu 16 and Ubuntu 18

$ npm --versions

$ npm --versions
{ aesop: '1.0.0',
  npm: '6.9.0',
  ares: '1.15.0',
  brotli: '1.0.7',
  cldr: '34.0',
  http_parser: '2.8.0',
  icu: '63.1',
  llhttp: '1.1.1',
  modules: '67',
  napi: '4',
  nghttp2: '1.37.0',
  node: '11.15.0',
  openssl: '1.1.1b',
  tz: '2018e',
  unicode: '11.0',
  uv: '1.27.0',
  v8: '',
  zlib: '1.2.11' }

$ node -p process.platform


In answer to your title “Is running npm via sudo safe?”, the recommended best practice is to avoid using sudo with npm. (I can expand on that.)

There is an open issue with installing global packages using sudo leaving behind files with the wrong ownership.

The short version is run this to fix the ownership (assuming bash shell):

sudo chown -R $(whoami) ~/.npm

The long version and canonical bug is: Global installs (sudo npm i -g) fail on Mac after 6.5 upgrade. Works fine after 6.4.1 downgrade.

More information.

This is on a Linux platform where npm + node where installed using the method recommended here

Thank you. Your workaround (fixing the permissions) is what I’ve done all along until now that I decided to file this issue.

What’s the correct way to update npm? Whenever it’s out of date, it prints a command how to update it, which I think is npm update -g npm.

Should I sudo su - first before running this command to make sure the subsequent npm update does not use the current user’s $HOME? If so, may I suggest that npm print the correct command?

Or better, npm should avoid writing to $HOME/.npm when run under effective uid root - that would seem to be the obvious solution, but (also obviously) it’s very likely I’m missing a lot of context. It sounds too easy of a fix.

Or should I ignore the instructions to update npm if I’ve installed node using the recommended method

PS: thanks for the link to Global installs (sudo npm i -g) fail on Mac after 6.5 upgrade. Works fine after 6.4.1 downgrade. However, it’s not addressing the issue (which seems to be npm looking in the wrong directory (the home directory of the real user) instead of root’s directory when running under euid root. Changing the permissions of /usr/local/* or wherever node is installed is not an acceptable solution.

Is there a npm issue somewhere where the npm developers justify their choice of writing to a user’s home directory while running with euid 0?

I have not investigated best pattern for system global installs on a multi-user computer.

Closing this in favor of pacote #174 which accounts for this specific issue.

Having worked for large corporations, where any form of root access is often highly restricted, needing sudo to do basic development is of concern.

There are instructions on how to configure npm to use the user’s home location:

The defects I pointed out (1, 2, 3) do indeed arise only if two conditions are true

There’s a lot of advice in this forum on how to side-step these defects by having per-user installations of npm (for both global and non-global packages with a shared cache), and that’s great. Yet, according to @bthompson90 the npm team receives approximately 2 messages per day from users affected by these (and possibly other) defects.

From my perspective as a long time (though not regular) npm user, the need to make use of the -g flag has greatly diminished with the advent of npx. If my memory is correct, you used to be required to install and/or upgrade packages such as uglify-js or create-react-app globally. That said, as of today, I know of only one package that requires the use of -g (and thus the use of sudo!) under default conditions, and that is npm itself, which periodically prompts the user to upgrade using the -g switch. The command it prints (npm i -g npm) will - predictably - fail for users of the “official binary node.js distributions,” but then the instructions on suggest the use of sudo to update to the latest stable version of npm (*).

While reading through some of the open pacote issues before filing mine, I came across a comment by @zkat who (according to github) owns these repositories that “npm is really really not meant to be run as root.” As is, however, it appears that the only way to avoid running npm as root is to disregard the official instructions put out by the node.js and, in part, by the npm team.

I’m wondering if this state of affairs could be improved. A possible strategy might be the following: decide whether running npm under sudo is supported or not. If it is not, exit the program if it is run under sudo. If it is, then add unit and/or integration tests to ensure that running npm does not leave files with the wrong ownership. I note that the issues I pointed above are not Heisenbugs, but occur predictably for every user, every time.

(*) I’m referring specifically to Linux here, although the instructions on appear to suggest that users may also be affected on OS X if they “installed Node using its default installer.”