Fix macOS Permission Denied Error (Sonoma, Ventura)

Quick answer

Run sudo chmod -R -N /path/to/folder in Terminal, then killall Finder — that clears the stuck ACLs causing the error.

Why this happens

macOS uses POSIX permissions (those rwx bits) plus a separate layer called ACLs (Access Control Lists). When you copy files from an external drive, restore from Time Machine, or download from the internet, macOS tags them with metadata that says "this came from another Mac" or "this is quarantined." The Finder then gets confused and throws the You don't have permission to view these files dialog even though your account is an admin and the permissions look fine.

The culprit is almost always a mismatch between the POSIX owner/group and the ACL entries. You might see the folder owned by a UID that doesn't exist on this Mac (like 501 from a different user) or a stale ACL that denies read access. The Finder checks both layers, but it only shows you the POSIX ones in Get Info — so you're left scratching your head.

I've seen this on Sonoma, Ventura, and Monterey. It's especially common after migrating to a new Mac or pulling files off a network share.

Fix steps

Open Terminal (Finder > Applications > Utilities > Terminal, or Spotlight with Cmd+Space).
Navigate to the problem folder. You can drag the folder from Finder into the Terminal window to paste its path. So type cd then drag the folder, then press Enter.
Check the current permissions with ls -le@ — that shows ACLs and extended attributes. You'll see lines starting with 0: or 1: that list deny or allow entries.
Strip all ACLs with sudo chmod -R -N . — the -R applies recursively, -N removes all ACL entries. You'll need your admin password. This leaves only the standard POSIX permissions.
Fix the owner to your user — in case the files are owned by a ghost UID, run sudo chown -R $(whoami):staff . This sets the owner to your current account.
Restart Finder with killall Finder. It relaunches instantly. You can also just log out and back in if you prefer.
Test the folder. If the error's gone, you're done. If not, move on to the alternatives.

If that doesn't work

Reset the quarantine flag

For files downloaded from the internet, the com.apple.quarantine extended attribute can cause weird permission behavior. Remove it with:

sudo xattr -dr com.apple.quarantine .

Run that in the same folder. Don't bother doing this for system files — only for user data.

Check the folder's parent permissions

Sometimes the error is on a folder inside, but the parent folder blocks traversal. Make sure the parent has at least read and execute permissions for you:

sudo chmod +x /path/to/parent

That's often enough on network volumes.

Use the Finder's own repair

Right-click the folder, select Get Info, then unlock the lock icon at the bottom. Add your account to the Sharing & Permissions list and set it to Read & Write. Then click the gear icon and choose Apply to enclosed items.

I've seen this work when the ACL reset didn't, but it's slower for large trees. Worth a shot if Terminal isn't your thing.

How to avoid it in the future

Always eject external drives properly — dragging to Trash or pressing Cmd+E avoids interrupted writes that leave permissions in a half-baked state. If you're copying from a Windows or Linux machine, consider using rsync with the -E flag to preserve extended attributes, or just accept that your Mac will re-tag them.

When migrating with Migration Assistant, double-check that the source Mac is on the same macOS version. I've seen UID mismatches when moving from an older system that used a different user ID scheme. If you're stuck, create a new user account on the destination and copy over only the data — it's a pain, but it sidesteps the ACL mess entirely.

For Time Machine restores, let the restore finish completely before poking around in the folders. Interrupting it can leave ACLs in a state that looks fine but acts broken.

One more thing — if you're on a corporate Mac with MDM (like Jamf or Intune), the profile might be enforcing permissions that override your changes. Check with your IT department before you start running sudo commands on a managed machine. They'll have a policy for this.

That's it. The ACL reset fixes 95% of these cases. The rest are usually quarantine flags or parent folder issues. Don't waste time with First Aid or reinstalling macOS — that's overkill for what's essentially a metadata hiccup.