npm EACCES: Permission Denied

Why EACCES happens

npm ultimately asks the operating system to create, modify, remove or inspect files. On Unix-like systems, the kernel evaluates the process identity against directory and file permissions. npm reports EACCES when that operation is not permitted. The same code can therefore describe several different ownership mistakes. On Unix-like systems, accessing a path also requires search permission on each directory in the path; the final directory can look writable while an inaccessible parent blocks npm. Inspect the path components as well as the named target. On Linux, namei -l /path/from/the/error displays permissions and ownership along the path; on macOS, inspect each parent directory with ls -ld.

A useful diagnosis explains all three. If a proposed fix does not explain why that particular user could not write that particular path, it is probably treating the symptom.

Fix #2 — global install prefix is not writable

This is the case covered directly by npm's official EACCES guidance: a global install such as npm install -g package fails because the global installation directory is not writable by the current user. npm recommends reinstalling Node/npm with a Node version manager as the preferred approach, or configuring npm to use a directory owned by your user.

Before changing anything, confirm that the denied path really belongs to the global prefix. A path under /usr/local/lib/node_modules, /usr/lib/node_modules or a similar system location often points here, but use npm config get prefix rather than assuming.

If a version manager is not appropriate, npm documents a user-owned prefix approach on macOS/Linux. Follow the current official instructions because shell startup files and paths differ by environment.

Verify: npm config get prefix points to the intended user-managed location, a normal global install succeeds without privilege escalation, and the installed command is available on PATH.

Fix #3 — the denied path is inside the project

If EACCES names node_modules, a generated file, build directory, lockfile or another path inside your project, changing the global npm prefix will not fix it. Inspect the project directory and its parent ownership. Common causes include a previous command that created files as another user, a container that wrote files with a different UID, an extracted archive with unexpected ownership, or a workspace copied from another environment.

Correct only the files or project tree that should actually belong to your development user. If the repository is shared, mounted, or managed by deployment tooling, confirm the intended owner first instead of changing it blindly.

Verify: the project files npm needs to modify are writable by the intended development/runtime user, a clean install no longer throws EACCES, and version-control status shows only expected dependency artifacts.

Fix #4 — npm cache or home-directory ownership is wrong

If the denied path is under your npm cache or home directory, inspect that exact directory. The important question is how files there became owned by another user. An old privileged npm run, container, restored backup or changed HOME environment can leave a user cache partially unwritable.

Do not automatically delete the entire cache. First determine whether the problem is ownership, disk state, or a different HOME/cache location than expected. If ownership is wrong, repair only the directory that should belong to that user. If a CI job intentionally uses an ephemeral cache, fix the job's user/path policy rather than hand-editing the runner after every build.

Verify: npm reports the expected cache path, the intended process user can write there, and the same install command succeeds without changing unrelated system permissions.

Fix #5 — Docker, CI or bind-mounted workspace

Inside containers and CI, usernames can be misleading because file access is governed by numeric user and group IDs plus mount permissions. A host directory owned by one UID can be mounted into a container whose process runs as another UID. Similarly, one pipeline step may create root-owned artifacts that a later non-root step cannot replace.

Fix the ownership contract where it originates: the container user, volume/mount mapping, workspace initialization, or pipeline step. Avoid adding a blanket recursive permission change to every build if the real issue is that one stage writes as the wrong user.

Verify: a fresh runner/container reproduces the corrected UID/GID and mount policy, not just a manually repaired existing workspace.

Still seeing EACCES?

Capture the first EACCES line from a fresh run and keep the path intact. If a second run fails at a different location, do not combine them into one diagnosis until you know whether the first fix changed the filesystem state.

Official references