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.

  • What is the underlying thing that you are trying to do? Perhaps there is a reason to that file having a lock. Aug 22 '11 at 23:15
  • 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
    Aug 22 '11 at 23:19
  • 1
    What type of filesystem is the file on? You aren't trying to use chown on an NTFS/FAT filesystem are you?
    – Zoredache
    Aug 22 '11 at 23:24
  • @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? Aug 22 '11 at 23:27
  • @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
    Aug 22 '11 at 23:38

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.

  • 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
    Aug 23 '11 at 13:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.