Leopard, MobileAccounts, and NFS homes

HomeSyncOn the MacEnterprise maillist, Arjen van Bochoven wrote of problems with automatic HomeSyncs under Leopard with NFS home directories. Manual syncs worked fine, but the automatic background syncs would fail with errors that looked like this:

1:: [228] Peer "network" is unable to sync. (-[SPeer_FS_PHD mountPeerVolume] (Peer-FS-PHD.m:140): "'((homePath))' is nil")
0:: [228] [2009/02/19 10:45:10.640] Peer "network" is unable to sync. Not enough peers will be available to continue syncing.
0:: [228] [2009/02/19 10:45:10.640] Aborting sync of "HomeSync_Mirror".

I saw the exact same problem in my environment. This also affected login and logout syncs. Here’s the (ugly) fix.

For each mobile account, you’ll need to make two modifications to the account info in the local DS:


/usr/bin/dscl . create /Users/$USERNAME dsAttrTypeStandard:OriginalHomeDirectory "<home_dir><url>nfs://$NFSEXPORT</url><path>$USERNAME</path></home_dir>"

where $USERNAME is the short username, and $NFSEXPORT is the nfsserver and its export.

This gives HomeSync a nfs:// URL to use to mount the network home directory (It shouldn’t have to do this, since the network home is already available at the autofs mountpoint for the network home, and obviously really doesn’t need it since manual syncs work), but we have to do it anyway.

The OriginalHomeDirectory attribute has two parts – a URL describing the mount, and a path describing the path to the actual home dir, relative to the mount. In my case, when I type `mount`, my home autofs mount looks like this:

homeserver:/vol/home/fahome on /home/fahome

and my NFS home path is /home/fahome/gneagle

So the URL is ‘nfs://homeserver/vol/home/fahome/’ and the path is ‘gneagle’.

Depending on how the home mounts are setup in your environment, the division between the URL and the path might be different, for example, we might have had this instead:

URL ‘nfs://homeserver/vol/home/’ with a path of ‘fahome/gneagle’.

The next change:
/usr/bin/dscl . append /Users/$USERNAME dsAttrTypeNative:preserved_attributes dsAttrTypeStandard:OriginalHomeDirectory

This prevents the OriginalHomeDirectory attribute from being overwritten by the empty value presumably coming from the network. (If there was a useful value in the network directory, this hack wouldn’t be needed.)

You may be able to create the accounts “correctly” in the first place by using /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount and passing the syncURL with the -u option in the form “nfs://homeserver/export/home/gneagle”. This didn’t work in my environment, and even if it did, it wasn’t really an option to use createmobileaccount, so I instead wrote a login hook that “fixes” the mobile account if needed. WordPress will cut off the right side of the script when displaying it, but you can select, copy and paste into your favorite text editor for examination:


#!/bin/sh

# Leopard bug workaround as of 10.5.2. March 5 2008
# inserts nfs:// URL into OriginalHomeDirectory attribute
# for mobile accounts so that login/logout/background syncs
# work reliably
#
# Greg Neagle, Walt Disney Animation Studios

# the following is the actual NFS share that is mounted via autofs
NFSEXPORT="homeserver.example.com/vol/home/fahome/"

USERNAME=$1
LOCALACCT=`/usr/bin/dscl . read /Users/$USERNAME 2>/dev/null`
if [ "$LOCALACCT" != "" ]; then
  # $USERNAME is a local account
  NETHOME=`/bin/echo $LOCALACCT | /usr/bin/grep OriginalNFSHomeDirectory` 
  if [ "$NETHOME" != "" ]; then
    # $USERNAME is a mobile account
    # in our case, the path and the username are one and the same
    /usr/bin/dscl . create /Users/$USERNAME dsAttrTypeStandard:OriginalHomeDirectory "<home_dir><url>nfs://$NFSEXPORT</url><path>$USERNAME</path></home_dir>"
    PRESERVED_ORIG_HOME=`/usr/bin/dscl . read /Users/$USERNAME dsAttrTypeNative:preserved_attributes | /usr/bin/grep dsAttrTypeStandard:OriginalHomeDirectory`
    if [ "$PRESERVED_ORIG_HOME" = "" ]; then
      /usr/bin/dscl . append /Users/$USERNAME dsAttrTypeNative:preserved_attributes dsAttrTypeStandard:OriginalHomeDirectory
    fi
  fi
fi

The user logs in with their network account. MCX computer group settings cause the user to be asked if they want to create a mobile account, if they agree the mobile account is created and the home directory is encrypted with FileVault. As they log in, the login hook runs and if needed, inserts the additional info into the cached local account info so that automatic HomeSyncs work.

Though this fixed the issue for our environment, I still consider this a bug.

