sudo chown fails with operation not permitted

8

3

I have found similar questions here, but the answers provided to those questions do not resolve my problem.

If I do:

sudo chown <username> main.m

I get an operation not permitted error.

The general solution to prior errors was:

sudo chflags nouchg main.m

to clear a lock flag. However, after doing this, I still cannot chown the file. I have also tried:

chflags noschg main.m

in single user mode without any luck - I get an operation not permitted error.

If anyone has any thoughts, I would be interested.

ericg

Posted 2011-08-22T23:05:08.327

Reputation: 470

What is the underlying thing that you are trying to do? Perhaps there is a reason to that file having a lock. – Tamara Wijsman – 2011-08-22T23:15:11.850

So I can use it as test data without placing the code in a secure helper tool, which requires extra work to debug - not impossible, but annoying enough that if I can change the attributes of the file so a secure helper tool is not necessary, that would make things a bit easier. Considering that this is just test data that was created, there is no longer any good reason for it to have a lock. – ericg – 2011-08-22T23:19:20.300

1What type of filesystem is the file on? You aren't trying to use chown on an NTFS/FAT filesystem are you? – Zoredache – 2011-08-22T23:24:36.470

@ericgorr: Most of that is over the top of my head; I'm unaware of what a secure helper tool exactly is. But as you say, it's just test data that was created; have you properly closed the test file in your code? – Tamara Wijsman – 2011-08-22T23:27:36.183

@Tom a helper tool is OS X's way of giving an application elevated privileges while maintaining privileges - so if an app wants to modify a secure file, for instance, it tells the (authorized) helper tool to modify the file for it. I'm guessing ericgorr wants to avoid elevating his/her application or something to avoid the rigorous debugging that comes with that. – Vervious – 2011-08-22T23:38:43.060

@Zoredache Mac OS Extended (Journaled) – ericg – 2011-08-22T23:41:03.087

@Tom It wasn't my code that created the file. Yes, I am sure it was closed appropriately as I can read the file just fine after multiple reboots, etc. – ericg – 2011-08-22T23:42:37.373

@Nano8Blazex It's just more difficult and time consuming to debug code in a launchd secure helper tool then it is to have the code in a regular application. But, it appears, that may be my only option unless I can figure out how to get rid of the lock on the file so I can perform operations like chown and ditto on it. – ericg – 2011-08-22T23:45:27.667

Answers

8

Mac files can be protected in four three different ways that I'm aware of:

  1. Standard Unix ownerships and permissions like r/w/x for user/group/others that you see with ls -l and fix with chown(1) and chmod(1).
  2. File flags like uchg and schg that you see with ls -lO and fix with chflags(1).
  3. The old Finder metadata "Lock bit" that you see with GetFileInfo filename. You can also see the presence of the Finder metadata, but not its meaning, with ls -l@. You can fix it with SetFile(1). Never mind, this is mapped to the uchg flag now.
  4. Access Control Lists (ACLs) that you see with ls -le and fix with the ACL-related arguments to chmod(1).

So let's see what's up with your file by combining all those flags to ls:

ls -lO@e main.m

It sounds like you already know how to deal with #1 and #2.

If you see an ACL (#4), you can fix it with the ACL-related arguments to chmod(1).

If you're still stumped, update your Answer with the output from that combined ls command I suggested above, so we can see what's going on.

Spiff

Posted 2011-08-22T23:05:08.327

Reputation: 84 656

The issue does appear to be with ACLs. I do find it interesting that sudo doesn't get one around such locks. Furthermore, chmod -R -a# 0 * did remove the ACLs from most of the files in the hierarchy, but failed to remove them from some - using sudo with the chmod didn't help. – ericg – 2011-08-23T13:39:09.223