Update: This is a bigger bug than I thought.
I just went through a nightmare of permissions errors that caused my computer to stop booting for several hours.
I was trying to share my whole hard drive, and not just my home folder. I went to System Preferences > Sharing > File Sharing and added my hard drive as a shared folder. I noticed that all my shared folders had these sharing permissions:
Me: Read & Write
Users: Read & Write
Everyone: Read Only
It freaked me out that everyone would have read access to my drive;
this sounded like OS X’s guest access. (Update: This IS OS X’s guest access, sharing all of your files with no password!) Furthermore, it wouldn’t let me select no access, so I was ([RIGHTFULLY]) worried that my drive was open to the public.
In finder, I used get info and saw similar permissions:
Sharing & Permissions:
System: Read & Write
admin: Read & Write
everyone: Read only
Since it says “Sharing” above it it, I clicked the lock to unlock, authenticated, and changed everyone’s access from “read only” to “no access”. Oops.
Clearly this is for general filesystem permissions and not for AFP file sharing. First, I couldn’t install a software package (it hung on examining additional volumes…). So I tried to reboot, and my computer hung on the grey screen with the little spinny dots circling around themselves. I’d just locked my system out of itself.
I tried booting into single user mode (hold down command S) and running fsck to fix the drive. No dice.
Then I booted with the Leopard install disk. I ran Disk Utility and tried to Repair Permissions. It failed, saying something like “Unsuccessful – an internal command reported failure”. The same thing happened with Check Permissions. Crap.
I tried booting with the Techtool Deluxe CD that comes with Applecare, but apparently this isn’t even compatible with Leopard — it wouldn’t even boot to CD for me, on several tries.
I tried some of the steps from the article Unable to move, unlock, or copy an item in Mac OS X:
defaults write /Library/Preferences/SystemConfiguration/autodiskmount AutomountDisksWithoutUserLogin -bool true
Next it said to run
but in Leopard there is no rc in /etc/. So much for that.
By the way, in the article Troubleshooting permissions issues in Mac OS X, it says
1) open Terminal
sudo rm -rf.
I don’t care what it says, NEVER RUN THIS COMMAND. That’s the most dangerous command you can run in unix.
Anyway, finally, I took it into my own hands: I booted into single user mode, and typed
chmod -R 777 /
This would recursively give everything access to everything and is the loosest form of permissions I could think of. It would screw up all of OS X’s permissions, but hopefully it would at least give OS X access to the drive again and disk utility could fix them.
Disk utility was able to run and spent a couple hours fixing permissions on the drive. After that I was able to boot again. Yay! I went back and changed the everyone permission on Macintosh HD to read only.
I got several kernel extension errors – OS X complained about not being able to load my MOTUFireWireAudio.kext extension (for my firewire audio interface), LittleSnitch.kext (little snitch), and fusefs.fs (NTFS mounter that parallels uses to mount XP drives). For the kernel extensions, I used terminal and typed:
The extensions mentioned above had the wrong permissions (still 777). I think this is because they didn’t come with OS X by default so repair permissions didn’t know what to do with them. So I typed:
chmod -R 755 MOTUFireWireAudio.kext/
chmod -R 755 LittleSnitch.kext/
And they worked better. These files are actually OS X packages / directories, hence the trailing slash and the -R flag. My MOTU driver started working but wouldn’t open the configuration application automatically, so reinstalling it and rebooting fixed it.
You can also test your kernel extensions by running:
kextload -t MOTUFireWireAudio.kext
for example. That gave me verbose output that the permissions were wrong.
I reinstalled parallels but fusefs.fs still wasn’t loading. So I typed:
chmod -R 755 fusefs.fs
Reinstalled parallels again, rebooted, and it worked.
I think things are ALMOST back to normal! Jeez.
Lesson learned: Don’t freak out if you see “everyone” having “read only” access in sharing system preferences. It refers to linux permissions, not to Mac OS X’s guest file sharing access. Lesson Learned: If you have this bug there is no way to securely share your files in Leopard, and trying to change the permissions for user “Everyone” with get info may hose your system.
20 Responses to “Permissions error SNAFU causes Leopard not to boot [solved]”
Leave a Reply
You must be logged in to post a comment.