Why does chown report “Operation not permitted” on OS X?
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.
macos file-permissions
add a comment |
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.
macos file-permissions
1
Have you triedsudo chgrp wheel ./entries
?
– squircle
May 4 '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 4 '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 4 '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
add a comment |
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.
macos file-permissions
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.
macos file-permissions
macos file-permissions
edited Jul 19 '15 at 11:12
G-Man
5,586112357
5,586112357
asked May 4 '11 at 20:42
josef.van.niekerkjosef.van.niekerk
75321121
75321121
1
Have you triedsudo chgrp wheel ./entries
?
– squircle
May 4 '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 4 '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 4 '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
add a comment |
1
Have you triedsudo chgrp wheel ./entries
?
– squircle
May 4 '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 4 '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 4 '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
1
1
Have you tried
sudo chgrp wheel ./entries
?– squircle
May 4 '11 at 20:46
Have you tried
sudo chgrp wheel ./entries
?– squircle
May 4 '11 at 20:46
1
1
Do a file system check. Open Disk Utility, select your volume, and click Verify Disk, then, if necessary, Repair Disk.
– Daniel Beck♦
May 4 '11 at 20:48
Do a file system check. Open Disk Utility, select your volume, and click Verify Disk, then, if necessary, Repair Disk.
– Daniel Beck♦
May 4 '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 4 '11 at 20:50
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 4 '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
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
add a comment |
7 Answers
7
active
oldest
votes
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 withls -le
and changeable withchmod [ -a | +a | =a ]
.
file flags viewable withls -lO
(Capital oh, not zero) and changeable withchflags
.
extended attributes, viewable withls -l@
(attribute keys only) and viewable and changeable withxattr
. (Usexattr -h
for help ifman 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 asroot
. Files protected by SIP will be listed byls -lO
as having therestricted
flag and/or be listed byls -l@
as having thecom.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.
7
Adding to this, other flags might prevent you to change your files. In my script I putsudo chflags -R nouchg,noschg,nouappnd,nosappnd,noopaque,dump .
– djjeck
Dec 8 '13 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
Jun 16 '14 at 18:39
1
I couldn't do the-N
andugo+rw
both at once (I gotFailed 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 runcsrutil disable
, then restart (to reenable, usecsrutil enable
).
– Erwin Wessels
Jan 12 '16 at 7:54
Thank you ... I had no idea about file flags. Now I understand why it saidoverride rwxrwxrwx huttarl/staff uchg for green.html?
– LarsH
Jan 27 '16 at 16:23
|
show 2 more comments
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 userm -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.
sudo rm -Rf foldername/
is working perfectly on OSX Mountain Lion
– Aryo
Nov 12 '12 at 0:05
5
@Aryo:rm
deletes the directory. Is there a way to just unlock everything without deleting it? When I lookuchg
is not set, and I can turn it on and off again as expected (withchflags [no]uchg
), but that has no effect on the lock icon in the Finder, or on my ability tochown
.
– orome
Feb 5 '13 at 0:31
add a comment |
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 tochflags
usingsudo
though, but it makes sense
– Felipe
Sep 13 '17 at 19:45
Had the same issue with CrashPlan.app (I haddrwxrwxr-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!
– webeno
Aug 2 '18 at 20:47
add a comment |
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.
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.
– Thomas Kilian
Jul 23 '16 at 21:01
3
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 4 '17 at 1:20
add a comment |
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
add a comment |
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
Sep 28 '14 at 18:54
add a comment |
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.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f279235%2fwhy-does-chown-report-operation-not-permitted-on-os-x%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 withls -le
and changeable withchmod [ -a | +a | =a ]
.
file flags viewable withls -lO
(Capital oh, not zero) and changeable withchflags
.
extended attributes, viewable withls -l@
(attribute keys only) and viewable and changeable withxattr
. (Usexattr -h
for help ifman 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 asroot
. Files protected by SIP will be listed byls -lO
as having therestricted
flag and/or be listed byls -l@
as having thecom.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.
7
Adding to this, other flags might prevent you to change your files. In my script I putsudo chflags -R nouchg,noschg,nouappnd,nosappnd,noopaque,dump .
– djjeck
Dec 8 '13 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
Jun 16 '14 at 18:39
1
I couldn't do the-N
andugo+rw
both at once (I gotFailed 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 runcsrutil disable
, then restart (to reenable, usecsrutil enable
).
– Erwin Wessels
Jan 12 '16 at 7:54
Thank you ... I had no idea about file flags. Now I understand why it saidoverride rwxrwxrwx huttarl/staff uchg for green.html?
– LarsH
Jan 27 '16 at 16:23
|
show 2 more comments
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 withls -le
and changeable withchmod [ -a | +a | =a ]
.
file flags viewable withls -lO
(Capital oh, not zero) and changeable withchflags
.
extended attributes, viewable withls -l@
(attribute keys only) and viewable and changeable withxattr
. (Usexattr -h
for help ifman 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 asroot
. Files protected by SIP will be listed byls -lO
as having therestricted
flag and/or be listed byls -l@
as having thecom.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.
7
Adding to this, other flags might prevent you to change your files. In my script I putsudo chflags -R nouchg,noschg,nouappnd,nosappnd,noopaque,dump .
– djjeck
Dec 8 '13 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
Jun 16 '14 at 18:39
1
I couldn't do the-N
andugo+rw
both at once (I gotFailed 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 runcsrutil disable
, then restart (to reenable, usecsrutil enable
).
– Erwin Wessels
Jan 12 '16 at 7:54
Thank you ... I had no idea about file flags. Now I understand why it saidoverride rwxrwxrwx huttarl/staff uchg for green.html?
– LarsH
Jan 27 '16 at 16:23
|
show 2 more comments
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 withls -le
and changeable withchmod [ -a | +a | =a ]
.
file flags viewable withls -lO
(Capital oh, not zero) and changeable withchflags
.
extended attributes, viewable withls -l@
(attribute keys only) and viewable and changeable withxattr
. (Usexattr -h
for help ifman 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 asroot
. Files protected by SIP will be listed byls -lO
as having therestricted
flag and/or be listed byls -l@
as having thecom.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.
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 withls -le
and changeable withchmod [ -a | +a | =a ]
.
file flags viewable withls -lO
(Capital oh, not zero) and changeable withchflags
.
extended attributes, viewable withls -l@
(attribute keys only) and viewable and changeable withxattr
. (Usexattr -h
for help ifman 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 asroot
. Files protected by SIP will be listed byls -lO
as having therestricted
flag and/or be listed byls -l@
as having thecom.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.
edited Dec 31 '18 at 22:17
answered Dec 12 '12 at 21:58
Old ProOld Pro
1,544817
1,544817
7
Adding to this, other flags might prevent you to change your files. In my script I putsudo chflags -R nouchg,noschg,nouappnd,nosappnd,noopaque,dump .
– djjeck
Dec 8 '13 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
Jun 16 '14 at 18:39
1
I couldn't do the-N
andugo+rw
both at once (I gotFailed 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 runcsrutil disable
, then restart (to reenable, usecsrutil enable
).
– Erwin Wessels
Jan 12 '16 at 7:54
Thank you ... I had no idea about file flags. Now I understand why it saidoverride rwxrwxrwx huttarl/staff uchg for green.html?
– LarsH
Jan 27 '16 at 16:23
|
show 2 more comments
7
Adding to this, other flags might prevent you to change your files. In my script I putsudo chflags -R nouchg,noschg,nouappnd,nosappnd,noopaque,dump .
– djjeck
Dec 8 '13 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
Jun 16 '14 at 18:39
1
I couldn't do the-N
andugo+rw
both at once (I gotFailed 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 runcsrutil disable
, then restart (to reenable, usecsrutil enable
).
– Erwin Wessels
Jan 12 '16 at 7:54
Thank you ... I had no idea about file flags. Now I understand why it saidoverride rwxrwxrwx huttarl/staff uchg for green.html?
– LarsH
Jan 27 '16 at 16:23
7
7
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 8 '13 at 4:45
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 8 '13 at 4:45
1
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
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
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
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
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 7:54
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 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
Jan 27 '16 at 16:23
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
|
show 2 more comments
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 userm -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.
sudo rm -Rf foldername/
is working perfectly on OSX Mountain Lion
– Aryo
Nov 12 '12 at 0:05
5
@Aryo:rm
deletes the directory. Is there a way to just unlock everything without deleting it? When I lookuchg
is not set, and I can turn it on and off again as expected (withchflags [no]uchg
), but that has no effect on the lock icon in the Finder, or on my ability tochown
.
– orome
Feb 5 '13 at 0:31
add a comment |
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 userm -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.
sudo rm -Rf foldername/
is working perfectly on OSX Mountain Lion
– Aryo
Nov 12 '12 at 0:05
5
@Aryo:rm
deletes the directory. Is there a way to just unlock everything without deleting it? When I lookuchg
is not set, and I can turn it on and off again as expected (withchflags [no]uchg
), but that has no effect on the lock icon in the Finder, or on my ability tochown
.
– orome
Feb 5 '13 at 0:31
add a comment |
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 userm -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.
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 userm -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.
edited Aug 3 '12 at 0:33
Renan
7,03042944
7,03042944
answered Jun 8 '11 at 17:47
bendaltonbendalton
28112
28112
sudo rm -Rf foldername/
is working perfectly on OSX Mountain Lion
– Aryo
Nov 12 '12 at 0:05
5
@Aryo:rm
deletes the directory. Is there a way to just unlock everything without deleting it? When I lookuchg
is not set, and I can turn it on and off again as expected (withchflags [no]uchg
), but that has no effect on the lock icon in the Finder, or on my ability tochown
.
– orome
Feb 5 '13 at 0:31
add a comment |
sudo rm -Rf foldername/
is working perfectly on OSX Mountain Lion
– Aryo
Nov 12 '12 at 0:05
5
@Aryo:rm
deletes the directory. Is there a way to just unlock everything without deleting it? When I lookuchg
is not set, and I can turn it on and off again as expected (withchflags [no]uchg
), but that has no effect on the lock icon in the Finder, or on my ability tochown
.
– orome
Feb 5 '13 at 0:31
sudo rm -Rf foldername/
is working perfectly on OSX Mountain Lion– Aryo
Nov 12 '12 at 0:05
sudo rm -Rf foldername/
is working perfectly on OSX Mountain Lion– Aryo
Nov 12 '12 at 0:05
5
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 5 '13 at 0:31
@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 5 '13 at 0:31
add a comment |
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 tochflags
usingsudo
though, but it makes sense
– Felipe
Sep 13 '17 at 19:45
Had the same issue with CrashPlan.app (I haddrwxrwxr-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!
– webeno
Aug 2 '18 at 20:47
add a comment |
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 tochflags
usingsudo
though, but it makes sense
– Felipe
Sep 13 '17 at 19:45
Had the same issue with CrashPlan.app (I haddrwxrwxr-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!
– webeno
Aug 2 '18 at 20:47
add a comment |
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!
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!
answered Aug 21 '14 at 17:30
ruffyruffy
12114
12114
Awesome, had tochflags
usingsudo
though, but it makes sense
– Felipe
Sep 13 '17 at 19:45
Had the same issue with CrashPlan.app (I haddrwxrwxr-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!
– webeno
Aug 2 '18 at 20:47
add a comment |
Awesome, had tochflags
usingsudo
though, but it makes sense
– Felipe
Sep 13 '17 at 19:45
Had the same issue with CrashPlan.app (I haddrwxrwxr-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!
– webeno
Aug 2 '18 at 20:47
Awesome, had to
chflags
using sudo
though, but it makes sense– Felipe
Sep 13 '17 at 19:45
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!– webeno
Aug 2 '18 at 20:47
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!– webeno
Aug 2 '18 at 20:47
add a comment |
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.
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.
– Thomas Kilian
Jul 23 '16 at 21:01
3
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 4 '17 at 1:20
add a comment |
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.
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.
– Thomas Kilian
Jul 23 '16 at 21:01
3
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 4 '17 at 1:20
add a comment |
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.
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.
edited Apr 13 '17 at 12:45
Community♦
1
1
answered Sep 30 '15 at 23:09
NateNate
3,61742025
3,61742025
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.
– Thomas Kilian
Jul 23 '16 at 21:01
3
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 4 '17 at 1:20
add a comment |
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.
– Thomas Kilian
Jul 23 '16 at 21:01
3
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 4 '17 at 1:20
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.
– Thomas Kilian
Jul 23 '16 at 21:01
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.
– Thomas Kilian
Jul 23 '16 at 21:01
3
3
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 4 '17 at 1:20
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 4 '17 at 1:20
add a comment |
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
add a comment |
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
add a comment |
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
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
edited Sep 29 '12 at 7:45
Sathyajith Bhat♦
52.7k29154252
52.7k29154252
answered May 4 '11 at 21:02
josef.van.niekerkjosef.van.niekerk
75321121
75321121
add a comment |
add a comment |
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
Sep 28 '14 at 18:54
add a comment |
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
Sep 28 '14 at 18:54
add a comment |
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)
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)
answered Sep 19 '13 at 22:49
danzadanza
1415
1415
This helped me to unlock.iso
from glitchy Virtual Box.
– Nakilon
Sep 28 '14 at 18:54
add a comment |
This helped me to unlock.iso
from glitchy Virtual Box.
– Nakilon
Sep 28 '14 at 18:54
This helped me to unlock
.iso
from glitchy Virtual Box.– Nakilon
Sep 28 '14 at 18:54
This helped me to unlock
.iso
from glitchy Virtual Box.– Nakilon
Sep 28 '14 at 18:54
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Mar 23 '15 at 15:28
camslicecamslice
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f279235%2fwhy-does-chown-report-operation-not-permitted-on-os-x%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Have you tried
sudo chgrp wheel ./entries
?– squircle
May 4 '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 4 '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 4 '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