Why does chown report “Operation not permitted” on OS X?












58















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.










share|improve this question




















  • 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
















58















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.










share|improve this question




















  • 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














58












58








58


30






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.










share|improve this 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.







macos file-permissions






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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














  • 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








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










7 Answers
7






active

oldest

votes


















78














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.






share|improve this answer





















  • 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






  • 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 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





















18














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.






share|improve this answer


























  • 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 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



















12














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!






share|improve this answer
























  • 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





















11














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.






share|improve this answer


























  • 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



















6














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






share|improve this answer

































    4














    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)






    share|improve this answer
























    • This helped me to unlock .iso from glitchy Virtual Box.

      – Nakilon
      Sep 28 '14 at 18:54



















    0














    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.






    share|improve this answer























      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
      });


      }
      });














      draft saved

      draft discarded


















      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









      78














      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.






      share|improve this answer





















      • 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






      • 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 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


















      78














      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.






      share|improve this answer





















      • 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






      • 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 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
















      78












      78








      78







      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.






      share|improve this answer















      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      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 put sudo 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 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 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
















      • 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






      • 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 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










      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















      18














      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.






      share|improve this answer


























      • 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 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
















      18














      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.






      share|improve this answer


























      • 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 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














      18












      18








      18







      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.






      share|improve this answer















      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      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 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



















      • 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 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

















      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











      12














      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!






      share|improve this answer
























      • 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


















      12














      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!






      share|improve this answer
























      • 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
















      12












      12








      12







      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!






      share|improve this answer













      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!







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Aug 21 '14 at 17:30









      ruffyruffy

      12114




      12114













      • 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





















      • 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



















      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













      11














      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.






      share|improve this answer


























      • 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
















      11














      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.






      share|improve this answer


























      • 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














      11












      11








      11







      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.






      share|improve this answer















      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      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



















      • 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











      6














      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






      share|improve this answer






























        6














        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






        share|improve this answer




























          6












          6








          6







          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






          share|improve this answer















          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







          share|improve this answer














          share|improve this answer



          share|improve this answer








          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























              4














              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)






              share|improve this answer
























              • This helped me to unlock .iso from glitchy Virtual Box.

                – Nakilon
                Sep 28 '14 at 18:54
















              4














              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)






              share|improve this answer
























              • This helped me to unlock .iso from glitchy Virtual Box.

                – Nakilon
                Sep 28 '14 at 18:54














              4












              4








              4







              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)






              share|improve this answer













              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)







              share|improve this answer












              share|improve this answer



              share|improve this answer










              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



















              • 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











              0














              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.






              share|improve this answer




























                0














                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.






                share|improve this answer


























                  0












                  0








                  0







                  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.






                  share|improve this answer













                  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.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Mar 23 '15 at 15:28









                  camslicecamslice

                  1




                  1






























                      draft saved

                      draft discarded




















































                      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.




                      draft saved


                      draft discarded














                      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





















































                      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







                      Popular posts from this blog

                      flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

                      Mangá

                      Eduardo VII do Reino Unido