Fix EACCES during a global npm installation
Identify the path npm cannot write, then choose a user-owned Node installation or global prefix without broadly changing system permissions.
EACCES means the operating system denied an operation. During a global npm install, the destination may be a system directory your account cannot write. Read the path in the error first: a project directory, cache, or Windows access-control rule needs a different fix from a global prefix.
Inspect the active installation
node --version
npm --version
npm config get prefix
npm config get cache
Check which Node and npm executables your shell resolves, especially if several installations coexist. On Unix, command -v node and command -v npm help identify them.
Option 1: use a Node version manager
A user-owned installation avoids the usual need to write global packages into system directories. Follow the official installation instructions for your chosen manager, inspect the installer, and load the setup for your actual shell.
For nvm-sh on a supported POSIX shell, once installed:
nvm install --lts
nvm use --lts
npm install -g typescript
The files still need correct ownership and permissions. nvm-sh also conflicts with a custom npm prefix; do not combine this option blindly with the next one. Check the nvm documentation when migrating an existing configuration. Windows version managers have their own setup and permission requirements.
Option 2: choose a writable global prefix
For a Unix installation you intend to keep:
mkdir -p "$HOME/.npm-global"
npm config set prefix "$HOME/.npm-global"
export PATH="$HOME/.npm-global/bin:$PATH"
npm install -g typescript
Put the PATH line in the appropriate shell configuration, such as .zshrc for interactive zsh or .bashrc for interactive Bash. Open a new shell or reload that specific file. Do not source a Bash file just because a tutorial uses Bash.
Repair only confirmed ownership problems
Repeated privileged installs can leave files owned by another account. Inspect the error path and npm config get cache before changing anything. If your personal cache really is $HOME/.npm and is incorrectly owned by root, a scoped POSIX repair is:
sudo chown -R "$(id -u):$(id -g)" "$HOME/.npm"
Do not apply recursive ownership changes to /usr, a shared directory, or an unverified project tree. Running package installation as an administrator also broadens the consequences of untrusted lifecycle scripts; their exact execution identity depends on npm's version and context. Avoid treating sudo npm install as the routine solution.
FAQ
Must I uninstall a system Node installation? Not necessarily. A writable prefix can be enough. If you migrate to a version manager, check PATH precedence and dependencies on the system installation before removing anything through its package manager.
Can I run a tool without installing it globally? A project dependency or npm exec/npx may suit the task. These still execute package code and may download it; they do not bypass permissions or trust requirements.
What about Windows? Inspect the reported path, ACLs, open files, and security-software logs. The POSIX prefix and ownership commands above are not Windows repair instructions.
What about a container? A non-root user may not own the global prefix. Set a writable prefix and PATH, or install required tooling during the image build and run the application with the intended restricted user.
Related reading
References
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan