The Basics: Permissions, Accounts, and File Organization

The Basics: Permissions, Accounts, and File Organization

Because of its Unix heritage, Mac OS X is a true multi-user operating system from the ground up. Yet some people have used Mac OS X for many months without fully realizing what this means—as the only user of their Mac, they press the power key and it simply boots up and runs, much like a Mac running OS 8 or OS 9. To many other users, a multi-user OS just means that several people can use the Mac without sharing the same Documents folder and preference files.

The truth is that the multi-user architecture of Mac OS X offers so much more than separate Documents folders. It is a powerful system of files, folders, and volumes, with varying degrees of access to those items given to individual users. Everything from setting preferences to installing software, from opening files to emptying the trash, is affected by this system; as a result, OS X provides levels of security and flexibility heretofore unseen on the Mac platform. Understanding the concepts of user accounts and privileges, and understanding the file structure of Mac OS X, are the first steps towards becoming a true Power User. In fact, understanding these topics is vital to mastering many of the topics discussed later in the book.

Because these issues are important, and because Mac OS X accommodates so many different levels of users, I'm going to start at a more basic level in Chapter 1 than in subsequent chapters, to ensure that I thoroughly explain these concepts. Consider this chapter the foundation on which you'll build your power user skills.

Permissions Explained

Users of Mac OS 9 and earlier may remember setting up File Sharing privileges—when File Sharing was enabled, each "shared" file had a set of privileges, set manually by the user sharing it, that told the OS which remote users could access it. Since Mac OS X is based on Unix, it inherits the Unix system of file permissions (also called privileges). This system is similar to File Sharing privileges, except that in OS X every file and folder has a set of permissions (some set by users, most set by the OS itself), and these permissions apply to everyone, whether they are connecting remotely or sitting in front of the host computer. To put it simply, OS X keeps track of which users can open each document, folder, or application, and which users can edit each individual file. (In OS X, the terms "open" and "edit" are actually called "read" and "write.")

You can see an example of permissions by selecting a file in the Finder (a document in your Documents folder is a good one to choose), and then selecting File Get Info. In the resulting Info window, you'll see a section called Ownership & Permissions. Clicking the disclosure triangle will expand this section to show the permissions given to this file. The Info window for a document from my Documents folder is shown in Figure 1.1.

Figure 1.1: The Get Info— Ownership & Permissions window for sample.doc

The owner of the file is me, frakes (the "Me" after the user name tells you that the owner is the current user), and I have read and write access to the file. You also see two other sets of permissions: Group and Others. In addition to an owner (the user who controls access to the file — generally the person who created it), every file belongs to a group, which is simply a defined subset of all users who have their own access privileges to the file. The group is automatically set to the default group for the owner—in this case, staff—and set to Read only.

These settings can actually be changed to provide certain other users with a particular level of access, without opening up such access to everyone. (I'll talk more about groups and group access later in this chapter, but for now just remember that they are there; they can be extremely useful once you learn how to use them.) Finally, the Others permission setting is used to set privileges for users who are neither the owner of the file nor part of the group assigned to the file; think of this as "everyone else." The default setting for others is Read only. (See "What Permissions Really Mean" for more info on the various levels of access.)


Mac OS X permissions are not enforced under Mac OS 9. If you reboot into OS 9, you're free to do anything you want, to any file you want—and so is anyone else.

Understanding what permissions are isn't too difficult; comprehending how they work and why they work the way they do can be quite confusing. The first step towards that goal is understanding user accounts.

Understanding User Accounts

Mac OS 9 and earlier were essentially single-user operating systems. Sure, Mac OS 9 had the less-than-perfectly-implemented Multiple Users feature, but it was just that—less than perfect. Mac OS X is a true multi-user system, meaning that whether you realize it or not, you're no longer the only user of your machine. In this section, I'm going to explain what "multiple users" means in a practical way: how files and folders are organized, what users do and don't have access to, and more.

User Accounts and File/Folder Organization

At the topmost level of your Mac OS X hard drive (this is called the root level of the drive), you'll see a folder called Users. This folder contains all user-level files for all users of your computer. Within this folder, each user has their own individual folder, the name of which is their "short" username (I'll talk more about short and long usernames in a bit). This folder is called the user's home folder or directory, and is generally identified with the abbreviated pathname ~/. Thus, on my computer, my home directory is located at /Users/frakes (Figure 1.2). Within each home folder are several folders that were automatically created when the user account was created: Desktop, Documents, Library, Movies, Music, Pictures, Public, and Sites. In addition, a user's home folder can also contain any other files and/or folders the user has placed there.

