How to Fix the “zsh: permission denied” Mac Terminal Error

You hit the return key, fully expecting a cascade of beautiful, scrolling output to flood your monitor.

Nothing happens.

Instead, your Mac spits back a tiny, infuriating string of text that feels like a slap in the face: zsh: permission denied: ./script.sh. Your pulse ticks up a notch. You type it again, maybe a little harder this time, as if physical force will somehow bypass the UNIX bureaucracy. Same result.

It hurts.

You’ve probably spent the last three hours frantically scraping Stack Overflow threads, pasting obscure commands into your terminal with the blind hope that one of them magically pays off. You just want the script to run, right? But macOS is standing there like a stubborn bouncer outside a VIP club, arms crossed, shaking its head.

I know the exact flavor of this frustration. Back in late October 2019, Apple dropped macOS Catalina. They unceremoniously dumped bash as the default shell and crowned zsh (Z shell) the new king. I was managing a deployment pipeline for a mid-sized fintech startup at the time. We relied on roughly 140 custom bash scripts to keep our local developer environments from completely falling apart. I updated my MacBook, pulled the main repository, ran our master setup script, and—bam. Access denied. Across the board. Everything broke instantly. I spent the next 14 hours manually unpicking the weird, granular permission rules Apple had secretly grafted onto the new operating system.

Fixing this error requires understanding exactly why your machine is terrified of the file you are trying to execute. We need to unpack the invisible layers of security macOS wraps around your data.

The Anatomy of a Lockdown: Why Zsh Hates Your File

Whenever you see that dreaded permission denial, your terminal is actually communicating a very specific boundary violation. It isn’t a bug. The system is functioning exactly as engineered. UNIX-based operating systems (which macOS is built upon) do not trust anything by default.

To see what the terminal sees, you need to list the hidden attributes of your file. Open your terminal and type ls -la followed by the directory path. Look at the far left side of the output. You will see a bizarre string of ten characters that looks something like this: -rw-r--r--.

That little string is the DNA of your file’s security profile. Let’s break it apart.

The very first character tells you the file type. A hyphen means it’s a standard file. A “d” means it’s a directory. The next nine characters are broken into three distinct blocks of three: User (you), Group (your team or admin group), and Other (everyone else on the computer). Within those blocks, you have three letters. “r” stands for read. “w” stands for write. And “x” stands for execute.

If you are looking at your script and you do not see an “x” in that first block of three characters, zsh will never, ever let you run it. It physically cannot. The operating system sees a text file, not a program.

Fix 1: The Execution Bit (Giving Yourself the Keys)

This is the most common culprit. You downloaded a script from GitHub, or you wrote a quick automation snippet in VS Code, and you tried to run it. By default, text editors and web browsers do not save files with execution rights. They save them as plain text.

You need to manually flip the switch. We do this using a command called chmod (change mode).

Type this exactly: chmod +x yourfilename.sh

Hit enter. It won’t give you a confirmation message—UNIX assumes you know what you are doing—but if you run ls -la again, you will see that an “x” has magically appeared in your permission string. Try running your script now. Nine times out of ten, this clears the roadblock entirely.

The Danger of the Nuclear Option: 777

If you wander around the darker corners of developer forums, you will inevitably find someone casually telling you to run chmod 777 to fix your problems. Do not do this.

It is incredibly reckless. Using 777 is the equivalent of taking the front door off your house, putting up a neon sign saying “Free TVs,” and going on vacation. It grants read, write, and execute permissions to literally every single user and process on your machine. If a malicious script finds its way onto your hard drive, it can modify a 777 file without asking for a password.

To understand what these numbers actually mean, we have to look at the octal permission matrix. Each letter has a mathematical value. Read is 4. Write is 2. Execute is 1. You add them together to get your final number.

Octal Number	Permission String	Mathematical Breakdown	Real-World Meaning
7	rwx	4 (Read) + 2 (Write) + 1 (Execute)	Absolute control. You can read, edit, and run the file.
6	rw-	4 (Read) + 2 (Write) + 0	Standard document mode. You can read and edit, but not run it.
5	r-x	4 (Read) + 0 + 1 (Execute)	Safe execution. You can read and run it, but you cannot alter the code.
4	r--	4 (Read) + 0 + 0	Read-only. You can look, but you can’t touch.
0	---	0 + 0 + 0	Completely locked down. Invisible to the user.

When you type chmod 755 script.sh, you are setting three different numbers. The first 7 gives you (the owner) full rights. The first 5 gives your group read and execute rights. The final 5 gives everyone else read and execute rights. This is the absolute gold standard for scripts you want to run safely.

