Why does chown report "Operation not permitted" on OS X?

Question

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.

Answer 1

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.

Answer 2

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:

http://explanatorygap.net/2005/07/10/unlocking-files-recursively-from-the-command-line/

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.

Answer 3

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!

Answer 4

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.

Answer 5

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

Answer 6

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)

Answer 7

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.