Click To expand
Figure 1.2: A typical home user folder

The important thing to note about home directories under OS X is that with the exception of the Public and Sites folders (which are accessible by other users), files, folders, or applications stored inside your home folder are for your eyes only, and unless you explicitly change their permissions, no one but you will be able to edit them, or even view them. Your user folder is yours and yours alone. In fact, the Desktop that you see is actually a folder called Desktop within your user folder. Each user has their own Desktop, so anything you save or copy to the Desktop will be visible and accessible only to you.

However, user folders aren't just for security. They also provide an enormous amount of flexibility between users. In addition to documents, folders, and applications, user folders also store each user's preferences (in ~/Library/Preferences). This means that any settings or changes you make to your Mac—your desktop picture, your e-mail account information, your web browser bookmarks—will apply only to you, allowing each user to customize OS X to best serve their own needs. When you log in, the OS uses your preferences and restores the environment to exactly the state it was in when you last logged out. This is important to note because it means that as you go through this book, many of the neat tricks and customizations you find will only apply to your personal account, thus preventing you from annoying or disrupting other users.


When I said that all preferences apply only to the user who set them, that wasn't entirely true. There are a few exceptions to this rule; for example, network settings apply to all users, and therefore can only be changed by an administrator. I'll talk more about which settings are system-wide in Chapter 2, "Sensational Setup."

User Levels

As I previously mentioned, every user of Mac OS X has their own account. Each of those accounts has one of two levels of access: normal and administrative.

  • Normal users Normal users have full access to their own user folder and to other users' Public folders. They can also launch applications located in the /Applications directory, and can change user-specific System Preferences (Desktop picture, views, Dock settings, as well as their own account password). However, that's basically the extent of their access. Outside of their own user folder, they have only Read access (except for other user folders, for which they have no access at all). In fact, a normal user cannot even create a folder or save a document outside of their own home folder.

  • Admin users Admin users do not have complete run of the house, but they are much less limited than normal users. Admin users can install new applications in the /Applications directory, can change system-level System Preferences (Network, Accounts, Sharing, Software Update, etc.), can install fonts and other system add-ons, can create folders and save documents almost anywhere on the drive, and can use system-level utilities such as Disk Utility and NetInfo Manager. The first account created under Mac OS X (the one you created when you first installed OS X) is an admin-level account by default, since every Mac OS X computer must have at least one administrator.

You can view user levels in the Accounts panel of the System Preferences application (Figure 1.3). We'll talk more about the use of this panel when we talk about creating and editing user accounts later in the chapter.

Click To expand
Figure 1.3: User levels, as shown in the Accounts panel of System Preferences

Despite having a higher level of access, even admin users cannot access other users' private folders, nor can they make changes to certain system-level folders (such as much of the System folder at the root level of the hard drive)—at least not without help. Although I said that there are only two levels of accounts in Mac OS X, this is technically not true. There is a third level of access in Mac OS X called root access that has complete control over everything, regardless of permission or location. However, you cannot simply assign root privileges to particular accounts; Mac OS X actually has a separate root account (disabled by default, for obvious security reasons). In order to gain root access you must log in as the root user. I'll talk much more about the root user, as well has how to temporarily gain root access from an administrator account, later in this chapter.

It is important to understand the differences between these levels of access, as many of the tips discussed in this book require admin access, and some require at least temporary root access. As I mentioned in the Introduction, I've noted the level of access required for each procedure.

Other Uses for User Accounts (besides Other Users, That Is)

User Level:






