To fix an EACCES: permission denied error on your Mac, start with the exact path and operation in the error. Check whether your account should be able to read, write, or run that item, then correct only the access it actually needs.
If the error happens during a global npm installation, npm recommends a Node version manager. Its other documented option is a global installation directory inside your home folder.
I would work through the checks below in order. They help you separate a project-folder problem from npm configuration, macOS app privacy, and protected system files without changing permissions across your Mac.
Key takeaways
- Read the complete error, especially
pathandsyscall, before changing anything. - Work in a project or output folder you own. An administrator account does not make every folder writable.
- Use Finder’s Sharing & Permissions for a specific personal file or folder when its access is wrong.
- For npm global-install errors, choose a Node version manager or a user-owned npm prefix. Keep those approaches separate.
- Avoid blanket permission changes, recursive ownership resets, and running package installations with elevated privileges as a quick fix.
- Disk Utility First Aid checks filesystem problems. It is not a general reset for file permissions or an app’s privacy access.
What does EACCES: permission denied mean?
Node.js defines EACCES as a file-access attempt that the file’s permissions do not allow. It tells you that an operation was refused, but the words alone do not identify which setting needs attention.
Here is an illustrative error, not output from a test:
Error: EACCES: permission denied, open '/Users/you/Projects/example/report.json'The useful clues are the operation, such as open, and the path. Node error objects can also include code, syscall, and path fields. Keep those details when you troubleshoot.
An open failure calls for checking the file and the access the app requested. With mkdir, check the folder where the new directory would be created. With rename or unlink, check the containing folders and the exact source or destination. Apple’s archived references for rename and unlink explain the related directory-access requirements.
If your error concerns a network operation rather than a file path, use that application’s networking guidance. Changing document permissions will not address the wrong kind of failure.
1. Check the path, account, and containing folder
First, confirm that the path is where you intended the program to work. A misspelled output location or a terminal opened in the wrong folder can send a perfectly reasonable command somewhere you cannot write.
These optional Terminal commands only display your current directory and account name:
pwd
id -unYou can inspect a particular item with ls -ld. In this example, replace the quoted sample path with the real file or folder from your error before running it:
ls -ld "/Users/you/Projects/example"The listing shows the item’s permission bits, owner, and group. It is a useful clue, although it does not explain every macOS access control. You can also inspect the item in Finder using the next section.
If the error says it cannot create a folder that does not exist yet, inspect its existing parent folder. There is no new folder to repair until creation succeeds.
Parent access matters too. Apple’s archived mkdir reference distinguishes missing write access on a parent directory from missing search access along the path. A file’s own permissions are only part of the picture.
If the item belongs to another person, an employer, or a shared service, ask its owner or administrator for the appropriate access. I would stop here rather than take ownership of someone else’s files.
2. Use a folder you own for projects and output
For personal development work, a project folder inside your home folder is a sensible starting point. For example, you can create a Projects folder in your home folder using Finder and keep each project inside it.
If an app is trying to save a report or build output in a protected location, change that app’s output setting to a suitable folder you own. Then repeat the original operation.
For an existing project, preserve the original files and any uncommitted work before making a separate working copy. Do not move system software or delete the original project just to make an error disappear.
A location inside your home folder is not proof that every item has correct ownership. Files created by a different account or an earlier elevated command can still need a closer look.
3. Check Sharing & Permissions in Finder
For a personal item that you own and are allowed to change, follow Apple’s Finder permissions guidance:
- Select the exact file or folder in Finder.
- Choose File > Get Info.
- Expand Sharing & Permissions near the bottom.
- Find your account in the list and inspect its privilege.
- If you own the item and need to edit it, change your account’s privilege to Read & Write. Unlock the settings if macOS asks and you are authorized to do so.
Keep the change limited to that item and the account that needs it. Leave the other users and groups alone. Do not give everyone write access as a troubleshooting shortcut.
I would also leave Apply to enclosed items alone during an initial check. It changes the scope from one folder to its contents, which may need different access.
Close the Info window and retry the same operation. If the settings are unavailable or the owner is unexpected, get help with that specific item rather than applying a recursive ownership command.
4. Check the app’s Files & Folders access
macOS also controls whether an app can access locations such as Desktop, Documents, and Downloads. Owning a document and giving an app permission to reach it are separate checks.
When the error concerns one of those locations, review Apple’s Files & Folders settings:
- Open Apple menu > System Settings.
- Choose Privacy & Security > Files & Folders.
- Find the trusted app involved and review its access to the particular location.
For a command launched inside an editor, consider the editor as well as a standalone terminal app. Enable access only when you trust the app and the task genuinely needs that folder.
If the app is not listed or the option is managed, follow the app’s guidance or contact your administrator. Do not grant broad Full Disk Access merely because you saw the words “permission denied.”
5. Fix npm global-install EACCES errors
If your command included -g, it requested a global install. On Unix-like systems, npm places global packages under {prefix}/lib/node_modules and command-line executables under {prefix}/bin, as its folder documentation explains.
For example, an error involving /usr/local/lib/node_modules may mean your current global destination is not writable by your account. Check your actual configuration instead of assuming a path from somebody else’s Mac.
These commands inspect the installation and its settings:
node -v
npm -v
command -v node
command -v npm
npm config get prefix
npm config get cacheThe version checks are documented in npm’s installation guide. The npm config reference explains that get prints a setting without changing it.
If node or npm is not found, address its installation or your shell’s PATH first. npm install is a package-installation command; typing it cannot install a missing npm command.
Option A: Use a Node version manager
This is npm’s recommended approach. Start from its installation guide and follow the chosen manager’s own macOS instructions.
For example, nvm’s official project provides its current installation steps. Read those steps before running downloaded installer scripts, especially on a managed work computer.
If you choose nvm and have already installed and loaded it in your shell, this command installs an LTS Node release:
nvm install --ltsUse the Node version your project requires if it specifies one. Recheck the active Node and npm paths in the terminal you actually use, then retry the intended package installation without adding sudo.
Do not combine this with a custom npm prefix. The nvm compatibility notes flag custom prefix settings as a source of problems. If you previously added one, follow nvm’s instructions for that setting. Keep unrelated registry and authentication configuration intact.
Option B: Use npm’s documented home-directory prefix
If you are keeping an installation that does not use a version manager, npm documents a user-owned prefix as the alternative. First confirm that ~/.local is a suitable location you control. The ~ means your home folder.
Record the existing prefix, then set the new value:
npm config get prefix
npm config set prefix ~/.localThis changes npm configuration for future global installations. It does not repair a local project’s files or move packages that were already installed elsewhere.
Next, make the new executable directory available to your shell. Following npm’s documented profile approach, open or create ~/.profile in a text editor and add this line once, preserving its existing contents:
export PATH="$HOME/.local/bin:$PATH"For zsh, npm also tells you to add the following line to ~/.zprofile. Again, preserve existing settings and avoid duplicating a line that is already there:
source ~/.profileLoad your updated profile in the current terminal with source ~/.profile, or open a new login terminal. Recheck the prefix and retry the trusted package you originally intended to install.
If an installation succeeds but its command is not found, check that ~/.local/bin is on the PATH of that same terminal. Do not respond by changing system-directory permissions.
6. Treat local-project and cache errors separately
A failure inside your project’s node_modules directory needs a project-level check. Changing the global prefix does not change the ownership or access of that existing project.
Inspect the named item and its parent, confirm your working directory, and check that the project is yours. If you need a clean working copy, preserve your source files and uncommitted changes first. Avoid blanket deletion as a permission fix.
If the error names npm’s cache, use npm config get cache to identify the actual cache directory. Do not assume it is the same directory as your global packages.
Check who owns the exact cache path. If earlier elevated commands left files owned by another account, ask for a narrowly scoped repair after confirming the location and ownership. Do not reset your whole home folder or a shared package-manager installation.
Clearing the cache is not a substitute for restoring the correct access. npm’s cache documentation describes an integrity-checking cache and says clearing it is typically unnecessary.
For occasional command-line tools, npm also suggests npx as an alternative to a global install. It can download and run package code, and it still needs access to its cache and any files the tool uses. Check the package’s identity and documentation before running it.
7. Avoid fixes that widen access across your Mac
I would skip advice that makes an entire directory tree writable by everyone. As the Node.js file-mode reference shows, a 777 permission mode grants read, write, and execute bits to owner, group, and others. Applying it recursively reaches every item below the chosen directory.
Broad recursive chown commands are also a poor default. Taking ownership of a whole system or package-manager directory can change files that have nothing to do with your error.
Similarly, adding sudo, --unsafe-perm, or --allow-root to npm commands is not the remedy recommended by npm’s current EACCES guide. Do not use old command snippets as permission bypasses.
If the path is part of macOS itself, leave its protections in place. Apple explains that System Integrity Protection limits changes to protected system locations, including actions by the root account. Disabling SIP is not an appropriate troubleshooting step for this guide.
Also note Apple’s distinction: /usr/local is a location third-party software can use. An error there does not automatically mean SIP is responsible. Check the actual ownership and npm configuration.
Does Disk Utility First Aid repair this error?
First Aid has a different job. Apple describes it as checking and repairing formatting and directory-structure errors on a storage device.
It does not replace checking a file’s access, fixing an npm destination, or reviewing an app’s Files & Folders permission. I would not run it as the standard next step for an isolated npm EACCES message.
If you also see signs of storage trouble, such as damaged files or a disk behaving unexpectedly, back up your data and follow Apple’s storage-repair guidance. Do not erase or reformat a disk to resolve a routine permissions error.
Verify the fix before making another change
After one targeted change, repeat the exact operation that failed. A successful install, save, or file access is the relevant check. Simply closing the error message is not confirmation.
If it fails again, compare the new path and operation with the original. A change from a global installation path to a project or cache path points you toward a different check.
When you need help, collect the command or app action, exact error code, failing operation, relevant path, macOS version, and Node/npm versions if applicable. Redact usernames, private project names, tokens, and other sensitive information before posting logs publicly.
On a managed Mac or a shared folder, give that information to the administrator or owner. The goal is the smallest correct change, with enough context to explain why it is needed.
Frequently asked questions
Can I fix EACCES without sudo?
Often, yes. Working in a folder you own, correcting your own item’s Finder privileges, or using a per-user Node setup may address the relevant cause. A change made without sudo is not inherently unsafe. Elevated access is not a requirement for ordinary personal project work.
Why does npm still fail after I install a version manager?
Your shell may still resolve Node or npm to a different installation. Check their active paths and the npm prefix. Also read the failing path: a version manager does not automatically repair an existing local project or cache directory.
Does using the same file in two programs cause EACCES?
Not by itself. The EACCES code identifies a denied access operation. Two programs using a file is not enough evidence to diagnose its permissions or justify switching users. Read the exact error and the application’s own guidance.
Why do I have Read & Write access but the app still fails?
Check the parent folders, whether the app uses a different account or location, and its macOS privacy access. A single Finder setting does not summarize every access restriction. If the error persists, keep the logs and seek a scoped diagnosis.
Should I use chmod 777 or change my whole home folder’s owner?
No. Those changes affect far more than the one operation you are trying to repair. Confirm the exact path, owner, and required access, then fix that specific mismatch or ask its administrator.
Final thoughts
The most useful EACCES fix starts with the path in front of you. Check the item, its parent, and the app that is requesting access. For global npm installs, use the documented version-manager or home-directory approach.
Make one limited change, retry, and keep your files and macOS protections intact. If the evidence is unclear, that is the point to get help with the exact error rather than give the program broader access.
