Fixing Mac OSX File Permissions and ACLs From the Command Line
Tags: Apple, OSX, permissions, unix
Recently the hard drive in my mac mini running Mac OSX Leopard (10.5) failed. Luckily I had time machine backing it up to an external USB disk. Now, since I had to replace the drive and rebuild my system anyway I figured, why not upgrade to Snow Leopard? Planning to just pull what I needed off the backup drive manually I went ahead with the upgrade. There aren’t too many files on this machine that I depend on. Just some ssh keys, gpg keys and random documents scattered about here and there. So I upgraded, installed my apps and copied my files from the backup. Everything was going smoothly until I tried to actually write to one of the files I copied from the backup drive. This is when I started getting permission errors.
Here’s what happened when I tried to update my ssh known_hosts file:
airbag:~ keith$ echo foo > .ssh/known_hosts -bash: .ssh/known_hosts: Permission denied |
Huh? But I own this file…dont I?
airbag:~ keith$ id uid=501(keith) gid=20(staff) groups=20(staff),402(com.apple.sharepoint.group.1),204(_developer),100(_lpoperator),98(_lpadmin),81(_appserveradm),80(admin),79(_appserverusr),61(localaccounts),12(everyone),401(com.apple.access_screensharing) airbag:~ keith$ ls -al .ssh/known_hosts -rw-r--r--@ 1 keith 502 56140 Mar 25 2009 .ssh/known_hosts |
I do own it… And so began much head scratching and man page reading.
Well, as it turns out I forgot to look at the file ACLs…
airbag:~ keith$ ls -le .ssh/known_hosts -rw-r--r--@ 1 keith 502 56140 Mar 25 2009 .ssh/known_hosts 0: group:everyone deny write,delete,append,writeattr,writeextattr,chown |
Well no wonder, the ACL is set to deny write,delete,append,writeattr,writeextattr and chown from everyone! Let’s get rid of that.
airbag:~ keith$ sudo chmod -N .ssh/known_hosts Password: |
That ought to do it. The -N flag says get rid of all the ACL info on the file. You could also update this to be just right for your user or group but I’d rather use only the standard unix permissions.
airbag:~ keith$ ls -le .ssh/known_hosts -rw-r--r--@ 1 keith 502 56140 Mar 25 2009 .ssh/known_hosts |
Seems to have removed all ACLs from the file. I wonder if we can write to it now…
airbag:~ keith$ echo foo >> .ssh/known_hosts airbag:~ keith$ |
And there you have it, the file is writable once again. Now its time to get some real work done!
June 30th, 2010 at 1:06 pm
This post is wonderful! Just cleared up an issue with Parallels and a backup from TimeMachine just like you described! Thank you!
[Reply]
October 18th, 2011 at 8:26 pm
This was a really useful post! After using Migration Assistant in Lion, I did what I could to move all my files from the user account created via MA to my user account when I set up my system. Of course, I was getting prompted by Finder to move any of the files from the old user – super annoying!
I tested using chmod -N fixed on one of my files and sure enough, it does the trick! Unfortunately I have a *ton* of files that have this problem.
Is there any kind of shortcut or guidance you could give in order to do this for multiple (i.e. thousands of) files?
Thanks so much for the great article!
[Reply]
Keith Reply:
October 18th, 2011 at 8:34 pm
@Erin, you could add the -R (recursive) flag to chmod which will update anything below the current directory. For instance if your problem files are located in /Volumes/foo you could run this:
chmod -R -N /Volumes/foo
However, if you’re dealing with system files, you may want to be a bit more clever and script something to enumerate the list of files with broken permissions and loop through them individually.
[Reply]
November 28th, 2011 at 4:55 pm
Rather than deleting the ACL in its entirety, I chose to give myself more specific permissions for the file. In my case .ssh/config had these settings:
I ran
chmod +a# 0 "ben allow write" config, after which I could modify the file. The permissions finally look like this:[Reply]
December 8th, 2011 at 9:27 am
[…] Your file may have an ACL that prevents writing by the current user. To view ACLs for a file, issue ls -le. Use chmod to modify ACLs. Run chmod -N to remove the ACL. […]
January 5th, 2012 at 5:04 pm
that was exactly what I needed! I had restored from a Time Machine backup and was everything looked OK on permissions, but I could not delete a file without an username and password prompt. It turns out deny delete was on. Removing the ACL was exactly the thing that worked. I used the chmod -R -N command on each folder in my home directory. Thank you!
[Reply]
March 25th, 2012 at 9:53 am
I’ve been trying to fix this for weeks, I finally stumbled across your blog via google. Thanks so much for posting this, it helped fix my issue with restored files from a Time Machine Backup!
[Reply]
April 20th, 2012 at 2:16 pm
Yesterday I started suffering with a borrowed Mac mini whose Leopard needs to be reinstalled ASAP but I got no time for that now. Problem is, every new user account I create comes with file permissions problems that Disk Utility won’t repair. Every single file in this machine that comes from any Mac or PC over the network can’t be edited, moved or deleted without typing first an admin’s password.
Today Google brought me to this blog and I found the answer: obliterate the entire ACL! =D I can now use the backup from another Mac mini with Snow Leopard I’ve been working on for months without the annoying “Enter an admin password” requisite.
Thanks! That “-N” was my salvation.
[Reply]
April 22nd, 2012 at 2:05 pm
Thanks so much. Helped me out big time when I changed all my permissions on my App Support folder (which was not a good idea, as it turns out).
[Reply]
May 6th, 2012 at 3:36 am
After doing a migration assistant from a time machine backup, I couldn’t move or delete a file without typing my password. The recursive option worked perfectly. Thank you!
[Reply]
November 5th, 2012 at 12:15 pm
Very helpful, especially with -R !
[Reply]
December 5th, 2013 at 8:21 am
excellent, solved all my problems
[Reply]