Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Recover from a read-only top-level directory System
Editor's note: REVISED ARTICLE to reflect info from Apple's Knowledge Base.

I wish I had visited OSX Hints earlier ... I asked friend of mine, who I've trusted to always give me good advice, how I could get sendmail working on my TiBook. He said all I needed to do was type (in the Terminal) sudo chmod -gw /. Instead of this, I highly recommend this hint offered by jpbjpbjpb - it doesn't turn your disk into a read-only disk! Ok, well to be fair, we both had a few pints to drink that night.

If you you ever end up in the same situation, You can regain control by starting up in single-user mode (apple-S on startup), and when you get the command prompt you can type the following:
 % mount -uw /
% chmod 1775 /
% reboot
NOTE: This information was taken from Apple's Knowledge Base, article number 106464.
    •    
  • Currently 3.00 / 5
  You rated: 3 / 5 (1 vote cast)
 
[2,461 views]  

Recover from a read-only top-level directory | 5 comments | Create New Account
Click here to return to the 'Recover from a read-only top-level directory' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Default / permissions
Authored by: Mikey-San on May 28, '02 09:26:15AM

The default file mode/ownership settings for / are:

drwxrwxr-t

It's owned by root (of course), and belongs to the admin group.


-/-
Mikey-San
http://www.mikey-san.net/



[ Reply to This | # ]
Huh?
Authored by: Anonymous on May 28, '02 09:53:59AM

Remounting the disk after removing group write permissions is certainly not the correct solution. Using chmod should fix the problem.

Even more important than the technique used to restore permissions are the permissions themselves. 777 (rwxrwxrwx) is a bad idea. In most Unices, / has 755 root.wheel permissions (or similar). However, MacOS X does things quite a bit different than most other Unices in their out-of-the-box setup.

Sendmail can be convinced to run even if it disagrees with the permissions on your UNIX machine. If you aren't sure as to what or why the permissions are set the way they are on /, /etc, /var/mail, etc. (sendmail doesn't stop with just /), this might be a safer answer. To convince sendmail, simply uncomment the DontBlameSendmail line in /etc/mail/sendmail.cf.



[ Reply to This | # ]
How to see permissions of /
Authored by: sjonke on May 28, '02 10:35:18AM

This applies to wherever you are. If you type "ls -la" you will get a long listing that includes "." and "..". "." is the current directory and ".." is the one above you. In the case of being at at the root ("/") already, these are the same. Here's what I see: drwxrwxr-t



[ Reply to This | # ]
How to see permissions of /
Authored by: kbibb on May 28, '02 11:35:36AM

An easier way to see /'s permissions is to use

ls -ld /

The "d" lets you see the perms of the directory,
not the directory's contents.



[ Reply to This | # ]
daily.local
Authored by: thatch on May 28, '02 09:27:42PM

The default permissions is where the problem is. So, I just put this into the file at /private/etc/daily.local

#! /bin/sh

# extra daily tasks
# 1) clean up from apple installers
chmod go-w /

...

I got this from macosxhints forums and I believe it was suggested by mervTormel. Now every time the daily maintenance script runs it includes the fix in daily.local. No more worries.



[ Reply to This | # ]