Yeah, that error is annoying as hell. You're in Terminal, trying to move or delete a file, and macOS just goes "Operation Not Permitted." No explanation, no hint. Just a brick wall.
The Fix: Grant Full Disk Access to Terminal
Open System Settings (or System Preferences on older macOS) and go to Privacy & Security > Full Disk Access.
Click the + button and add Terminal (it's in /System/Applications/Utilities/). If you're using iTerm2, add that instead. Also add your code editor if you're running scripts from it — VS Code and Sublime Text hit this wall too.
Once added, toggle Terminal on if it's not already, then quit Terminal completely (Cmd+Q) and reopen it. Try your command again.
That fixes it 90% of the time. The other 10%? Read on.
Why This Works
Since macOS Catalina (10.15), Apple locked down user data — Desktop, Documents, Downloads — behind a privacy layer. Even if you're an admin and even if you type sudo, apps that don't have explicit Full Disk Access get blocked. It's not a Unix permission issue; it's Apple's TCC (Transparency, Consent, and Control) database deciding who gets in.
Terminal by default has no access. So when you try to rm a file in ~/Documents, the system intercepts and returns "Operation Not Permitted." Granting Full Disk Access tells TCC that Terminal is trustworthy. Simple as that.
Less Common Variations
1. The File Isn't in a Protected Folder
If the file is on an external drive or in /tmp, Full Disk Access might not be the issue. Check the actual permissions with:
ls -lO@ /path/to/file
Look for restricted or hidden flags. If you see restricted, that's a Spotlight or Time Machine metadata flag. Remove it with:
sudo xattr -d com.apple.metadata:com_apple_backup_excludeItem /path/to/file
Had a client last month whose entire Downloads folder was flagged restricted after a failed Time Machine restore. That command cleared it right up.
2. Automation Permission Blocking Scripts
If you're running a script that controls another app (like AppleScript controlling Finder), you might see the error from osascript. That's not Full Disk Access — that's the Automation tab in Privacy & Security. Go there and check the box for your terminal app next to whatever app it's trying to control.
3. App Translocation on Quarantined Apps
Downloaded an app from the internet and it's behaving weirdly? macOS might be running it from a read-only virtual location (App Translocation). Move the app to /Applications first, then try again. This one trips people up because the error appears when the app tries to write near its own bundle.
Prevention: Stop It From Coming Back
The root cause is usually one of two things:
- You upgraded macOS and the TCC database got confused.
- You're using a tool that wasn't around when you first granted permissions.
After a major macOS update (like from Catalina to Monterey), re-check your Full Disk Access list. Updates sometimes reset or drop entries silently. I've seen it happen enough to make it a habit.
Also, if you use rsync or find in scripts, make sure the script runner (like a cron job or launchd agent) has Full Disk Access, not just Terminal. Launchd processes run separately and need their own grant.
One more thing — don't grant Full Disk Access willy-nilly to random apps. Every app with that permission can read your entire disk. Keep the list short: Terminal, your backup tool, maybe a file manager you trust. That's it.
If you've done all this and still get the error, check if the file itself is locked with the uchg flag:
ls -lO /path/to/file | grep uchg
If you see it, unlock with chflags nouchg /path/to/file. That's a classic locked-from-Finder issue that fools people into blaming permissions.
That should cover every angle I've seen in the field. Fix it, move on, and get back to actual work.