Fix 2: Ownership Disputes and the Sudo Hammer

Sometimes, giving a file execution rights does absolutely nothing. You run chmod +x, try to execute the file, and zsh still spits that same denied message back in your face.

Why?

Because you don’t actually own the file.

This happens frequently if you copy files from another user account, restore from an old Time Machine backup, or install packages globally using a package manager that requires root access. The operating system looks at your user account, looks at the file owner, realizes they don’t match, and blocks the execution. It doesn’t matter if the file has an “x” on it. You aren’t on the list.

Run ls -l again. Next to the permission string, you will see two names. The first is the user who owns the file, and the second is the group. If the first name says root or some other strange username instead of your actual Mac login name, you have found the problem.

You need to take ownership of the file using the chown (change owner) command. Because you are taking property away from another user (even a system user), macOS requires you to prove you have administrative privileges. We do this by invoking sudo (superuser do).

Type this: sudo chown yourusername:staff yourfilename.sh

The terminal will pause and ask for your Mac login password. When you type it, no characters or asterisks will appear on the screen. This is a deliberate security feature to prevent shoulder-surfing. Just type the password blindly and hit return. Once you reclaim ownership, try running the script again. The zsh error should vanish.

Fix 3: Apple’s Invisible Quarantine Flag

Let’s say you created the file. You own it. You gave it 755 permissions. It absolutely should run.

But zsh still denies you.

Welcome to the silent, invisible world of macOS Gatekeeper. Apple is terrified of malware. To protect average users from accidentally downloading and running malicious software, Apple uses a deeply embedded system called Gatekeeper. When you download a file from the internet—via Chrome, Safari, or even curl—macOS secretly tags that file with an extended attribute called com.apple.quarantine.

Standard terminal commands like ls -l do not show this quarantine flag. It hides in the background, quietly blocking execution until you manually approve it through the graphical user interface. But if you are working purely in the terminal, you never get that graphical popup asking “Are you sure you want to open this?”

You just get a blank denial.

To check if Apple has quarantined your script, you need to use the extended attributes command. Type xattr yourfilename.sh.

If the terminal prints out com.apple.quarantine, you’ve caught the culprit red-handed. The fix is incredibly satisfying. You basically tell macOS to strip the quarantine tag off the file entirely, bypassing Gatekeeper for this specific item.

Run this command: xattr -d com.apple.quarantine yourfilename.sh

No output means success. The file is now clean, trusted, and ready to execute. I cannot tell you how many hours I wasted during that 2019 Catalina migration trying to fix UNIX permissions when the actual problem was Apple’s invisible quarantine system slapping a padlock on my downloaded bash scripts.

Fix 4: The Path and the Shebang

Sometimes, the error is purely linguistic. The terminal is a literal machine; it does exactly what you tell it to do, even if what you are telling it makes no sense.

If you type script.sh and hit return, zsh will search through a predefined list of directories (known as your $PATH) looking for a program called “script.sh”. Your current downloads folder or desktop is not in that path. So, zsh gets confused, tries to interpret your command as a built-in function, fails, and throws a permission or “command not found” error.

You must explicitly tell zsh to look in the exact directory you are currently standing in. You do this by adding a dot and a slash before the file name: ./script.sh.

The dot means “right here.” The slash means “inside this directory.”

Then there is the issue of the shebang. Open your script in a text editor. Look at the very first line. Does it say #!/bin/bash or #!/bin/zsh?

That sequence of characters (pound sign, exclamation mark) is called a shebang. It tells the operating system exactly which interpreter should read the code below it. If your script specifies an interpreter that doesn’t exist, or one that you don’t have permission to use, zsh will throw a permission denied error before it reads a single line of your actual code.

If you are on a modern Mac running Apple Silicon (M1/M2/M3 chips), Homebrew installs things in a completely different location than older Intel Macs. Intel Macs put Homebrew binaries in /usr/local/bin. Apple Silicon Macs put them in /opt/homebrew/bin. If your script relies on a specific tool and the shebang points to the wrong architecture directory, you will hit a brick wall. Always verify your paths.

Fix 5: The Line Ending Trap (Windows Contamination)

This one is a nightmare to diagnose if you don’t know what to look for.

Let’s imagine a scenario. A colleague working on a Windows machine writes a brilliant python or shell script. They zip it up and slack it over to you. You unzip it, run chmod +x, and try to run it. Zsh immediately spits out a permission denied error, or worse, a completely garbled syntax error involving \r.

