Update 10/31/14 - You might want to re-implement redirection to the /tmp on the local drive via Workgroup Manager (see this article):
http://houseofmac.wordpress.com/2010/11/03/os-x-network-home-folder-redirection/
Moving the ~/Library/Caches to /tmp should speed up browsers at least (and reduce network and server load).
You might want to consider hidden preference file info like "last_directory" and the ilk below and re-create them if possible.
Here is a login hook way (see post): - p.s. Thanks Nigel Kersten!
http://lists.apple.com/archives/macos-x-server/2006/Feb/msg01025.html
In case it goes away, here is Nigel's code:
... Sure. Have you looked at LoginHooks? Basically they are a shell script that gets passed the variable $1 as the username of the user who is logging in and executed before login finishes. As we have a combination of local, mobile and network users, I have a LoginHook that distinguishes between them, as I want to do different things for the different users, like forcing new mobile users to have their home directory at /Volumes/Storage/Users, not /Users. Here's a snippet of a script that would redirect caches for only network users. I've kind of pieced this together from our SOE LoginHook, pulling out bits that aren't relevant, so I ****haven't actually tested this at all****. There may be some bugs... Oh, and I'm using the dscl "/Search" node here, but we actually hard- wire the LDAPv3 node. It should be safe to use the search node, as that section of the script shouldn't be running for any local or mobile users, but I prefer to hardwire it myself as "/LDAPv3/ your.od.domain". ----------start #!/bin/sh # lookup_local=$(niutil -read . /users/$1 2> /dev/null) if [ "$lookup_local" != "" ]; then # this will grab local and mobile users, as they're both strictly 'local' users. auth_prop=$(niutil -readprop . /users/$1 authentication_authority 2> /dev/null | grep LocalCachedUser) if [ "$auth_prop" != "" ]; then # Do your stuff for mobile users here. logger "LoginHook: Starting for Mobile Account - $1" else # Do your stuff for local users here. logger "LoginHook: Starting for Local Account - $1" fi else # Do your stuff for network users here. logger "LoginHook: Starting for Network Account - $1" home_loc=$(dscl /Search -read /Users/$1 homeDirectory | sed 's| homeDirectory: ||g') /bin/mkdir -p /Library/Caches/$1 /usr/sbin/chown $1 /Library/Caches/$1 /usr/bin/sudo -u $1 /bin/chmod 700 /Library/Caches/$1 /usr/bin/sudo -u $1 /bin/rm -Rf $home_loc/Library/Caches /usr/bin/sudo -u $1 /bin/ln -s /Library/Caches/$1 $home_loc/ Library/Caches fi logger "LoginHook: Finished for - $1" ----------end If you save this as /Library/LoginHooks/loginhook.sh and make it executable (and protect it appropriately!) you can then issue a command like: sudo defaults write com.apple.loginwindow LoginHook /Library/ LoginHooks/loginhook.sh and it will run this script as each user logs in. The 'logger' lines will print to syslog. We also do some similar stuff with the Temporary Items folder that Office uses, and due to a problem we were having at one point we also trash the mcx cache, although I don't think we actually need to do that anymore. Oh, and if you're binding to the directory, you can actually save these in the directory using Workgroup Manager. Mike's sent me some defaults commands that will supposedly let you enable MCX login scripts for machines that aren't actually binding to the directory, but I haven't tested them yet. -- Nigel Kersten [Senior Technical Officer] College of Fine Arts, University of NSW, Australia. CRICOS Provider Code: 00098G
Update 11/15/2013 - AFP and home auto-mounts might be considered worthy of testing!
It looks like the latest round of fixes for Firefox (24 and 25) to land in Firefox 26, will help crashing Firefox on
OS X clients with OS X server and AFP homes based on this nice and extremely helpful bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=918612
Looks like Firefox on OS X in school environments might be a winner in future.
Using network home auto-mounts under OS X, and having to move users from one server to another after creation?
This works for most programs, but some are poorly written.
Here is why:
Preference files often get written with the full server path in them...
Chrome hides this in the Preferences file: ~/Library/Application Support/Google/Chrome/Default/Preferences "last_directory": "/Network/Servers/server.com/Users/username/Desktop" But Microsoft Office is even worse.... It keeps the server the application was registered on in a preference file: ~/Library/Preferences/com.microsoft.office.plist Nuke that file and MSO works after the move, but the user will have to re-do the first run steps (thankfully not the registration key entry)....
I am sure there are other programs that break on a server move.
Hey dummies, do you hard code paths on your website so it only works on one server?
Chrome and MSO are so bad that they try to open and mount the location specified in the Preference file.
The program eventually crashes and or fails to kill off on log out for the user.
Nothing like lazy programming to make your product seem like it is crap, when it is probably not.
Here is some discussion on the Chromium bug list:
Link here:
http://code.google.com/p/chromium/issues/detail?id=27756&q=network%20home%20directory&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20Area%20Feature%20Status%20Owner%20Summary
Comment 42 by mar...@chromium.org, Mar 22, 2011 If you think Firefox better suits your needs, then by all means switch to that browser. We aim to be the best browsers for everybody, but there will always be users who have specific requirements that are better met by a different product. Having said all of this, you will probably discover that both Chrome and Firefox do *much* better if you can avoid storing state files on a filesystem that fails to implement full POSIX semantics, and that is shared across multiple logins. Long before Chrome existed, when I was using Firefox as my daily browser, I made it a point to move all of the Firefox state files to local disk. I had a lot less trouble afterwards. All network filesystems (NFS, Coda, ...) have unusual semantics and failure modes. It is better not to use them for parts of the filesystem that are expected to provide full POSIX semantics. This particularly means to never ever use them for /tmp (really bad things happen, if you do!), and to avoid them for some of the files in /home. This especially means ~/.config, ~/.gnome*, ~/.cache, ~/.gconf*, ~/.mozilla and probably a few others that I can't think of right now. None of this means that we shouldn't try to make a best effort to help users who are unfortunate enough to be stuck with a machine, where local storage isn't available. But I would always expect for some problems to remain, if the filesystem is essentially untrustworthy.
I especially love the bits about non full POSIX semantics and "... users who are unfortunate enough to be suck with a machine, where local storage isn't available."
Avoid network filesystems for ~/.mozilla, eh? Network home dirs via nfs etc were around long before programs started becoming written like this as well.
From the looks of the open bugs, many of the bugs would go away with a fix to the file paths in preference and other files....