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 -lato check ownership, then fix withchmod/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 evensudocan 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.appfrom/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