At this point you may be saying to yourself "OK, I'm the only user of my computer, and I have admin access by default, so why do I need to know about user accounts?" That's a good question. In addition to the importance understanding user accounts and permissions has for fully understanding OS X as a whole, there are several reasons I recommend creating other users accounts that have little or nothing to do with multiple users:

  • Troubleshooting While Mac OS X is incredibly stable, the truth is sometimes things go wrong. When you experience a computer problem, the first step you should take towards finding a solution is always to narrow down the possible causes. In Mac OS 9, you held the shift key down to start up without extensions; if your Mac then worked fine, you had isolated the problem to a startup file conflict. In Mac OS X, because each user account has a different set of preferences, support files, and startup/login files, the first thing you want to do is to find out if your problems are caused by your account or by a larger system issue. A helpful way to do this is to create a new account (now, before you have problems), name it something clever (I call mine "Trouble"), and then never use ituntil you have a problem. If that happens, log out of your own account, log back in under your troubleshooting account, and see if the problems are gone. If they are, you've just isolated your problem to something in your own account (~/Library files, Login items, etc.), and that's where you should start looking for the cause. If the problems still exist, then the cause is system-wide.


    I recommend that you give your troubleshooting account admin access as discussed later in the chapter. If you ever find yourself in an emergency where you need admin access but you can't log into your normal admin-level account, having an extra admin account can be a lifesaver.

  • Testing Software If you're an aspiring power user, chances are that at some point you've downloaded "beta" software (or even—gasp—"alpha" software). In other words, you've tried out software that isn't quite ready for prime time. Although a lot of beta software is very stable, some isn't, and you may have experienced crashes or other problems. Even if you're not that brave, at some point you may have installed software just to check it out, and later decided that you didn't really like it, but you couldn't figure out how to get rid of all the support files that the software installed. My approach to these situations is to create an extra user account just for testing out software. You can run the alphas, betas, and "just curious" software from this account until you've either decided you want to use it in your main account or decided you want to get it off your Mac as soon as possible. Whatever you decide, your personal account—the important one you can't afford to screw up—should be unaffected.

  • Guests We've all had a friend who needs to borrow our laptop to type up a report, or asks to use our computer to do their taxes, or is just hanging out and wants to browse the Web. We let them (because we're nice people, of course), but the next time we sit down at our computer we find that our Desktop is a mess, or our application preferences have been changed, or, worst case scenario, an important document was accidentally deleted! A great solution is to create an extra account, call it "Guest" (or something a bit more clever), and then set it up for just these situations. I've got my guest account configured with limited access (see "Creating User Accounts" later in the chapter) and with just the essentials in the Dock: web browser, word processor, spreadsheet, etc. You can even set up the account with no password so that anyone visiting or borrowing your computer can simply click on the "Guest" icon at login and be on their way.

  • Remote access and file sharing In addition to allowing others to use your computer locally (sitting in front of it), user accounts also control who can access your Mac remotely (over the Internet, via your home or office LAN). If you want someone to be able to access files on your computer, that person must have a user account on your computer—even if they will never use the computer in person. (I'll talk more about remote access and file sharing in Part III, "The Internet, Networking, Sharing, and Printing.")

As you can see, "multiple users" doesn't necessarily mean "multiple people using the computer." I hope these suggestions will get you thinking about other ways to take advantage of the security and flexibility provided by multiple user accounts.

Why Are There So Many Copies of So Many Folders? (OS X File/Folder Organization)

I previously discussed the flexibility that user accounts provide, especially in providing a way for users to customize their individual computing environments. However, this versatility also creates new challenges that are not present in single-user operating systems. For example, what if you or another administrator of your Mac wants to install a system add-on or utility, and wants the effects or features of that software to be applicable to all users? Or, at the opposite extreme, what if some software needs low-level access to the operating system and needs to ensure that nosy users don't remove installed files?

Fortunately, the way Mac OS X is organized provides solutions to these dilemmas. Unfortunately, this organization can be quite confusing for the user (even for experienced users). If you truly want to master Mac OS X, understanding how files are organized is just as important as understanding permissions and user accounts; many of the tips and tricks discussed in this book require that you be familiar with OS X's file system. With that in mind, I'm going to explain the various folders and folder levels and their purposes.

Domain/Directory Levels

If you've done any digging around on your OS X hard drive, you've most likely discovered a number of "identical" folders in different places. In reality, these similarly named folders are not identical; in fact, they serve different, but parallel, purposes. This parallel structure is due to the fact that Mac OS X has three different levels of system and user support, called domain levels. These three levels are called the system, local, and user domains. Each of these domains provides a different level of support, and a different degree of access to its files and folders; a summary of each follows.

  • System The system domain is represented by the directory /System at the root level of your hard drive. The contents of this folder (which are effectively the contents of /System/Library, as that is the only folder contained in /System) comprise the entire operating system. With a few exceptions, everything inside was installed by the Mac OS X installer or by Apple updaters (those exceptions being a few third-party installers that require very low-level access to the OS). The contents of this folder are protected by the OS and are not easily modified—and for good reason: modifying files in the /System directory is the easiest way to screw up your OS! If you want to witness this security in action, try deleting a file or folder, such as /System/Library/Keyboard Layouts. (Go ahead, try to drag that folder to the trash, I'll wait.) You'll receive an error message that says, "The operation could not be completed because this item is owned by root." Unless you have root access, most of the /System directory is off-limits. Think of /System as the foundation of the OS—you can remodel what's on top of it, but you don't want to start messing with it unless you really know what you're doing.

    Click To expand
  • Local The local domain is represented by the /Library and /Applications folders (at the root level of your hard drive). These directories provide a way for administrators to provide resources to all local users of the computer. You'll notice that the contents of /Library look similar to the contents of /System/Library. Whereas almost everything inside/System/Library is installed by the OS X installer, /Library is largely populated by support files and system add-ons installed by administrators or software installers. The /Applications folder contains any applications you or another administrator have installed there; much like the resources in /Library are available to all users, the applications installed in /Applications can be used by all users. While the contents of these two folders are not modifiable by a normal user, any administrator can make changes.

    Click To expand
  • User The user domain is represented by each user's home folder (~/). As described in the sidebar "Dissecting the Contents of Your Home Directory," each user folder has its own Library and Applications directories (referred to by the paths ~/Library and ~/Applications). While support files and other resources located in the ~/Library folder work in much the same way as files located in /Library and /System/Library (and the folders inside ~/Library look very similar to those in the other two Library directories), those in ~/Library, the user-level directory, are available only to the particular user whose user folder contains them. Likewise, if a user creates their own Applications folder as suggested earlier in the chapter, any applications installed in ~/Applications will only be available to that particular user.

  • Files generally get installed in ~/Library or ~/Applications for two reasons. First, when an admin decides that they want to make certain files or applications available only to themselves or to a particular user, the administrator will install files in their own or a particular user's directory. Second, recall that a normal user cannot modify any folder outside of their home directory. Thus, if a normal user wants to install an application, system add-on, or other /Library-level file, they must use their own ~/Library and ~/Application directories.

    Click To expand

    There is actually a fourth domain level in Mac OS X, the Network domain. If you are connected to a network (most likely a local area network, or LAN), a central server can host this Network domain, and the corresponding /Library directory. This /Library directory can contain resources and support files available to all users on the network. However, as such a configuration is rare for the average user of Mac OS X, and the presence of such a Network domain does not really affect the discussion at hand, I'm not going to spend much time on it.

  • A good example of a group of parallel folders that illustrates the concepts discussed in this chapter is the way Mac OS X stores fonts. Fonts that are installed by the Mac OS X installer are stored in /System/Library/Fonts. Fonts installed by applications or by administrators for use by all users are located in /Library/Fonts. Fonts installed by a single user, or by an administrator for use by only a single user, are located in ~/Library/Fonts. All users can take advantage of fonts stored in /System/Library/Fonts and /Library/Fonts, but user-level fonts (those stored in their own ~/Library/Fonts) are only accessible by the user in whose ~/Library directory the fonts are located.

  • Another good example of parallel Library folders is folders that hold preference files. The folder /Library/Preferences contains system-level preference files that affect all users, such as login window prefs, sharing and firewall prefs, power management prefs, and serial numbers for applications available to all users. These preferences generally require administrative access to change. Each user also has their own ~/Library/Preferences folder, holding all of their own preference files. This system is actually quite powerful, as it allows for both personal and system-wide preferences. (You'll notice that there are relatively few preference files in /Library/Preferences; this is a testament to how much of OS X is configurable by each user individually.) Also note that there is no /System/Library/Preferences directory. This makes sense if you think about it, as /System shouldn't be modified.

What do these domain levels mean to you? First, you should now have a better idea of how OS X keeps track of single-user versus all-user versus system-level files. But perhaps more important for this book, understanding these domains should help you understand how changes you make to files or folders will affect your own user account, other user accounts, or the system as a whole. You also now know where to put something or edit something depending on which accounts you wish to affect. This knowledge will come in handy as you experiment with various tips and tricks throughout the book.

The Man behind the Curtain: NetInfo

If you've come to Mac OS X from earlier versions of the Mac OS, you may be wondering where OS X stores all of its info on users, user accounts, and the like. The answer is a file called the NetInfo database. Since we'll be working with this database at various points, it's helpful to talk briefly about what it is, what it does, and how to work with it.

What Is NetInfo?

NetInfo is a central, system-level database (meaning it cannot be modified without administrator or root access) that stores network and administrative information. This data includes information on all user accounts (usernames, file locations, group memberships, etc.), groups, access levels, network domain information, file sharing services, printer info, and more. Basically, any kind of network-related data (remember, in Mac OS X, even local accounts are "network-related") is stored in the NetInfo database.

The information in the NetInfo database is stored hierarchically: a root NetInfo domain contains various directories, and each directory can contain further directories or properties, which are the actual settings stored in the database. For example, the "real name" for my user account, "Dan Frakes," is stored in a property in the NetInfo database called realname, located at: /users/frakes/realname. Note that while NetInfo paths look very much like file paths (/Users/frakes/), they are not the same. They simply look similar because both NetInfo and the Mac OS X file system are organized hierarchically.

Some of the info in the NetInfo database is maintained by the system and is accessible and edited via other methods (user accounts, for example, are set up via System Preferences, as explained later in the chapter). However, certain information, such as groups and group membership, is only configurable by editing your NetInfo database. How to do this is our next topic of discussion.


NetInfo is actually a pretty complicated system, too much so to go into more detail here. However, Apple has provided a rather thorough description of it in the form of a document called Understanding and Using NetInfo. You can download the PDF file from or

Working with NetInfo

The NetInfo database is physically located at /var/db/netinfo/local.nidb, but you can't access the database in the Finder without root access. So how do you work with it? There are actually two ways: Terminal and NetInfo Manager. Of course, given the importance of the data managed by NetInfo, both methods are only available to an admin-level user.


Making changes to your NetInfo database can have drastic consequences. The information stored in the database is vital to your Mac's operation, and making changes to items you aren't familiar with can cause problems such as not being able to access files or not being able to boot up your computer. Before making any changes to NetInfo, you should back up your NetInfo database as described in "Backing Up and Restoring the NetInfo Database."


You can access and edit your NetInfo database from the command line using the Terminal application (/Applications/Utilities/Terminal). In fact, OS X has a built-in Terminal command for doing so: niutil (which stands for NetInfo utility). Using this command you can create, rename, and delete NetInfo settings, as well as find out current settings. We'll actually use this command later in the book (see Appendix B).

However, although using Terminal to edit your NetInfo database is fast and convenient if you know exactly what you want to do (including exactly which property you wish to modify), it's not very intuitive for those who are not experts in the various directories and properties managed by NetInfo. A better solution can be found in the NetInfo Manager application.

NetInfo Manager

The NetInfo Manager application (/Applications/Utilities/NetInfo Manager) provides a graphical interface to the NetInfo database. It allows you to quickly view current database settings, and—with administrative access—to change, add to, or delete settings. While all of the possible things you can do with NetInfo Manager are beyond the scope of this book, I want to briefly show you how it works in general, since we'll be using it at various points in the book to do NetInfo-related things.

To use NetInfo Manager, you simply launch it like any other application. If you simply want to view settings, you can dig right in. However, if you want to edit settings, you need to authenticate by clicking the "Click the lock to make changes" button at the bottom of the window. You will be asked for your username and password; assuming your user account has admin privileges, entering your username and password will give you temporary Write access to the NetInfo database (remember what I said about backing up your database before making any changes).

I mentioned previously that the NetInfo database is hierarchical in its organization; the NetInfo Manager window reflects this organization. In fact, if you've ever viewed windows "by Column" in the Finder, or used the expanded view in an Open/Save dialog, the top half of the NetInfo Manager window should look familiar. In Figure 1.4, I've navigated to the NetInfo directory for my own user account, frakes. You can see the root level of the database in the left window (/), and all of the directories located at the root level in the middle window. I've selected the users directory, which provided me with a list of all users on my Mac. Selecting my username provides me with a list in the bottom window of all the properties associated with my account.

Click To expand
Figure 1.4: User account settings in NetInfo Manager

Some of the properties listed should make sense (realname is my "full" name, hint is my password hint, home is the location of my home folder). On the other hand, some probably don't mean much to you right now. That's normal—we'll talk about some throughout the book; others you may never care about. What's important is to see how NetInfo Manager lets you view and work with the database.

If you want to edit a value, you simply double-click it (provided you've authenticated as described here). The field will become an editable text field, and you can type in the new value. If you really know what you're doing, you can even add properties, values, and directories. When you're finished, you simply select Domain Save Changes. Or, if you decide that you want to discard any changes you made, you can instead select Domain Revert to Saved.

At this point, I encourage you to simply click through the various directories in NetInfo Manager to get a feel for how it is organized and what types of information are stored in the NetInfo database. Unless you're already familiar with NetInfo, do not make any changes yet; later in this chapter you'll get your first taste of actually working with the database.


You'll notice in Figure 1.4 that there are quite a few users listed. Only four of those users (frakes, jennifer, power, and trouble) are actually user accounts set up in the Accounts panel of System Preferences. The rest are system-level accounts used by the operating system for various tasks and purposes, and are present on all Mac OS X computers. You generally do not want to make changes to these accounts.

Backing Up and Restoring the NetInfo Database

Because making changes to your NetInfo database can have such drastic consequences, you never want to make changes without first making a backup of the database itself. The steps here show you how to back up your NetInfo database, and how to restore it, if necessary.

Backing Up the NetInfo Database

User Level:



all users



Although NetInfo Manager supposedly allows you to make a backup of your database from within the application (Management Save Backup), many users have found this method to be problematic; sometimes it works, sometimes it doesn't. To make matters worse, sometimes you get an error, sometimes you don't—and the error doesn't necessarily correspond with whether or not it works! I've found that a much more reliable way to backup your database is using Terminal:

  1. Launch Terminal (/Applications/Utilities/Terminal).

  2. At the prompt, type the following (all on one line, preserving all spaces as indicated; case is important in Terminal, so make sure you copy case correctly):

         cd /private/var/db/netinfo <RETURN>
         sudo cp -R local.nidb local.nidb.backup <RETURN>
  3. When you are prompted for a password, type your normal account password (you must be an admin user, of course).

The cp command copies the database local.nidb to a new file in the same directory called local.nidb.backup; since the database is actually a directory of files, the -R option tells cp to copy the directory and all files within it. The sudo command—which asked for your password—provides you with the temporary root access needed to be able to write a new file to that directory. (You'll learn more about sudo in "Getting to the Root of It," later in this chapter.)

Now you've got a backup copy of your NetInfo database. It's a good idea to use this procedure each time you make changes to NetInfo. In fact, if you're not the type to back up your computer regularly, it's also not a bad idea to back up your database after adding, deleting, or modifying user accounts, since such changes are actually editing the NetInfo database. (If you're not the type to back up regularly, you also need to read Chapter 14, "Mac OS X Maintenance and Administrative Actions," as soon as possible.) If you're especially cautious, you can name the backup files differently each time you make changes to the database (local.nidb.backup1, local.nidb.backup2, and so on) so that you have a backup of each generation of changes. (If you don't back up to a new, differently named, copy each time, make sure you delete the previous backup copy before backing up again; you can do so using the following command in Terminal: sudo rm -R /var/db/netinfo/local.nidb.backup.)

Restoring Your NetInfo Database from a Backup

User Level:



all users



If you spend a lot of time working with NetInfo, there's a chance that at some point you'll make a mistake, or the database will become corrupt, or, for lack of a better explanation, your NetInfo database will just get screwed up. When this happens, you might see funny things like home folders not being where they should be, or you may not even be able to boot the computer—you never see the login screen. At this point, you'll be glad you made that backup, because the first step you should take in fixing things is to restore your NetInfo database from a reliable copy.

To do this, you need to boot into what is known as single-user mode. Single-user mode is a limited way of working directly with the file system of Mac OS X without actually logging in as a user. What you see in single-user mode looks a lot like what you'd see in a Terminal window—text on a black screen. The benefit of single-user mode is that in most cases you can use it even if you can't boot up or log in to OS X. (Even if you can log in, you should still use single-user mode to restore your NetInfo database, since the current database is in use when you're logged in and cannot be replaced).

  1. Reboot or start up your Mac; immediately press and hold command+S. You'll see a bunch of text scroll by, until you see the following:

         Singleuser boot -- fsck not done
         Root device is mounted read-only
         If you want to make modifications to files,
         run '/sbin/fsck -y' first and then '/sbin/mount -uw /'
  2. If you're having problems, the first thing you should always do when booting into singleuser mode is run fsck, which is OS X's built-in disk utility. Type the following at the prompt: /sbin/fsck -y <RETURN>

    If you get an error that the file system was modified, run the command again; keep running it until you get a message that everything is OK. (The fsck utility will be discussed in more detail in Chapter 14.)

  3. In order to access files on your boot volume, you need to mount the disk. Type the following command (note the space between uw and /): /sbin/mount uw / <RETURN>

  4. Use the mv command to rename the "bad" database from local.nidb to local.nidb.bad:

         cd /var/db/netinfo <RETURN>
         mv local.nidb local.nidb.bad <RETURN>
  5. Use the mv command again to rename the backup database local.nidb (all one line):

         mv local.nidb.backup local.nidb <RETURN>

    Note that if you're restoring from another backup with a different name, you should replace local.nidb.backup with the actual name of your backup database in the command above.

  6. Restart your computer by typing reboot <RETURN>. This command tells the computer to finish any disk writes that are in progress, and then restarts the machine.

When you reboot, OS X will use the newly restored NetInfo database.

The Last Resort: Rebuilding the NetInfo Database

User Level:



all users



I hope you never have to use this tip, because if you do, it means something has gone horribly wrong with NetInfo. However, the truth is that, well, it can happen. Sometimes the NetInfo database gets corrupted so badly that your Mac won't even start, and you either didn't make a backup, or your backup itself is damaged. In this scenario, your only hope is to wipe out the existing NetInfo database and tell Mac OS X that you want to start from scratch. Here's how:

  1. As in the instructions for restoring your database, start up in single-user mode (command+S at startup).

  2. At the localhost# prompt, use fsck to ensure that your drives are in good shape: /sbin/fsck -y <RETURN>. If you receive a message that your file system was modified, run fsck again, as many times as is necessary to get the message that your disk is OK.

  3. To mount the boot disk so that you can access the files on it, type the following (note the space between uw and /): /sbin/mount -uw / <RETURN>

  4. Type the following commands:

         cd /var/db/netinfo <RETURN>
         mv local.nidb local.nidb.deleted <RETURN>
         rm /private/var/db/.AppleSetupDone <RETURN>
         reboot <RETURN>

    The first command changes the name of the corrupt NetInfo database to local.nidb.deleted (so that OS X won't use it when you reboot). You could have deleted it using a different command in Terminal, but by renaming it you'll still have a copy in case it turns out the problem wasn't a corrupted NetInfo database. The second command deletes a file the operating system uses to keep track of whether or not you ran the initial account setup process. Once you delete that file, Mac OS X thinks that you need to set up your initial account again, and will launch the Setup Assistant the next time you boot into OS X.

  5. When your computer reboots, the setup assistant will ask you to set up a "first" user account. Be sure to provide the exact same short username you used for your original admin account (the one you generally use that has administrator privileges). This will cause Mac OS X to match your "new" account up with your existing user folder and all corresponding permissions. You may also need to go into the Users pane of System Preferences and re-create any other users you previously created (see "Creating User Accounts" in the next section). Again, be sure to use the exact same short usernames the original accounts used.


More info (and more advanced info) on recovering and replacing the NetInfo database can be found at and