I am trying to do the following on my Mac (10.6.7):

sudo chown myusername:wheel ./entries

but Unix/Mac is returning "Operation not permitted". When I ls -lash the culprit file, it looks as follows:

8 -rwxrwxrwx   1 myusername  staff   394B Apr 26 23:26 entries

I've tried sudo and sudo su; nothing works. Any ideas what's up?

I'm trying to chmod files I've copied from my old Ubuntu box. Most of the files have successfully chmod'ed recursively; just this one is stuck and I don't understand why.

  • 1
    Have you tried sudo chgrp wheel ./entries?
    – squircle
    Commented May 4, 2011 at 20:46
  • 1
    Do a file system check. Open Disk Utility, select your volume, and click Verify Disk, then, if necessary, Repair Disk.
    – Daniel Beck
    Commented May 4, 2011 at 20:48
  • Make sure the file is not locked in Finder (no lock badge on the icon). To change it, open the Get Info dialog and uncheck Locked.
    – Daniel Beck
    Commented May 4, 2011 at 20:50
  • If it is an "external" volume (i.e. not the system volume), you may have to remove the "Ignore ownership on this volume" option. (See at the bottom of the Get Info window for the volume itself).
    – mivk
    Commented Dec 16, 2012 at 19:25

7 Answers 7


Yes, Mac has many enhancements to Unix in the area of files. Ignoring the whole resource fork thing which is not used much anymore, there are:

  • the standard Unix permissions ugo rwx and so on. Normal Unix tools apply.
  • ACL's, viewable with ls -le and changeable with chmod [ -a | +a | =a ].
  • file flags viewable with ls -lO (Capital oh, not zero) and changeable with chflags.
  • extended attributes, viewable with ls -l@ (attribute keys only) and viewable and changeable with xattr. (Use xattr -h for help if man xattr does not give you anything.)
  • Starting with OS X 10.11 "El Capitan", System Integrity Protection (SIP) further protects some files from changes from ordinary processes, even when using sudo to run as root. Files protected by SIP will be listed by ls -lO as having the restricted flag and/or be listed by ls -l@ as having the com.apple.rootless attribute.

You can be denied operations on a file because of Unix permissions, ACLs, file flags, or SIP. To fully unlock a file:

sudo chmod -N file        # Remove ACLs from file
sudo chmod ugo+rw file    # Give everyone read-write permission to file
sudo chflags nouchg file  # Clear the user immutable flag from file
sudo chflags norestricted file  # Remove the SIP protection from file
sudo xattr -d com.apple.rootless file # Remove SIP protection from file

If System Integrity Protection (SIP) is enabled, sudo chflags norestricted and sudo xattr -d com.apple.rootless will also return an "Operation not permitted" error. To clear the flag and/or attribute you need to boot into macOS Recovery and either run the commands from Terminal (you may have to first use Disk Utility to unlock and mount your boot drive, then remember your files will be under /Volumes/Macintosh HD or whatever your boot drive is named) or disable SIP altogether and then reboot and the commands should then work. Be aware, however, that future OS updates will likely restore the restricted flag and com.apple.rootless attribute to any files you removed it from.

Disabling SIP is not recommended as it removes lots of protection against malware and accidental damage, plus it is not necessary when you can simply remove the protection on a per-file basis. If you do disable SIP, re-enable it when you are done making changes.

Note that if ls -lO shows the schg flag is set, you have to get into single-user mode to unset it. I'm not going to get into that here as there are bigger questions about why the file has that flag set and why you are trying to mess with it and what the consequences will be.

  • 9
    Adding to this, other flags might prevent you to change your files. In my script I put sudo chflags -R nouchg,noschg,nouappnd,nosappnd,noopaque,dump .
    – djjeck
    Commented Dec 8, 2013 at 4:45
  • 1
    Note: if something has the "unchangeable" flag, the Locked checkbox in Get Info will be checked and grayed out. "sudo chflags nouchg" fixes it.
    – Foo Bar
    Commented Jun 16, 2014 at 18:39
  • 1
    I couldn't do the -N and ugo+rw both at once (I got Failed to clear ACL on file ugo+rw: No such file or directory) but running them individually worked fine. If recursive is desired the -R must be the first arg.
    – owenfi
    Commented Nov 15, 2014 at 23:38
  • 3
    Note that System Integrity Protection (rootless) can also cause this on El Capitan and later. To resolve that, boot into Recovery Mode (Cmd-R), open Terminal and run csrutil disable, then restart (to reenable, use csrutil enable). Commented Jan 12, 2016 at 7:54
  • Thank you ... I had no idea about file flags. Now I understand why it said override rwxrwxrwx huttarl/staff uchg for green.html?
    – LarsH
    Commented Jan 27, 2016 at 16:23