Leopard, MobileAccounts, and NFS homes

11 thoughts on “Leopard, MobileAccounts, and NFS homes

  1. Hm.. February 2009,.. more than 1 year ago. 😦
    I was kinda hoping to find an article (or two) on your trials n’tribulations of PHD (mobile accounts… network homes etc.) under Snow Leopard clients.. and Snow Leopard Server… in the hopes that your words would give me insight.

    I’ve got my users on an external disk in a subfolder called ‘users’ . I’ve got that mounted on the server on /Volumes/stormtroopers (currently at /dev/disk7).
    I’ve defined the sharepoints in WGM
    stormtroopers /Volumes/stormtroopers
    shared /Volumes/stormtroopers/shared
    users /Volumes/stormtroopers/users

    the ‘users’ sharepoint is automount enabled with guest access
    and a typical user (e.g., anakin) has
    sharepointurl := afp://deathstar.georgelucas.ch/users
    path to home folder := anakin
    full path := /Network/Servers/deathstar.georgelucas.ch/users/anakin

    Lastly, I have indeed created the home for anakin, and I’ve double-checked that NFShomedirectory is defined with the same value as the full path. I’ve even peeked into the folder and do see the files.. correctly chowned.

    On the virgin client machine Alderaan (only the local admin account exists) I use the login window and type in anakin’s username and password. The local folder IS created, and I *CAN* login in.

    NOW (finally!)… My question…

    When the mobile account for anakin SYNCS a df briefly shows one or both of…
    /Network/Servers/deathstar.georgelucas.ch/users
    /Volumes/users

    !!!!
    Whether it shows one, the other, or both seems to be arbitrary from one sync-moment to another.

    Should I be using a fullpath of /Volumes/users
    instead of /Network/Servers/deathstar.georgelucas.ch/users/anakin ?

    Can you detect any weirdness in my setup?

    Thx for any help.
    Shawn

  2. I’m sorry: I simply don’t know. We don’t use AFP network homes, and we don’t use Open Directory, so I’m not sure what the correct/expected behavior is.

  3. Chris Duffy says:

    Hey- I’d like to talk to you about home sync. I’m doing something fairly interesting- I have my home on an airdisk, and I’ve used WGM on my local account to tell it that it’s there… Now I’d like to use WGM, or whatever else, to do a proper home sync, cache redirects, etc.

    I could dig out how to make this work myself (one of the many things I do is run a very small OS X server at work) but it seems like you really know what’s going on and may have some good pointers. So… email me!

    The client main client in question is 10.5, though I would like to copy-and-paste the same settings to my 10.6 box… that’s round 2…

  4. Ambrose Neville says:

    Hi Greg, I have a question about your use of the NetApp filers in the respect of a heterogenous client environment, and network home folders/PHDs.

    Do you share out home directories over CIFS to your Windows users, NFS to your Mac and Linux clients? do you have any users who would log into say, a Windows client one day and a Mac client the next?
    Also, how have you handled general non-home shares? Do you share those out over both protocols from the Netapp filers?

    Thanks in advance
    Ambrose

    1. “Do you share out home directories over CIFS to your Windows users, NFS to your Mac and Linux clients?”

      Yes. The home directories are made available to Windows users, but aren’t _used_ as their home directories.

      “do you have any users who would log into say, a Windows client one day and a Mac client the next?”

      Yes.

      “Also, how have you handled general non-home shares? Do you share those out over both protocols from the Netapp filers?”

      In most cases, yes.

      -Greg

  5. pauln says:

    I just have to say Thanks! Of the scores of web pages I’ve scoured, yours is the one that seems to have gotten me out of Portable Home Directory hell. Huzzah!

  6. Hans says:

    With my setup it doesn’t work. I have local Users directories synced with /home shares on NFS server which.
    My mount info prompts:

    poseidon.home.lan:/home/hans on /home/hans (nfs, nodev, nosuid, automounted, nobrowse)

    I have enterd the following command in the terminal:

    sudo dscl . create /Users/hans dsAttrTypeStandard:OriginalHomeDirectory "<home_dir><url>nfs://192.168.1.100/home/</url><path>hans</path></home_dir>"

    I also tried with machine naming (‘poseidon’ with or without local domain ‘ home.lan’) but that doesn’t work either.

    My ~/Library/Logs/FileSyncAgent/FileSyncAgent-verbose.log tells me:

    NSLocalizedDescription = “No route to host”;

    For further details about verbose log see: http://pastebin.com/xPPUNf4U

    What’s wrong?

    1. Hans says:

      On my server log I read a succesvol authentication

      Oct 6 14:14:17 poseidon mountd[2931]: authenticated mount request from 192.168.1.81:1007 for /home/hans (/home)

Comments are closed.