Windows and macOS handle the invisible “enter” key character differently. When you hit return on a Mac, it inserts a Line Feed (LF). When you hit return on a Windows machine, it inserts a Carriage Return AND a Line Feed (CRLF).

Zsh reads that Windows-created file, hits the end of the first line, sees that hidden Carriage Return character, and chokes. It tries to execute a file path with an invisible, illegal character attached to it. The system panics and denies permission.

You have to scrub the Windows formatting off the file. If you have Homebrew installed, you can install a tiny, brilliant utility called dos2unix.

Run brew install dos2unix.

Once installed, simply type dos2unix yourfilename.sh. The utility will silently strip out all the illegal carriage returns, leaving a perfectly clean, POSIX-compliant script that zsh will happily execute.

Fix 6: The File System Format (The External Drive Dilemma)

Are you trying to run a script directly from an external USB thumb drive or an external SSD?

Stop. Look at how that drive is formatted.

If you bought a hard drive off the shelf at Best Buy, it is almost certainly formatted as exFAT or FAT32. Manufacturers do this so the drive works on both Windows and Mac right out of the box. But there is a massive, glaring problem with exFAT.

It does not support UNIX file permissions.

The entire concept of read, write, and execute simply does not exist on an exFAT file system. When macOS mounts an exFAT drive, it fakes the permissions just enough to let you read and write files. But it strictly forbids execution. If you run chmod +x on a script sitting on an exFAT drive, the terminal will quietly accept the command and do absolutely nothing. The execution bit will never flip.

If you absolutely must run scripts from an external drive, you have to format that drive as APFS (Apple File System) or Mac OS Extended (Journaled) using Disk Utility. Once the drive uses a native Apple file system, UNIX permissions will function normally, and zsh will let you work.

Fix 7: System Integrity Protection and Full Disk Access

Sometimes, the script is fine. The permissions are fine. The ownership is fine. But the script is trying to touch a part of the Mac that Apple has declared completely off-limits.

Starting with macOS El Capitan, Apple introduced System Integrity Protection (SIP). It is a root-level lockdown of essential system directories like /System, /bin, and /usr. Even if you use sudo, you cannot modify files in these directories. If your script tries to write a log file or install a dependency into an SIP-protected folder, zsh will immediately shut it down with a permission denied error.

You cannot (and should not) turn off SIP for daily use. Instead, you need to rewrite your script to output its data to safe, unprotected user directories like ~/.local/bin or a custom folder in your Documents.

Similarly, macOS Ventura and Sonoma have incredibly aggressive privacy controls regarding your personal files. If you run a terminal script that tries to scan your Downloads, Documents, or Desktop folders, the operating system intervenes at the graphical level.

If you’ve accidentally clicked “Don’t Allow” when the Mac popped up a warning asking if Terminal could access your files, zsh will be permanently locked out of those folders. Every script you run that touches them will throw a permission denied error.

To fix this, you have to dig into the graphical settings:

1. Click the Apple logo in the top left corner of your screen.
2. Open System Settings.
3. Scroll down and click on Privacy & Security.
4. Click on Full Disk Access.
5. Look for Terminal (or iTerm2 if you use that).
6. Toggle the switch to the “on” position. (You will need to authenticate with your fingerprint or Mac password).
7. Completely quit out of your terminal app and restart it.

By granting Full Disk Access, you bypass the annoying graphical pop-ups and let zsh operate with the authority it actually needs to manage your files.

The Tri-Layer Permission Diagnostic Framework

When you are staring down a stubborn terminal error, randomly guessing commands is a massive waste of time. You need a systematic approach to isolate exactly which layer of security is blocking you. I use a specific mental model I call the Tri-Layer Diagnostic Framework. It forces you to check the simplest things first, progressively moving toward the more complex, hidden system restrictions.

If you hit a “permission denied” wall, run through this exact sequence:

• Layer 1: The File Level (The Obvious Stuff)
  • Run ls -l filename.
  • Check the owner. Is it your username? If no, run sudo chown youruser:staff filename.
  • Check the execution bit. Is there an “x” in the string? If no, run chmod +x filename.
  • Are you specifying the path correctly? Ensure you are typing ./filename instead of just the name.
• Layer 2: The OS Level (The Hidden Stuff)
  • Did you download this file from the internet? Run xattr filename.
  • If it shows quarantine, strip it: xattr -d com.apple.quarantine filename.
  • Is the file sitting on a Windows-formatted USB drive? Move it to your Mac’s internal drive.
  • Did a Windows user create it? Run dos2unix filename to fix the line endings.
