Now that I’ve tried it myself, I’ve very much enjoyed the advantages that having a network home account has offered. I’ve also rather disliked some of the disadvantages. Ultimately, the biggest drawback has been that when our production crew is doing a lot of rendering, my home account slows to a crawl and I can’t get work done. Okay, I can, but not without a lot of swearing, and the fellas in the other cubicles just ain’t digging that, believe me.
After some water-cooler-side conversation, and some excellent comments by my excellent readers, I’ve decided I might be just be a perfect candidate for something that may offer the best of both worlds.
Portable Home Directories
Portable Home Directories (PHDs), as they’re called by Apple, essentially allow a user to keep and work from a local copy of his network home account. The local account is synced up with the network account using various strategies, which I’ll talk about in a bit. It’s essentially an intelligent implementation of Windows’ crappy Roaming Profiles. The big difference is those strategies I mentioned.
Windows’ Roaming Profiles are problematic, particularly in production environments where users store a lot of data, because Windows simply hard syncs those profiles at login and logout. This means that if you’ve generated a lot of data in any given session, you’re in for a long wait when you log out — and another long wait if you log into another machine — while Windows syncs your local and network profiles. It’s a nice idea — giving you the centrality of a network account and the responsiveness of a local one — but it fails in practice because it is, essentially, dumb, causing the sync process to ruin the experience.
The experience we’re going for here is, of course, seamlessness. Or as close to it as possible. So: I want to be able to log in to my workstation and have the responsiveness and normalcy of a local account, but I then want to be able to log in to another workstation and have my documents follow me throughout a given facility. Moreover, I want the synchronization of said documents to be as invisible as possible to the user. It should “just work.” With as little waiting and confusion as possible.
This is, of course, easier said than done.
Apple takes a noble stab at this with its Portable Home Directory settings. See, where Microsoft simply syncs account data at login and logout, Apple affords some granularity in what gets synced and at what times. Apple gives you precise control over what gets synced, as well as allowing for not just login and logout syncing, but periodic syncing as well. Smart! And it could make all the difference.
But I’m getting ahead of myself again. Let’s actually step through the process of creating a Portable Home Account. I’ll show where it shines and where it falls apart for me.
Activate Mobility Preferences
- This all starts in Workgroup Manager. So fire that up and navigate to the user you want on Portable Homes.
- Make sure that user’s current home account is a Network Home Account (i.e., it lives on a server somewhere).
- Click the “Preferences” button from the toolbar, and then open the “Mobility” pane. This is where all the action happens.
Mobility Preferences
Set Account Creation Options
- The first thing to set up is how and when the local portable account is created. Click on the Account Creation tab and set Manage: to Always.
- Since I already have a network home account that I’ve been using from an NFS share (on a non-Apple server), I set my user to “Create mobile account when user logs in” using the “default sync settings.” I assumed this would copy everything over from the network account to the local drive and start the ball rolling fresh, but that’s not what happened. More on that in a bit.
Account Creation
- Under Account Creation’s Options tab I set a custom path that pointed to a folder that contained a local version of my home account that I’d rsynced previously. Again, I did this thinking it would speed the initial sync process, but that turned out to not be the case.
Account Creation Options
Set Sync Rules
- Finally it’s time to define how the syncing between local and network homes will behave. This is the real genius behind the Portable Home Directory system, and what distinguishes it from Roaming Profiles.
- First under the Rules tab you have “Login & Logout Sync.” This allows you to set specific items to sync only at login and logout. The suggested defaults for this are mainly your account settings, i.e. your entire ~/Library folder. This is quite sane, and I stuck with this setting.
Login & Logout Rules
- Note the “Merge with user’s settings” checkbox. I initially checked this, but later found it problematic. It was useful on my first sync, but it doesn’t appear to track deletions and such, so I ended up disabling it.
- Also of note is the “Skip items” section. This allows for what rsync users would call exclusions. This also greatly speeds syncing as you can exclude unneeded items such as cache and trash. I stuck with the sane defaults here as well.
- Next up are your Background Sync settings. Again, very sane defaults are provided: We back up your entire home account, periodically, in the background. Skip the usual suspects and don’t merge.
Background Sync Rules
- Finally, under Options, we can set the frequency with which the server will run the background sync.
Background Frequency
- I also set the option to “Show status in menu bar.” This, as you’ll see, becomes quite useful for the way I ultimately ended up using this feature.
Some Disclaimers
Portable Home Directories are actually not specifically intended for the sort of use-case we’re applying them to here. PHDs are actually designed for users with laptops that come and go onto a network that is also populated with stationary workstations. It’s really made to be used in conjunction with network home accounts, allowing laptop users to use network home accounts without being completely tethered to the network.
So to be clear, this is an experiment. I’m doing things a bit outside the norm. (I mean, what fun would it be if I weren’t.) And any problems I had were likely because of this fact. Still, it’s hinted at in the documentation that PHDs can be used for users of non-portable machines to some advantage, so I wanted to see how we could apply them to our (okay, my) particular situation.
I started off a bit outside the realm of the typical first time setup. I had two things at the outset that essentially represented a test of how we might migrate to a PHD-style system: I had a network home account already populated with data, and I had a copy of that data on a local hard drive. This represents our typical user. But I was also hoping that I’d be able to use these to get the Portable Homes process underway more speedily. This was not the case at all.
Initial Experiences
The first thing that happened when I logged into my newly Portable Homes-activated account was that I was greeted with a prompt asking me if I wanted to create a portable home.
Initial Prompt
I chose to do so (“Yes”), since that was pretty much what I was here to do. And upon login I was greeted, not with my previously set up network home account nor my rsynced local account, but rather with the standard boilerplate skel account you see when creating a new user. Worse, the server seemed to get confused as to where my home account should be placed on the local drive. Though I had defined it on my server as a custom path, it seemed to want to go in a folder called “User” on the specified drive, no matter what I entered for the custom path. Apparently, for me anyway, the custom path — and my hopes of speeding the sync process — just plain old didn’t work.
Default Login Environment: Not What I was Hoping For
After this I decided to try again. I moved my custom folder off the local drive and, in Mobility Preferences, simply defined the drive I wanted to use for my Portable Home. I also chose to “Merge with user’s settings” for this go ’round under the Rules section of the Mobility prefs. The thought was that this should pull down my network home account and create a local version from it. And this is exactly what happened. And for a time life was good and I thought I was done. I thought I’d found my magic settings. But the next day I logged in to find that once again my account had reverted back to the default, first-login settings. Yikes!
Portable Homes Weirdness
(Here I’d just like to point out the benefits of having a backup of your entire home account if you’re going to play around with this. Or just use a spare, dummy account. I actually did lose data numerous times during my testing, as you’ll see in Part 2.)
After poking around a bit I discovered that my machine had logged me into my network home. Or at least that’s where the Finder went when I hit Command-Shift-H. But my home account settings were the defaults, not my network home account settings. WTF? Logging out and logging back in I found myself in what I considered to be the right local location, and all my custom settings had returned. But this was clearly getting weird and flaky. And no matter how I configured things, the weirdness persisted. The biggest problem, though, was the fact that my local and network home accounts never synced in the background. And that was sort of the most important part.
Manual Sync
For a time I used Portable Home Directories the only way I could get it to work for me. Remember that tickbox to “Show status in menu bar?” Well, it turns out that you can use this menubar widget to manually sync your local and network home accounts. And manual syncing actually worked okay for me. In fact, it was the only way I could get my network and local data in sync.
Menubar Icon
During this time I pretty much using the default Mobility settings, but my account was on my Work drive. Portable Homes had placed it at:
/Volumes/Work/systemsboy.xahomes
for some strange reason, but I could live with that. Every so often — particularly if I thought I might be going to another machine and logging in as myself — I’d hit “Sync Home Now” in the Menubar pulldown.
Sync Home Now
This would begin the Home Sync process. The process is far from immediate, but it’s not too slow. It takes a few minutes. Once it’s done I can verify that my network and local homes are synced up.
Home Sync Status
Conflicts that the service couldn’t resolve were handled similarly to iPhone-to-AddressBook conflicts, though, with the usual PHD flakiness: often conflicts occurred where they shouldn’t have.
PHD Conflict Resolution
But the biggest problem with Manual Sync was that logging in to another computer failed. A popup alert appeared telling me I was unable to log in at this time because “an error occurred.” Great.
I was really hoping for this to be seamless, of course. But it just may not be possible with this particular setup. The best I can get out of Portable Homes so far is not much better than a glorified rsync script with a pretty GUI for running it and some semblance of conflict resolution. And it completely breaks my ability to log into other computers.
Conclusion (For Now)
In the end I decided that my troubles were likely due to the fact that I was not working in the typical Mac OS X idiom. It’s my guess that Portable Homes failed for me in this instance mainly because my network home account is on a completely different, non-Apple server, one that my Mac Server is not set up to share as a network home location. I would venture that if you set Portable Homes up just like it says in the manual, using Apple kit and AFP and the like (possibly AFP reshares would work), Portable Homes works like a charm. But if you don’t you’ll get some strangeness like I did. Ah, the joys of the bleeding edge!
On my first shot at Portable Homes I experienced a number of surprises and inconsistencies. While Portable Homes is a great idea, and in theory looks to be perfect for someone like me, there are major pitfalls in a complex, multi-platform environment that prevent it from being usable for much of anything. But Portable Homes has potential and I plan to delve more into how to get it working for us in our complex environment. In our next installment I’ll be trying a setup more closely aligned with the Apple-sanctioned method for implementing PHDs. We’ll see how it goes.
11 Comments
Hi,
It’s cool and in the meantime a pity that I met the same problem and experience as you.
I had the same situation. I have a macmini server with Open Directory installed and I activated the mobile account for the user of my laptop (only me use it). Each process was like you.
The only difference is that my network account is on my macmini and my local account is on a partition. At the beginning it had created a home at /Volumes/Data/username. After a next login, it had created an invisible link .username.xahome in the folder /Volumes/Data/Users that he has self created. And finally the account home finished in the folder Users !!?
Now I have some trouble with sync because i wanted to copy data/files from an other account with uid changed of course to my mobile account. The behaviour is some kind weird. I go on to try to make it work more than two days … I pray for that. Regards and good luck
Great article – What version of Server did you try? Have you given it a go with 10.6.2 please?
Many thanks
I was using Mac OS X Server 10.5.8. Unfortunately, I don’t know when I’ll get a chance to upgrade to 10.6. We’re just not using Mac OS X Server enough these days to justify the hardware and software upgrade. It’s kind of a bummer.
I’ll post more when/if this changes.
-systemsboy
It seems to me you haven’t set the correct permissions for the account that you imported.
When Mac OS X Server creates a new user account in open directory, the owner permissions are set to the user you are creating. If you copy any existing users from another Mac or any server into Mac OS X Server’s folder where users accounts are shared, then you must set the owner permissions for that account.
Example: you copy an existing account from a Mac to Server’s folder for network user-shares. Then you create a user with same name, and set the password and then define it’s Home in Workgroup Manager. In Sharing tab in Workgroup Manager, you find the user folder you copied and select it. Then click the Access tab and set the owner to the name of the account you created and give Read & Write access. Set the group to the appropriate group and appropriate access. “Everyone” should be set to read only.
Next you must click the gear and propagate the permissions. Be sure to check all options to propagate. Owner, Group and Everyone. Access list propagation is optional.
hey i was wondering about this “.xahome” as well. It’s not supposed to happen and apple enterprise support didn’t seem to know what it meant. I’ve seen it on my 10.5.x server, installed on both a intel mini and a powermac g5, and somewhat on some client machines.
@ Sylvain :
Each time I’ve set a home folder to mount on any non-startup volume (or even redirected any other ~/* subfolder to) I get this or other problems.
A folder redirection or PHD creation is started precisely at the time of login, whereas volumes (aka anything that would appear in /Volumes/) are not mounted until login is complete and a user arrives at their fully loaded desktop (or therearoundabouts).
Therefor the OS screws up, and makes an actual directory, instead of following a symbolic link, in /Volumes because that link isn’t there yet. This is no good and has to be manually erased (often on the command line) and the machine restarted (because there was likely another volume on the machine with that name already, and it will have “\ 1″ appended to it’s name and aliases to it are broken until reboot.
so when you wrote:
[quote] “At the beginning it had created a home at /Volumes/Data/username.” [/quote]
… were you referring to another partition or disk?
•If so, the login sequence i described explains your problems. look in /Volumes and see if there is an actual directory there alongside the alias to your real volume.
•if not, you shouldn’t be putting data (or a dir named “Data”, no pun intended:-) in /Volumes.
I have found a way to workaround this:
•in WGM, select the user, group, machine or machine group that has the login settings we’re dealing with. under the preferences for mobility, under “account creation” and then “options;”
•set ‘manage’ to ‘always;’
•select ‘home folder location;’
•select ‘user chooses,’ and in the pop-up you may specify ‘any, internal’ or ‘external;’
•apply and save.
•reboot or logout the affected entry.
•OPTIONALLY, you may also want to log them in one time for each machine and select the location for the PHD, as well as check the box to ‘remember my choice’ so it sticks. This setting will now behave the same as if you had changed the home folder location under ‘advanced settings’ in System Preferences’ Accounts panel.
Watch out for other WGM settings (i cant find right now) that toggle the ability to hold down certain keys at login or startup to bypass this PHD location setting, as well as other managed settings.
@ Mike :
when you wrote:
[quote] “In Sharing tab in Workgroup Manager, […]” [/quote]
… did you mean in Server Admin?
PS another thing that may have caused it for me was somehow getting my server itself as an entry in WGM, and then settings the mobile accounts location the wrong way (by selecting ‘at path’ and entering /Volumes/*). now even though i’m logging in locally right on the server where the network homes are stored, sometimes i end up with the .xahome thing. lame, but it’s wrong anyway so whatever.
FANTASTIC article… useful and informative.
But I couldn’t use it to advance me further with a PHD problem that I’m hoping to conquer. Maybe you can help?
SITUATION:
Xserve1 hosts (AFP) user accounts on an external XSan.
Portable Home Directories sync those to client laptops.
The XSan folder is also permanently mounted to XServe2 (‘>mount’ on Xserve2 shows it correctly mounted).
THE PROBLEM:
When I log into Xserve2, the users folder is mounted AGAIN (causing grief with file perms etc.). There was no problem pre-SnowLeopard (10.5).
I KNOW I could just stop using PHD,.. but I don’t want to give that up.
I also KNOW that could just not mount permanently,.. but I need it for a bunch of other reasons.
I COULD just move the files physically from Xserve1 to Xserve2 but that just shifts the problem elsewhere (I’ll have double-mounts on Xserve1).
MY QUESTION:
1. How do *you* local-mount users, permanent-mount on another server, and PHD to mobile laptops syncing their home dirs.
2. How might I prevent the automount from happening while preserving the use of PHD? (woud making a hardlink work?.. configuring fstab in an exotic way? digging into the hidden prefs on OS X Server? Latching on to some sort of apple event linked to the the system log file?
Your help is appreciated and will win you a privileged place in heaven (and a free beer if you come by Lausanne, Switzerland).
Best,
Shawn
Shawn,
I’m a little unclear as to what Xserve2 is doing and why you’re logging on to it. If I understand correctly, Xserve1 is working correctly and the problem is that Xserve2 remounts the Xsan, causing multiple mounts to appear when you log on to it.
To answer your first question: I don’t. I am no longer using network home accounts or PHDs. We just don’t really need them where I work now. So I’m a little out of the loop on the current tech here.
To answer the second question: automount is simple to turn off with the command-line if you want to disable it for specific maps. All the automount config files live in /etc and begin with “auto_”. The main control file that dictates which automount map files get loaded is called “auto_master”. Here you can disable specific map files (like auto_home, for instance) by simply commenting them out. There is likely a GUI way to control this to some extent by now as well, but I don’t have the latest, greatest version of Server, so I don’t know offhand and can’t really check. And there are almost certainly LaunchAgents and Daemons that control automount to some extent.
If you’re serious about mucking with automount — which is great and I highly recommend — spend some time reading the man files. You’ll be glad you did.
As far as fstab goes, it’s always made me very nervous to mess with Mac OS X’s fstab implementation, and I’ve never really found it necessary. Needless to say, I don’t recommend it.
Hopefully this helps somewhat.
-systemsboy
@systemsboy:
.
Thanks for the thoughts.. I’ll watch this thread more actively now
CLEARING-UP XSERVE2 RBF (reason 4 being):
Xserve2 and Xserve1 are simultaneously connected (via fiber-channel links) to the XSAN disk. This allows our users to ssh into one or the other (from the lighter client machines) to do data-processing on really big files (50gig filesize).
YOUR (great!) IDEA:
I hadn’t thought of turning off the automount as you suggest (although it means losing the possibility to automount from other machines on the network
BTW: For PHD our WGM (on Xserve1) specifies a typical home to be afp://xserve1.blah.blah/Volumes/disneyland/users so the automounter on xserve2 says ‘heh,I’m not Xserve1 so I need to mount’ even though it’s already mounted (think fiber-channel). We tried configuring the AFP to disallow Xserve2 and that works… but the disallowing takes 15seconds during login… slow slow slow!
NEW PROBLEMS THOUGH (arghh!):
Actually our automounter is now misbehaving.
Although I have share points set up as they should, perms seem fine, OD properly configured,.. On client machines, although I can manually mount (via ‘Connect to Server->Browse to the users share point etc.), automounting fails during login.
from system.log on the client I am seeing:
edu.mit.Kerberos.CCacheServer[942]: launchctl start error: No such process
afp home directory mount failed in theEnumerator->Mount in AFP_Mount: status = Unknown error: -5000
from ApplePasswordServer.Server.log:
KERBEROS-LOGIN-CHECK: user {0x4bfba0dc19d92b62000000150000020c, koppenhoefer} is in good standing.
KERBEROS-LOGIN-CHECK: user {0x4bfba0dc19d92b62000000150000020c, koppenhoefer} authentication succeeded.
Any ideas or web links you might have, to help, would be great.
Shawn
I hadn’t thought of turning off the automount as you suggest (although it means losing the possibility to automount from other machines on the network…
You can disable automount on a per-computer basis by creating maps for computers that you want to automount, and disabling (or not creating) maps for computers you don’t want to automount.
I fear we may be talking about different kinds of automount.
On client machines, although I can manually mount (via ‘Connect to Server->Browse to the users share point etc.), automounting fails during login.
I believe this is a different sort of automount than the automounter daemon used for automounting NFS shares when called by the filesystem.
Nevertheless, your problem appears to be a Kerberos problem. Kerberos makes me go “Blurghh!” I know people are insanely in love with it, and when it works well it does offer certain advantages, but it’s a bitch to set up and/or troubleshoot when there are problems. So I’ve never used it.
What I’m trying to tell you is, I think you have a Kerberos problem, and I am useless for that sort of thing.
Oh, and BTW, a 15 second wait is not a big deal. It can be a lot worse, and when users start creating and syncing a lot of data, it probably will be a lot worse. So get used to it.
The fun of non-local homes! Good luck!
-systemsboy
I am setting up around 300 computers for a school district I work in. The teachers are a bit overwhelmed when a new system is put in place and reading instructions doesn’t seem to be a priority. I am afraid that when sync conflicts arise they will have a hard time determining what to do. I have decided I would like to default the sync prefs to Keep the most recent modification date. However there isn’t a choice in Workgroup Manager to do this automatically. Is there some kind of login hook script and/or logout hook script that can produce these results??? Thanks for any help….
So you’re saying that, when sync conflicts occur, you want the popup to not appear and the conflicts to be automatically resolved using the most recently modified version.
No, I don’t know of a way to achieve this, with login hooks or otherwise. I would guess you’d need to modify something fairly low-level to pull it off.
Again, it’s been some time since I’ve looked at this functionality, and you might want to take a closer look, but if there is no Apple-sanctioned way to set that preference, I would probably advise against messing with it.
-systemsboy