Results 1 to 4 of 4

Thread: Moves home directories (Jazzbo)

  1. #1
    Join Date
    Jun 2002
    Campbell, CA, USA

    Lightbulb Moves home directories (Jazzbo)

    In this example, the non-root volume-name to which we're moving /Users is "freedom".

    The most straightforward way I know of to move your home directory from the root disk to your freedom volume is to mix a little Terminal action with NetInfo Manager. I know, I know: CCC and other sorts of cloning software exist, but I don't know how they work.
    Make certain that the disk volume to which you are planning to move /Users does not have "Ignore ownership on this volume" checked. Select the disk in Finder, Get Info, and look in the "Ownership & Permissions" area.
    Unlike TZ, I prefer to have the Users directory in the path to home directories. That segregates it away from other functional directories in the destination volume -- for instance, I have an Applications directory ("folder") next to Users on my /Volumes/Local volume (akin to your /Volumes/freedom volume).

    Note: For all Terminal sessions, you enter commands at a "shell prompt". It may show on your machine as a %, with the hostname, hostname and current path, or other info to its left. Also, you may see a # instead of a % ending the prompt string.
    After typing any command into the Terminal, wait for the prompt string to be printed again before you enter the next command!
    Note: Any line I show in the Terminal transcripts that starts with a # is a comment from me about what's going on, not something for you to type in.

    1. In Terminal, set a root password if you haven't already
    sudo passwd root
    (answer sudo's password prompt with your *own* password, then enter your new root-user's password twice: once to set it; once to confirm it)

    2. Log out of the desktop as yourself, and log back in as root.

    You may need to go into the Accounts preferences and change your login options to "Name and password", first.

    The reason for logging in at the desktop as root is that if you are logged in as a user whose home directory you're about to move, you have status files scattered under the user's home directory, and they'll be moved (copied) along with all the rest. That can seriously confuse your applications the next time you log in as a moved user. It can leave you locked out of apps and such.

    As well, your home directory -- and thus the path to all sorts of your resources, like your Library -- is looked up when you log in (or when a Terminal window is opened), and kept in memory from that point on. Ripping the home directory out from under a logged-in user by carrying out the rest of this procedure can have many unforeseen consequences.

    3. In Terminal, clone the Users directory from one location (I'm going to presume the root disk) to another (/Volumes/freedom in this sample).

    # Create the Users destination folder
    mkdir /Volumes/freedom/Users

    # Copy the contents of /Users into the new location
    ditto -rsrcFork /Users /Volumes/freedom/Users

    # Adjust filemode and group for the new Users directory
    chgrp admin /Volumes/freedom/Users
    chmod 1775 /Volumes/freedom/Users
    4. In NetInfo Manager, switch the home directory for each user under /Users to be under /Volumes/freedom/Users.
    a. Select the users table
    b. Unlock (lower left corner of the window)
    c. Select a user whose home directory is under /Users (yourself, for instance)
    d. Find the home directory entry
    e. Click your way in until you can edit the home path
    f. Insert
    /Volumes/freedom/ at the beginning
    g. Click to another field
    h. Command-S to save (answer yes to the update? dialogue box)
    i. When you've done all users: Management->Restart Local NetInfo Domains
    5. Move the old /Users aside and set a symlink to cross-connect it:
    # Rename the /Users directory
    mv /Users /Users.old

    # Set a symlink so /Users points to the new location
    ln -s /Volumes/freedom/Users /
    That's it. Log out and then back in as a moved user.

    6. When you're 100% satisfied that the move was successful, you can remove /Users.old from the root disk. Really easy, as your regular account, in Terminal:
    sudo rm -r /Users.old
    Once you've taken this step and removed /Users.old, you can't "fall back", as shown below.

    Until you remove it, you can fall back to it (below). Keep in mind, though, that the longer you run with the home directories on the other disk, the more out-of-date this old, fall-back root-disk-resident /Users.old will be.


    To fall back, log in as the root user, reverse step 5:
    ## NOTE: This is part of the Fallback routine!
    # Delete the symbolic link
    rm /Users

    # Restore /Users directory
    mv /Users.old /Users
    run NetInfo Manager, and re-run step 4, above, deleting rather than inserting /Volumes/freedom/ from the beginning of each home directory that you need to flip back to the root disk.

    Last edited by Jazzbo; 10-03-2004 at 06:29 AM. Reason: Provide the actual steps for the fallback procedure

  2. #2
    Join Date
    Jun 2002
    Campbell, CA, USA

    Default Jazzbo's notes on his approach to moving /Users

    Some rambling notes on my approach to moving /Users as above.

    1. By establishing a Users directory ("folder") under the non-root volume, we easily handle the case of having multiple accounts locally-defined on the host. Each user's home directory lives next to the others in (e.g.) /Volumes/freedom/Users/.

      The "extra" directory level (e.g. /Volumes/freedom/Users/momo) -- constrasted with TZ's approach of putting the username directories at the top of the volume (e.g. /Volumes/freedom/momo) -- flags for me that I've navigated to a home directory (under /Volumes/freedom/Users/) so I don't accidentally wipe out Rick's home directory from the root of /Volumes/freedom thinking it was, for example, a temporary transfer-from-Rick directory.

      It fits with what's a convention on Unix systems to group users' home directories inside directories dedicated to no other use, for clarity if nothing else.

      It is not law! What works for you works for you. If I were to dedicate a volume to nothing but home directories (which merges up TZ's and my approaches), I'd call the volume either /Volumes/home or /Volumes/Users, just to keep things clear to me.

    2. I like to install applications not provided stock with Mac OS X on the same non-root volume where I keep my home directory. Here's a sketch of what I do:
      # Home directories:
      # Third-party applications
      # Keep games out of Applications
      # For browser downloads
    3. One other trick. I put a symlink pointing to the current root-disk's Applications directory into my third-party applications directory, and I put a leading blank (space) in the name of the symbolic link file:
      ln -s /Applications /Volumes/freedom/Applications/\ root\ Applications
      The backslash (\) is needed in front of each of the blanks in the symlink filename for the shell to treat it as a single filename (instead of three if there were no backslashes). That's called "escaping" the spaces. Because the name of the symlink (" root Applications") starts with a blank, it sorts first in Finder. So it's always right at the top of the list (I use Columns mode in Finder, thank Bog!) when I open my non-root Applications folder.

      Now, in my Finder sidebar, I get rid of the quicklink to the root Applications directory, then drag in the Applications folder from my non-root disk. Its top entry always navigates to the current root disk's Applications directory, so I can switch boot disks and it still takes me to the Applications delivered with the OS on the disk that's currently booted.

    4. When you install a new OS image on a new volume and then boot it the first time, you'll wind up recreating the "501" account -- the very first user account on the host -- on the new root disk.

      The new installation (this is a brand new install, not an overlay with preserved configuration data) also creates a brand new NetInfo database on the new root disk.

      • If you're running with only one user, this is no big deal. Let it set things up, then:

        1. Set a root password
        2. Log out of the desktop
        3. Log back in as root
        4. Update NetInfo's home directory for the user account
        5. mv /Users /Users.old
        6. ln -s /Volumes/freedom/Users /

      • If you're running with multiple users, make sure the "501" first account is the same person previously defined as "501". You can run nidump passwd . (don't leave the dot out!) with the old root disk booted to inspect its passwd table -- the first number in an entry is the "uid" or userid number, and you're looking for "501" for the first account and all of the rest of the accounts in the 500 range. Keep track of the order!

        Then, before renaming the
        /Users directory, define the rest of the accounts in the Accounts preference pane. Do it in the right order -- ascending by uid number from 502 -- and they'll all match. Do it in the wrong order and your users will wind up owning each other's files. (We can fix that in NetInfo Manager if it happens, though.)

        In step 4, you need to update the home directory for each user.

  3. #3
    Join Date
    Jun 2002
    Campbell, CA, USA

    Default File-naming pitfalls and how to avoid (or deal with) them

    1. Blanks in volume names

    In "the shell" (in the Terminal app, for instance), blanks separate different "tokens" used as command arguments. For instance:
    ls My Great
    is actually asking the file-listing command (ls -- that's "ell-ess") to describe three separate files: My, Great, and! That's because the spaces in there break the "arguments" for the ls command into three. There are two ways to solve this, since we obviously intend to refer to a single file named "My Great":
    ls My\ Great\
    ls "My Great"
    In the first example, the backslash (\) character is used to "escape" the spaces, telling the shell that the "token" continues, including the space. This is not portable to other shells on other Unix systems!

    The second example shows the filename surrounded in double-quotes ("), which also makes it a single token. This one's portable.

    There are other characters besides spaces which can cause you grief in the shell. The basic list is:
    # not safe!
    blank tab newline carriage-return $ ! ( ) \ < > ? [ ] { } | ` ' " # & * /
    Which is to say, most non-alphameric characters other than:
    # safe!
    . _ , - + ~ % ^ =
    but beware of using tilde (~) or dot (.) as the first character in a filename.

    How does this apply to moving /Users from the root disk to another volume? If you put any of the unsafe characters -- including space -- in the volume name to which you are going to move /Users, then you are going to have to find a way to escape those characters, either with backslashes, quoting, or both (for instance, $ still has a special meaning to the shell even inside double-quotes and also requires a backslash).

    With spaces, you wind up needing something like this:
    ditto -rsrcFork /Users /Volumes/My\ New\ Hard\ Disk/Users
    and must remember to get those backslashes in there every time you refer to that volume in Terminal.

    Recommendation: Do not put any of the unsafe characters into your volume name(s) if you intend to move /Users to it (them) from the root disk.

    Recommendation: If you want multiple words in a volume name, use TZ's trick of replacing spaces with underscores, like: /Volumes/My_New_Hard_Disk

    Addendum: As Eric pointed out, if you drag-and-drop the destination /Volumes/volume_name/Users folder from the Finder into your Terminal window at the point when you need it (eg. as the second argument for the ditto command), Finder and the Terminal app will collaborate to get all the unsafe characters escaped for you. So you type "ditto -rsrcFork /Users " (see the space after /Users in there?), then drag the destination Users folder in from Finder to complete the command. Still, it's a lot easier when you don't have any unsafe characters in that volume name.

    2. Case-sensitivity in Unix (and Mac OS X is a Unix)

    An awful lot of Unix is case sensitive. Usernames, passwords, and filenames, including volume names, all are. HFS+ has an odd twist on it, though. Filenames, including directories ("folders") and volume names, are stored in mixed case, but looked up as if case-insensitive. This can get very confusing in the shell (in Terminal) if you're not ready for it.

    I generally name volumes and other important directories with mixed-case names. In the shell, I've just gotten used to matching the case when I type, always, because I spent (and spend) more time on non-Mac-OS-X Unix systems than in Terminal on Mac OS X.

    You're always safest to assume that the file-system is case-sensitive, even though on an HFS+ volume you can't, for example, put a file called makefile in a directory that already has another file in it called Makefile.

    Last edited by Jazzbo; 09-05-2004 at 09:12 PM. Reason: Wording tweak

  4. #4
    Join Date
    Jun 2002
    Campbell, CA, USA

    Default About: chmod 1775 /Volumes/volume_name/Users

    The chmod command is used to change a file's "mode" -- its permissions set.

    1775 is the numeric representation of:

    rwx for owner
    rwx for group
    r-x for "others"
    t "sticky"
    For any file, the rw part grants read and write access (r- granting read-only). For directories, x ("execute permission") means that a user can navigate through it, so we're allowing anyone to navigate through the directory with 'x' on in all three parts. The "sticky" bit on a directory is taken to mean that anyone with read/write access to the directory can only remove/rename files that are owned by that user. Of course, all permissions checking is off if it's the root user doing the work.

    How the number 1775 means that is like this.

    For each of the triples of read, write, and execute (rwx), we start with a zero and add to enable:
    4 enable read
    enable write
    enable execute
    So to grant read-only access, it's the number 4; read-only and execute is 5; read/write and execute is 7 (all bits on). The rightmost three numbers (the 775), then, enable all access for owner and group and read-only plus execute for "others" -- that is, not the owner and not in the group.

    There are three special flag bits in the thousands-place where the 1 appears in 1775:
    4 setuid on execution
    setgid on execution
    the sticky bit
    Not to get too fancy about setuid and setgid bits, but their most typical use is so that any user allowed to execute a command winds up running that command as the command-file's owner. For instance, the sudo command file is owned by root and has the setuid bit on, or it couldn't become root for you when you run it.

    For other than directories, the sticky bit is historic from the days of small (and expensive!) RAM in computers. Certain commands that "everyone" used a lot -- the ls command to list files, for instance -- had the sticky bit set to tell the kernel to leave it loaded in memory for as long as possible because "sometime soon someone else is going to need it" and if it was still in memory, it didn't need to be read back in from disk.

    The use of the sticky bit on directories to add a little security to more-or-less globally writable directories is a fairly recent arrival in Unix.

    So our chmod 1775 /Volumes/freedom/Users command has the effect of:
    1. grant read/write/execute access to the root user
    2. grant read/write/execute access to the admin group
    3. grant read/execute access to everyone else
    4. disallow users removing entries they don't own
    Run man chmod to see the complete description. (Type 'q' to quit when you're through reading the manual page.)


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts