Change home directory = constant lockups

[PaulyD]

got ML 10.8 DP1 installed and all is OK until I move the home directory off of my SSD and onto my 2nd HDD in my optibay. Once I do this and reboot hardly anything will load (spotlight, clock, other tools in menubar).

If I try open up System Preferences this will freeze and needs force quitting, as do a lot of apps whereas others open fine such as Safari, iTunes etc.

The moment I switch the home directory back then EVERYTHING works perfectly and its great.

Done this on both an upgraded Lion install and a fresh install too.

Anyone else tried this setup and get any issues?

 

[KnightWRX]

Maybe if you went into a bit more details, we could help you. How are you moving your user's home directory ? Are you modifying your user's entry to point to the new mount point ? Is the mount done on boot for your SSD volume ? Is it done over the existing location ?

 

[PaulyD]

Apologies, was just getting the basics in the post.

On my SSD I have just OSX. On my 2nd HDD I have two partitions, one for data (basically the home folder) and the other for Win 7.

I copied over the home directory from Users to the storage partition then went into the User section in System prefs, control-clicked on my username -> advanced options and changed the location of the home directory there, like I did with Lion.

Reboot and the moment I do I get the above.

I thought it might be an existing file there causing the corruption so manually moved all my normal files out, formatted the storage partition and just moved the home directory over from the clean install of ML (so pratically nothing in there) and again it does the same.

Its not a huge issue, just wondered if other people had reported the same.

 

[jasonvp]

I copied over the home directory from Users to the storage partition then went into the User section in System prefs, control-clicked on my username -> advanced options and changed the location of the home directory there, like I did with Lion.

A far more elegant solution to the same thing I started doing back with Leopard. The way my Macs are set up is: OS on drive 1, home directories on drive 2. Drive 2 mounts as /Volumes/Users. I boot the system into stupid-user mode and use the UNIX ln command to link /Users -> /Volumes/Users (after deleting the original /Users).

Now, I have NO idea if this will work w/Mountain Lion, but it should.

jas

 

[PaulyD]

Thanks, it sounds like it does the exact same thing I'm doing but from a command line side.

Just wondered if anyone else experienced this problem really. Was just testing out ML myself and am happy enough to go back to Lion once i'm done

 

[jasonvp]

Thanks, it sounds like it does the exact same thing I'm doing but from a command line side.

Actually it isn't. The OS still thinks my home directory is /Users/<username> for instance, even though it's a logical link into another directory.

I like the solution you're using because it's far more elegant. Mine's a sledgehammer solution that changes the location of ALL users' home directories without telling the OS about it.

jas

 

[Bear]

got ML 10.8 DP1 installed and all is OK until I move the home directory off of my SSD and onto my 2nd HDD in my optibay. Once I do this and reboot hardly anything will load (spotlight, clock, other tools in menubar).
...

Was this without autologin turned on or off? If autologin was on, I'd suggest disabling it and then logging in after the system is up. It could be a subtle timing issue that has lingering effects.

 

[KnightWRX]

I copied over the home directory from Users to the storage partition

An important point. How did you do this ? Terminal/Finder ? What user were you logged in as ? Did you tell the copy operation you wanted to preserve file ownership/security attributes or did you manually reset permissions/ownership using chown -R after the operation was completed ?

----------

I like the solution you're using because it's far more elegant. Mine's a sledgehammer solution that changes the location of ALL users' home directories without telling the OS about it.

Actually, your solution is much more elegant and resilient. Like you say, it takes effect for all users automatically and you did tell the OS about it, contrary to what you believe.

 

[PaulyD]

Was this without autologin turned on or off? If autologin was on, I'd suggest disabling it and then logging in after the system is up. It could be a subtle timing issue that has lingering effects.

Auto login was turned on, I can try with it turned off and see if it does the same.

An important point. How did you do this ? Terminal/Finder ? What user were you logged in as ? Did you tell the copy operation you wanted to preserve file ownership/security attributes or did you manually reset permissions/ownership using chown -R after the operation was completed?

Finder, I have one admin account and one guest account and I was logged in as admin account. Didn't do anything to preserve file ownership/security attributes. Didn't believe this would be required as doing the exact same in Lion has no issue with this and I have done so several times in the past.

EDIT: This is the exact guide I used, though there are many others online all stating the same/very similar

 

[jasonvp]

you did tell the OS about it, contrary to what you believe.

Well, not really. As I pointed out: the OS still thinks that /Users is where everyone's home directories are. The authentication system, PAM, et al still think /Users/<directory> is where my home dir is. Any shell I start will have /Users/<directory> as the $HOME variable, vs. /Volumes/Users/<directory>.

Our solutions differ in that his is user-specific and mine works for everyone automatically. And as he described: he took steps to tell the OS (the underlying UNIX authentication system specifically) where his home directory is. I did none of that.

In the end: I know my solution works for all versions of OS X I've tried it on. I've yet to try it on ML as I'm not in the developer program (and have no interest in it). But I'll be sure to do so when ML is released this summer.

jas

 

[KnightWRX]

Well, not really. As I pointed out: the OS still thinks that /Users is where everyone's home directories are.

Nope, the OS knows about it, since you had to symlink it.

Again, your solution is the most elegant. It's how I would have done it. Actually, I probably would have just mounted the volume over /Users like we do for every other Unix system out there (that's how I've done it since I've been administering Unix boxes anyhow, /home always being a seperate disk/LVM volume/partition/what have you).

 