• Layer 3: The System/Hardware Level (The Deep Stuff)
  • Does the script try to modify core Mac files? Check the code for paths starting with /System or /usr/bin.
  • Does the terminal have rights to see the folder? Check System Settings -> Privacy & Security -> Full Disk Access.
  • Is the shebang pointing to an architecture that doesn’t exist on your M-series Mac? Check for /opt/homebrew vs /usr/local.

Working through that list systematically eliminates the guesswork. You stop fighting the machine and start diagnosing it like a mechanic reading an engine code.

Dealing with Homebrew Permission Nightmares

We need to talk about Homebrew. If you are a developer, a data scientist, or just a power user, you probably use Homebrew to install packages. And Homebrew is notorious for generating wildly confusing zsh permission errors, especially when updating or installing global packages like Node, Python, or Ruby.

Here is a deeply realistic scenario. You type brew upgrade. The terminal chugs along for a few seconds, downloading files, and suddenly halts. Red text floods the screen. Zsh screams that permission is denied trying to write to a specific directory inside /usr/local/Cellar or /usr/local/share/man.

Your first instinct is probably to slap sudo in front of the brew command. sudo brew upgrade.

Never do this. Homebrew explicitly forbids running its commands as root because it is a massive security risk. If you run Homebrew as root, any script inside a package you download has total, unrestricted access to your entire machine. Homebrew will actually block you from doing it and throw a different error.

The actual root cause of this specific permission denied error is directory ownership. At some point in the past, you or an installer script probably ran a command with sudo that created a folder inside the Homebrew directory tree. Because sudo was used, the root user owns that specific folder. Now, when regular Homebrew (running as your normal user) tries to update a file inside that folder, the OS blocks it.

To fix Homebrew permission cascades, you have to forcefully take back ownership of the entire Homebrew directory tree.

If you are on an Intel Mac, run this exact command:
sudo chown -R $(whoami) /usr/local/*

If you are on an Apple Silicon Mac (M1/M2/M3), run this instead:
sudo chown -R $(whoami) /opt/homebrew/*

Let’s break down why that command is so powerful. The -R flag stands for recursive. It tells the system to drill down into every single folder, sub-folder, and file inside the target directory. The $(whoami) snippet is a clever variable that automatically inserts your exact Mac username. You are essentially telling the OS: “I don’t care who owned these thousands of files previously. I own them now.”

Once the terminal finishes processing that massive ownership change (it might take a minute or two), run brew update again. The permission errors will be completely gone.

When SSH Keys Deny You Access

There is one incredibly specific, highly frustrating variant of the zsh permission denied error that happens when you are trying to push code to GitHub or connect to a remote server. You type ssh user@server or git push, and zsh immediately throws a permission denied publickey error.

This has nothing to do with the execution bits we talked about earlier. This is a cryptographic failure.

SSH (Secure Shell) relies on a pair of keys—one public, one private. Your private key lives on your Mac, usually inside a hidden folder called ~/.ssh. If the permissions on that private key file are too loose, the SSH protocol will literally refuse to use it. It is a built-in safety mechanism. If your private key can be read by other users on the system, it isn’t private anymore.

Navigate to your SSH directory by typing cd ~/.ssh. Run ls -l.

If your private key (usually named id_rsa or id_ed25519) has permissions that look like -rw-r--r-- (which is 644), SSH will block it. It considers the key compromised because the group and other users have read access.

You have to lock the file down to absolute minimum access. Only you should be able to read it. Nobody else. Not even the group.

Type this: chmod 600 id_rsa (replace id_rsa with your actual key name).

The 600 permission translates to -rw-------. The owner can read and write. Everyone else gets nothing. The moment you tighten that permission, SSH will trust the key again, and your git pushes will go through flawlessly.

The Illusion of the Broken Terminal

It is incredibly easy to feel like your Mac is actively fighting you. When you are staring at a wall of text, and every single command you try gets rejected, the natural human response is to assume the terminal itself is broken. Maybe zsh is corrupted. Maybe you need to reinstall macOS.

You don’t.

The terminal is just a mirror reflecting the underlying rules of the UNIX file system. It has no opinions. It has no vendettas. It simply looks at the math. Does user A have the mathematical right to perform action B on file C? If the math checks out, it runs. If the math fails, it stops.

Every single time you encounter zsh: permission denied, you are just solving a tiny logic puzzle. You check the execution bit. You check the ownership. You check the Apple quarantine status. You check the syntax of your path.

Once you internalize how these layers stack on top of each other, the terminal stops being an intimidating black box. It becomes exactly what it was designed to be—a precision tool that obeys your exact commands, provided you speak its language correctly.