100

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.

G-Man Says 'Reinstate Monica'
  • 7,678
  • 22
  • 41
  • 87
josef.van.niekerk
  • 2,173
  • 5
  • 22
  • 22
  • 1
    Have you tried `sudo chgrp wheel ./entries`? – squircle May 04 '11 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 May 04 '11 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 May 04 '11 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 Dec 16 '12 at 19:25

7 Answers7

113

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.

Old Pro
  • 2,348
  • 1
  • 17
  • 26
  • 8
    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 Dec 08 '13 at 04: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 Jun 16 '14 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 Nov 15 '14 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`). – Erwin Wessels Jan 12 '16 at 07: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 Jan 27 '16 at 16:23
  • Do you also need to change permissions on the directory that owns the file? – Edward Falk Apr 04 '16 at 03:51
  • `man xattr` shows me a manpage with Apple-specific notes - not sure when this was added since the manpage itself is dated from Nov 29, 2010 (before this post was made). – nneonneo Jul 02 '17 at 22:28
  • I was scratching my head why my rsync script was was squawking about `Operation not permitted` for matching ownership until I ran across your post. This particular issue was fixed by `sudo chflags -R nouchg .` in the root of the backup up tree. Thanks. **Very helpful!** – drewk Nov 11 '19 at 00:08
  • When booted into the recovery partition, `xattr` is not in the path. Running it via `/Volumes/xxx/usr/bin/xattr` results in a "bad interpreter" error on Python. Trying to run `xattr` via `/Volumes/xxx/usr/bin/python /Volumes/xxx/usr/bin/xattr` results in an error on a file in the Python framework. – jetset Mar 05 '21 at 00:29
  • In my case I was trying to delete `/Application/iTunes.app`. Even booting into the recovery partition, turning off SIP, rebooting, and then trying to run `xattr` to remove rootless resulted in an error: `xattr: [Errno 1] Operation not permitted: '/Applications/iTunes.app'` I gave up and deleted the file while booted into the recovery partition. – jetset Mar 05 '21 at 00:30
20

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.

Renan
  • 7,981
  • 4
  • 39
  • 48
bendalton
  • 301
  • 1
  • 2
  • 1
    `sudo rm -Rf foldername/` is working perfectly on OSX Mountain Lion – Aryo Nov 12 '12 at 00: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 Feb 05 '13 at 00:31
13

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!

ruffy
  • 131
  • 1
  • 4
  • Awesome, had to `chflags` using `sudo` though, but it makes sense – Felipe Sep 13 '17 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 Aug 02 '18 at 20:47
12

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.

Community
  • 1
Nate
  • 4,083
  • 5
  • 26
  • 25
  • 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 Jul 23 '16 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 Jun 04 '17 at 01:20
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
Sathyajith Bhat
  • 61,504
  • 38
  • 179
  • 264
josef.van.niekerk
  • 2,173
  • 5
  • 22
  • 22
  • You really should take the highest voted answer as 'the answer'. It is complete and accurate. – drewk Nov 11 '19 at 00:13
5

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)

danza
  • 151
  • 1
  • 5
2

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.

camslice
  • 129
  • 2