[haravikk]

I've done my own by the even more complex method of moving individual folders onto the other drive (~/Movies, ~/Music and ~/Documents being the main ones) while leaving the rest where they are, and using symlinks to let the system think they're still in my user folder. It works fine for the most part but it's hopeless if I ever try to access my home folder from another machine, since AFP doesn't do anything for symbolic links.

Anyway, when you relocated your user folder, were you signed into the account that you were moving by any chance? I've always heard that you're supposed to sign into another admin account (a temporary one if necessary) and move your user account from that. This way you can also immediately trash the old user folder. The interesting question though is really what's going on that's actually causing the programs to fail. I know Lion introduced lock files for preferences, have you tried logging in as a temporary admin account and trashing all the .lockfile files in your user folder to see if that might be causing weirdness (e.g - programs can't open because they can't open their preferences files?).

I dunno, I can't think of any reason why something in Mountain Lion should cause a change in behaviour. Has anyone else tried moving their user folder using the built-in feature as opposed to weird hacks like the rest of us?

 

[PaulyD]

Anyway, when you relocated your user folder, were you signed into the account that you were moving by any chance? I've always heard that you're supposed to sign into another admin account (a temporary one if necessary) and move your user account from that. This way you can also immediately trash the old user folder.

I was signed into my one and only admin account (PaulyD). I copied the existing home directory over from the main SSD to the storage drive I wanted it located. I then did the change in the User section and after pointing it to my storage drive it states it needs to restart. Following the restart it is just unresponsive. Spotlight, the time etc just dont load in the top right etc and opening most things cause them to stop responding and need a force quit.

Last night I also tried turning off auto login and same result.

I also made a test admin account, this had the home directory on the SSD and worked fine but logging into my PaulyD one pointing to my storage drive cause the above issue.

The interesting question though is really what's going on that's actually causing the programs to fail. I know Lion introduced lock files for preferences, have you tried logging in as a temporary admin account and trashing all the .lockfile files in your user folder to see if that might be causing weirdness (e.g - programs can't open because they can't open their preferences files?).

Possibly but not something I have a great deal of experience in.

I finally resolved it in the end, I reinstalled Lion

 

[KnightWRX]

I'm pretty convinced at this point it was an issue with file ownership. Simply opening terminal and listing the files with 'ls -l' would have told you the owner, which was probably different from your users.

Thus when login in with your user, it didn't have access to its home folder and that would explain the errors you got.

 

[PaulyD]

Terminal wouldn't open. It was rather touchy about what would open (Safari and App Store would open fine, Mail would fail etc). It would bounce on task bar then get the light indicator to show it was open but nothing would come up. Then Right/Second clicking on it would show its not responding and have to Force Quit it.

Doing the exact same works in Lion fine though.

Out of interest, why would file ownership get changed by simply copying a file over from one location to another?

 

[KnightWRX]

Out of interest, why would file ownership get changed by simply copying a file over from one location to another?

Why would it get perserved is a more appropriate question ? You have to think of what exactly a copy operation is and how a programmer would implement it. At the very basic level, a copy operation is actually 2 operations, a file read and a file creation. Basically, we're going to open a file for reading, the source and a file for writing, the destination. Using the fread() and fwrite() ANSI C functions, you "transfer" the data from one to the other.

When you create a file on a Unix system, it gets stamped with a creation date, it gets its permissions set depending on your umask and the owner/group are that of the creating user. A copy thus "changes" file ownership :

$ ls -al /var/run/resolv.conf 
-rw-r--r--  1 root  daemon  262  1 Mar 19:07 /var/run/resolv.conf
$ cp /var/run/resolv.conf .
$ ls -al ./resolv.conf 
-rw-r--r--  1 username  staff  262  1 Mar 19:31 ./resolv.conf

In actuality, there is no "change" operation performed. The system just reacts that way normally to a new file being created.

Now, if you try to "preserve" the ownership on a copy, you need to first tell cp to do it. This is because we now have to do a few more operations on the file after creating it :

$ cp -p /var/run/resolv.conf .
$ ls -al ./resolv.conf 
-rw-r--r--  1 username  staff  262  1 Mar 19:07 ./resolv.conf

Now wait a minute, it didn't work you'll say. And you're partly right. Look at the timestamp. It is now equivalent to the original file (19:07 vs 19:31). The ownership though still got "changed". Again, it's not that the ownership got changed, it's that the operation to preserve the original ownership got denied. If we try it manually, you'll see that a normal user has no right to set a file to be owned by root :

$ chown root ./resolv.conf 
chown: ./resolv.conf: Operation not permitted

Hence, when the cp command tried to preserve the ownership as root:daemon, the fchown() call returned EACCES, which is a standard symbol defined in errno.h to mean an operation was not permitted by the system.

File ownership is complex when you dwelve into it. If your home is not owned by your user, stuff breaks. The best way to ensure your home directory is a clone copy is to use a method that actually makes a perfect copy (ownership, timestamps, attributes, acls, etc..) and to do so as an unrestricted user (root).

 

[petererr]

This is a great thread, except that OP eventually disappeared after KnightWRX dug into too much details. lol

I am guessing KnightWRX was right about this, although sadly OP probablly will never come back and confirm this.