I had the same problem. It turns out that the offending files were marked as "Locked" by the OS. I found this solution and it solved the problems in seconds:


It seems like the rm command has changed in Tiger such that if you use rm -Rf with elevated privileges, it will automatically unlock the files.

In OS X before Tiger: find /Volumes/Transit -flags +uchg -print0 | xargs -0 chflags nouchg

In OS X after Tiger: sudo rm -Rf foldername/

Also, even after OS X 10.4, there may be file metadata flags such as uchg and uappnd, which prevent any modification of the file permissions or ownership. chflags can remove the flags. Some of the file attributes/metadata and how they are handled by different copy tools are here.

  • 1
    sudo rm -Rf foldername/ is working perfectly on OSX Mountain Lion
    – Aryo
    Commented Nov 12, 2012 at 0:05
  • 5
    @Aryo: rm deletes the directory. Is there a way to just unlock everything without deleting it? When I look uchg is not set, and I can turn it on and off again as expected (with chflags [no]uchg), but that has no effect on the lock icon in the Finder, or on my ability to chown.
    – orome
    Commented Feb 5, 2013 at 0:31
  • 1
    You are telling people to PERMANENTLY DELETE directories?! not change permissions. This answer should be removed.
    – John
    Commented Oct 25, 2023 at 20:19
  • I was about to say the same thing as the last @John. Why is there an answer here talking about deleting directories? That's not what the question was about. Also, the link is broken, that's why you're supposed to give answers here, not link to them.
    – John Smith
    Commented Jan 25 at 0:00

I had the same problem with the Crashplan.app.

All the solutions listed here would not help me, but this one did the trick: http://forums.macrumors.com/showthread.php?t=1546163

You have to change the system and user immutable flags:

Do this to see which flags are active on your file/folder:

ls -lhdO MyFile

The response might look like this:

drwxrwxr-x 3 root admin schg,uchg 102B Apr 8 2013 MyFile

schg,uchg are those immutable flags. One for the system and one for the user. To remove them, do the following:

chflags noschg CrashPlan.app # this removes system immutable flag
chflags nouchg CrashPlan.app # this removes the user immutable flags

Then, for me at least, the file is unlocked and you can delete it!

  • Awesome, had to chflags using sudo though, but it makes sense
    – Felipe
    Commented Sep 13, 2017 at 19:45
  • Had the same issue with CrashPlan.app (I had drwxrwxr-x@ 3 _BGMXPCHelper admin schg 96B 9 Jan 2018 CrashPlan.app), and this one was the only solution that allowed me to delete it, thanks!
    – benomatis
    Commented Aug 2, 2018 at 20:47

In OS X 10.11 (El Capitan), this can also be caused by the new Rootless feature. See this answer for an explanation.

In short, for certain important directories, there is no way to modify them — whether you use sudo, chown or chmod. This affects the /usr directory, (although you are allowed to modify /usr/local).

To modify a Rootless-protected directory, you need to disable Rootless. And, of course, re-enable it after making your modifications, because it is an important security enhancement.

  • 1
    Wow. That drove me nuts. Somehow I needed to copy something to /usr/lib which was otherwise not found in /usr/local/lib (don't ask me why). And that did the trick.
    – qwerty_so
    Commented Jul 23, 2016 at 21:01
  • 4
    Actually, you don't have to disable Rootless altogether, you can just boot into Recovery mode (which you'd have to do anyway to disable Rootless) and make the changes you want from the Terminal there.
    – Old Pro
    Commented Jun 4, 2017 at 1:20

After a lot of struggling, here's what I had to do to get the problem fixed:

  • Moved the file to ~/Desktop
  • sudo chown myusername:staff ./entries
  • Moving the file back to it's original location didn't work (Operation not permitted, again), so...
  • sudo rm ./entries
  • sudo mv ~/Desktop/entries ./entries
  • You really should take the highest voted answer as 'the answer'. It is complete and accurate.
    – drewk
    Commented Nov 11, 2019 at 0:13

I had the same problem, about my home folder. At the end i just used finder like this:

Go -> Computer -> your disk -> Users -> your user name -> right click -> Get Info

I found that it was locked, probably i did it in the past and forgot. Unchecked the locked checkbox, problem fixed.

I can recommend using 'Get Info' from finder in order to tackle this kind of problems.

(OS X 10.8.3)

  • This helped me to unlock .iso from glitchy Virtual Box.
    – Nakilon
    Commented Sep 28, 2014 at 18:54

Make sure both the file and its parent folder are unlocked

I was facing a similar problem when trying to delete a Mac Mail email signature file. I could not delete it until I had unlocked the file as well as its parent folder.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .