Fix "Operation not permitted" Error in macOS Terminal

intermediate๐ŸŽ macOS2026-03-18| macOS 10.15 Catalina and later (including Ventura, Sonoma, Sequoia), Terminal and third-party shells

Error Message

Operation not permitted
#macos#permission#sip#terminal#full-disk-access

TL;DR

Hitting Operation not permitted in Terminal? Three fixes cover 90% of cases:

  • Go to System Settings โ†’ Privacy & Security โ†’ Full Disk Access โ†’ add Terminal (or your shell app).
  • Modifying system files? Check SIP first: csrutil status.
  • Regular file issue? Run ls -la to check ownership, then fix with chmod/chown.

What Causes This Error

Operation not permitted (errno 1) shows up in four distinct situations โ€” and the fix is completely different for each one:

  • Full Disk Access not granted โ€” Catalina added a permission layer where Terminal needs explicit FDA approval to touch ~/Desktop, ~/Documents, ~/Downloads, Mail data, and more. No FDA, no access โ€” even as your own user.
  • System Integrity Protection (SIP) โ€” SIP locks /System, /usr, /bin, and /sbin. Not even sudo can override it.
  • File/directory permissions โ€” the classic UNIX problem: wrong owner, wrong mode bits, or a BSD immutable flag (uchg/schg) on the file.
  • Sandbox restrictions โ€” sandboxed apps can't freely access arbitrary paths on the filesystem.

Fix 1: Grant Full Disk Access to Terminal

Nine times out of ten, this is the fix when the error hits inside your home folder.

  • Open System Settings (macOS Ventura+) or System Preferences (Monterey and older).
  • Navigate to Privacy & Security โ†’ Full Disk Access.
  • Click + and add Terminal.app from /Applications/Utilities/.
  • Using iTerm2, Warp, or another shell? Add that app too โ€” FDA is granted per application.

Restart Terminal, then retry. You'll know it worked when the same command runs without complaint.

Quick sanity check before and after:

ls ~/Library/Mail
# Before FDA: Operation not permitted
# After FDA: lists the directory contents

Fix 2: Check and Handle SIP

SIP protects core OS paths. sudo doesn't help here โ€” that's by design.

csrutil status
# System Integrity Protection status: enabled.

Trying to modify /System/Library, /usr/bin, or /sbin? SIP is doing its job. Don't fight it.

The better move is almost always a workaround. Instead of editing /usr/bin/python3, use pyenv to manage Python versions, or install tools via Homebrew into /opt/homebrew (Apple Silicon) or /usr/local (Intel). Same result, no SIP wrestling.

If you genuinely need SIP disabled โ€” for kernel extension development, say โ€” here's how:

  • Restart into Recovery Mode: hold Cmd+R on Intel, or hold the power button on Apple Silicon until the options screen appears.
  • Open Terminal from the Utilities menu.
  • Run csrutil disable, then restart normally.

Re-enable it when done: boot into Recovery again and run csrutil enable. Don't leave SIP off on a daily-use machine.

Fix 3: Fix File Permissions

Own the file but still getting blocked? Check what the permissions actually say:

ls -la /path/to/file
# -r--r--r--  1 root  wheel  1024 Mar 18 10:00 myfile.txt

That output tells you everything: root owns it, and nobody has write access. Fix it:

# Take ownership of the file
sudo chown $(whoami) /path/to/file

# Make a script executable
chmod +x myscript.sh

# Standard read/write for a text file
chmod 644 myfile.txt

# Recursive fix on a whole directory
chmod -R 755 /path/to/dir

Not sure which octal value to use? The Unix Permissions Calculator on ToolCraft lets you tick checkboxes and get the exact chmod number โ€” handy when you can never remember if 644 or 755 is what you need.

Fix 4: Remove Immutable Flags

Sometimes the issue isn't permissions at all โ€” it's a BSD flag that locks the file regardless of who owns it.

# The -O flag reveals BSD flags
ls -lO /path/to/file
# -rw-r--r--  1 user  staff  uchg 512 Mar 18 file.txt
#                                  ^^^^ this is the culprit

# Remove user immutable flag
chflags nouchg /path/to/file

# System-locked files need sudo
sudo chflags noschg /path/to/file

The uchg flag gets set by Finder's "Locked" checkbox in Get Info. If you ever checked that box and forgot about it, now you know why you're stuck.

Fix 5: Rosetta / Architecture Mismatch

Apple Silicon Mac running an x86 binary through Rosetta? Occasionally the translated binary lacks the right entitlements and throws this error. Run it natively instead:

# Check what architecture a binary was built for
file /usr/local/bin/mytool
# mytool: Mach-O 64-bit executable x86_64

# Force native ARM execution
arch -arm64 /usr/local/bin/mytool

Verify the Fix

Re-run the command that failed. That's the only test that matters.

FDA verification:

# Should list contents after granting Full Disk Access
ls ~/Library/Safari

# Write test on Desktop
touch ~/Desktop/test_file.txt && echo "Write OK" && rm ~/Desktop/test_file.txt

Permission fix verification:

# Confirm the new permissions look right
ls -la /path/to/file

# Then run the original command again
./myscript.sh

Quick Reference

  • Protected user dirs (Desktop, Documents, Downloads, etc.) โ†’ Grant Full Disk Access
  • /System, /usr/bin, /sbin โ†’ SIP is working as intended; find an alternative path
  • Files you own โ†’ chmod / chown
  • Immutable files โ†’ chflags nouchg
  • sudo doesn't help โ†’ SIP or FDA is the real blocker, not Unix permissions

Related Error Notes