Why do I get "ls: Desktop: Operation not permitted" when I own Desktop?

Question

I'm on Big Sur, and I understand there have been some changes with permissions in macOS since Catalina. I don't understand, however, how it is possible that I cannot ls ~/Desktop when ls -l ~ shows drwx------+ for permissions and me as the owner. Could someone explain this?

Edit: to be clear, I am not asking how to access this directory, but how it is possible that I cannot, given how Unix permissions work.

• Gilby: What is the output from ls -le ~? That will show the ACL. But @user3439894 comment may be what you need.
• Gilby: @user3439894 You are most likely right about the solution. Just pointing out that permissions issues need more than just ls -l and (as you know) ls -le would check that the permissions are as default.
• user3439894: @Gilby, I decided to check something out in a clean install of macOS Big Sur and posted an answer with my findings. It was a permissions issue, but in System Preferences > Security & Privacy > Privacy > Files and Folders, not Full Disk Access. That said, at one point I did have to add Terminal to Full Disk Access to accomplish something, just don't remember what.

Answer 1

[This answer is about how it is possible to get a permissions error accessing a file, when the file permissions allow access.]

Recent versions of macOS have additional security layers that are independent of the normal unix-style access permissions. They (mostly) regulate access based on the identity of the program, rather than the user ID the program is running as. The new layers are System Integrity Protection (SIP), which regulates access to the core of the operating system, and Transparency, Consent and Control (TCC), which regulates access to "personal" information (as well as things like the camera and microphone).

Access can be vetoed by either these layers or the standard unix layers. That is, if SIP and TCC allow something but the standard unix permissions forbid it, it's forbidden. And if the standard unix permissions allow something, but SIP or TCC forbids it (as in your example), it's also forbidden.

These new security layers are necessary because we can't trust our software. Even if you set aside malware, experience is showing that many "legitimate" developers would love to spy on their customers for valuable personal data that we'd really rather they not have. So just because I'm running some program doesn't mean that program should have access to everything I have access to (e.g. my emails and contacts, location, camera, etc...).

Answer 2

Testing on a clean install of macOS Big Sur, in Terminal when I executed ls ~/Desktop I was presented with this dialog box:

enter image description here

I clicked: OK

I then executed ls ~/Downloads and was presented with this dialog box:

enter image description here

I clicked: Don't Allow

Executing ls ~Downloads in Terminal again, it returned: ls: Downloads: operation not permitted

I then went to System Preferences > Security & Privacy > Privacy > Files and Folders and had the following:

enter image description here

As you can see what I said OK to is checked and what I said Don't Allow is unchecked.

So, check to see that System Preferences > Security & Privacy > Privacy > Files and Folders > Terminal > Desktop is checked.

---

Notes:

If you do not want to be prompted each time on protected folders, then add Terminal to: System Preferences > Security & Privacy > Privacy > Full Disk Access

In doing so, Files and Folders will show Terminal as having Full Disk Access instead of what's shown in the screenshot above.

If your uncheck Terminal in Full Disk Access, then whatever applications previously were under Files and Folders > Terminal will reappear with the same settings as last set.

• TJ Luoma: I always add Terminal.app to "Full Disk Access" as shown in the same screenshot. Otherwise you have to do this for multiple folders.
• user3439894: @TJ Luoma, I had told the OP in a now deleted comment to do just that and have not edited it into my answer yet but to your comment that is probably why I did as mentioned to the comment to Gilby.
• Gilby: Have upvoted. I am sure that this s what is stopping @Danny.
• dannycbus: Thanks for your response. I am aware of the solution of adding Terminal (and sshd-keychain-wrapper for ssh access) to Full Disk Access, but my question is actually more theoretical than practical. I am curious how it is possible on a Unix operating system that permission to access a directory should be denied to that directory's owner with that directory has rwx permissions.
• pion: @Danny Because xnu’s access control policy is implemented below the BSD layer

Answer 3

Allowing Full Disk Access to Terminal and iTerm is the key answer here:

1. Open System Preferences > Security & Privacy > Privacy > Full Disk Access
2. Select the checkbox next to Terminal and iTerm

Answer 4

I got ls: Downloads: operation not permitted even though iTerm has "Full Disk Access" at
System Settings>Privacy & Security>Files and Folders>iTerm.

Quitting iTerm and opening a new instance did the trick for me.

• mmmmmm: I think Apple normally prompts you to restart an app after you give it full disk access.

Answer 5

Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.

This is a sure shot that worked for me!

https://osxdaily.com/2018/10/09/fix-operation-not-permitted-terminal-error-macos/

• Community: As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
• Allan: Link only answers tend to get deleted. Could you post an edit to your answer with the relevant details here and utilize the link to source your info? As a rule of thumb, the answer should stand on its own. Oh, and Welcome to AD!
• dannycbus: Not only is it unclear, it does not answer the actual question.
• benc: FYI: I'm going to flag this answer for deletion. (For context, I've been a triage moderator for a long time, but haven't used the deletion processes much, but I think this is a pretty clear example...) My basic reasoning is that the article is correct, but not unique, and the screen snapshots are very different than current (Ventura/Sonoma era System Settings.app).