Apple released Mac OS X 10.6.2 updates yesterday, fixing a number of issues, including the Guest Account bug posted earlier that could potentially delete a user’s home directory.

Other fixes include native support for Apple’s new, multi-touch Magic Mouse, mobile account creation for Active Directory users, file sync for portable home directories, a fix for Mail crashes during Exchange setup, & an issue with graphics distortion in Safari Top Sites, among others.

Updates are available via software update or directly from Apple. Download the 10.6.2 combo update for servers or the 10.6.2 combo update for clients.

As always, make sure you have a current backup before applying any software updates. Read on for the full list of features/fixes.

What’s included?

General operating system fixes provided for:
• an issue that caused data to be deleted when using a guest account
• an issue that might cause your system to logout unexpectedly
• Spotlight search results not showing Exchange contacts
• the reliability of menu extras
• an issue in Dictionary when using Hebrew as the primary language
• shutter-click sound effect when taking a screenshot
• an issue with the four-finger swipe gesture
• an issue adding images to contacts in Address Book
• an issue in Front Row that could cause sluggish or slow frame rates while watching videos
• creation of mobile accounts for Active Directory users
• reliability and duration of VPN connections
• general reliability improvements for iWork, iLife, Aperture, Final Cut Studio, MobileMe, and iDisk
• overall improvements to VoiceOver performance
• this update addresses video playback and performance issues for iMac (21.5-inch, Late 2009) and iMac (27-inch, Late 2009) computers that may occur in some situations while AirPort is turned on

Fonts fixes provided for:
• an issue with font spacing
• an issue in which some Fonts are missing
• font duplication issues
• an issue with some PostScript Type 1 fonts not working properly

Graphics fixes provided for:
• an issue when connecting monitors to DVI and Mini DisplayPort adapters
• an issue in which the brightness setting may not be remembered on restart
• addresses functionality with specific display models
• general reliability and performance improvements when using some applications

Mail fixes provided for:
• a situation in which Mail’s unread count may not update properly as messages are read on another computer
• an issue in which deleted RSS feeds may return
• an issue in which Mail cannot preview or Quick Look attachments when composing a new message
• an issue that can cause Address Book and/or Mail to stop responding when opened
• an issue in which email messages received from an Exchange Server are not formatted correctly
• an issue in which Mail reports “Account exceeded bandwidth limits” for some Gmail accounts

MobileMe fixes provided for:
• performance when accessing files from iDisk via the Finder and syncing iDisk files
• an issue in which syncing iDisk files does not proceed beyond “checking items”
• reliability and performance when syncing contacts, calendars, and bookmarks with MobileMe (syncing with iTunes and iSync are also improved)
• an issue that prevents some users from logging into MobileMe via the MobileMe System Preference pane

Network file systems fixes provided for:
• compatibility with third-party AFP servers
• file synchronization for portable home directories

Printing and faxing fixes provided for:
• automatic printer updates improvements
• Print dialog allowing you to enter and send to more than one fax recipient

Safari fixes provided for:
• a graphics distortion issue in Safari Top Sites
• Safari plug-in reliability

snowleopard.jpgMy last post looked at an issue where network users without a proper path assigned to their home directory in WorkGroup Manager would be unable to properly create a local home folder. This post looks at an issue with login failures that can arise with mobile network accounts under Snow Leopard Server. If you have mobile network accounts – AD or LDAP – that cannot login, jump to the bottom of this post for the fix.

After creating several network user accounts under Snow Leopard, I found that my test user account was unable to login. But instead of the standard shake of the login window that indicates a failed login attempt, the login window actually began to collapse as if the login process was starting – the login & password boxes disappeared briefly before reappearing suddenly & displaying the familiar shake to indicate that login had failed.

Interestingly, the user account could still be used to access system services without issue. Attempting to login to AFP shares or setup iCal for shared calendaring using the users login credentials worked fine.

Several reboots & rebinds later I dug through the system log to find the following error: error = Error Domain=NSOSStatusErrorDomain Code=-35 “Operation could not be completed. (OSStatus error -35.)” (no such volume).

Turns out the was unable to create the mobile account at login. The solution was to create it manually. On the client computer, login as an administrator & run the following two commands as root:

sudo /System/Library/CoreServices/ -n username

sudo createhomedir -c -u username

This forces the creation of both the mobile user account & their home directory. Log out & log in with your mobile user’s credentials – you should be able to login without issue. This should work for both Active Directory and Open Directory mobile user accounts.

Thanks to Rich Trouton of the macenterprise google group for posting the fix!

As of this writing, Snow Leopard Server is at version 10.6.1

snowleopard.jpgUPDATE: Due to some errors on my part, I have had to heavily edit this article. The information contained herein is now accurate. Sorry for the confusion!

I recently ran into a bit of an irritating issue while setting up directory services on a new server running Snow Leopard Server (10.6.1). It seems that as of 10.6, users without a value for their home directory (NFSHomeDirectory) are unable to create a home directory on managed clients. I had created a series of users and assigned them to groups. Every time I would log in to test, however, error messages would appear warning about problems creating the user’s home directory.

What is interesting, however, is that users can still access system services (AFP, iCal, etc) without issue. Attempting to login to AFP shares using the users login credentials works fine. Attempting to login to a managed client, however, generates a warning message about being unable to locate the users home directory. When logged in, the user cannot create new files or folders on the desktop – the whole system behaves as if the user has no permissions for the desktop.

A quick look at the logs on the server hinted that the issue was tied to home directories, with several warning messages about problems with home directories: CFPreferences: user home directory at /99 is unavailable. User domains will be volatile.

Sure enough, when I looked in WGM, I had forgotten to assign home directories to the accounts. I quickly corrected this (relatively large) oversight & BAM! clients were logging in without issue!

This is a fairly sharp departure from previous behavior. Prior to Snow Leopard, network users with no home directory assigned (NFSHomeDirectory=99) could still login; their home directories were simply created in a folder named “99” in the root of the boot volume (/99/user1). As of 10.6 this behavior seems to have changed. Why exactly, I’m not yet sure – although I imagine it must be tied to security.

My next post explores an issue where mobile account creation can sometime fail on login. Stay tuned!

As of this writing, Snow Leopard Server is at version 10.6.1.

wgmCreating network home folders for users in Open Directory is typically a fairly painless task using OS X Server. What can be a little more painful is trying to figure out how to create a clean, locally cached home folder on a client workstation. The only obvious options for home folders in Workgroup Manager are None & the creation of an AFP or NFS share that’s stored on the server.

While leaving the settings in WGM set to None does result in the home folder getting cached on the local machine, it’s a less than perfect solution. For starters, the profiles get cached in the root of the drive, under a directory labelled 99. Plus the home folders it creates doesn’t have the usual directory structure – they only contain a Desktop and a Library folder. Not quite what we’re looking for. Ideally, the home folder would get created in the /Users directory, using the standard home folder template just like a local machine account is.

The fix to this is to make sure the NFSHomeFolder attribute is set for all your network accounts. That’s what happens when you select an AFP or NFS share – the path to the network share is written to the NFSHomeFolder attribute in the LDAP directory. When you leave the home folder setting at None, the default value is assigned to NFSHomeFolder – a value which happens to be 99 (hence the 99 directory that appears in the root directory on client machines whenever a user without a specified home folder logs in).

Set Network Account Home Folders to the Local Users Directory (/Users):

  1. Launch WGM & login to your Open Directory server
  2. If the Inspector tab in WGM isn’t visible, enable it in the Preferences
    1. Check the box next to “Show ‘All Records’ tab and inspector
  3. Select a network user account & click the Inspector tab
  4. Locate the NFSHomeDirectory attribute – it should read 99 – & change this value to ‘/Users/username‘ where username is the shortname of the user.
  5. Save your changes.


I recently had a drive fail in a client’s RAID setup. 3 mirrored drives in a software RAID0 (mirrored) configuration. No big deal, you say! In a 3 drive configuration like that, you can swap the faulty drive without even losing any redundancy! Simple!


Physically replacing the drive went as planned, dead easy. But the rebuild failed contiuously. It should take hours (they were terabyte drives) but instead would stop after a few minutes, showing the replacement drive status as “Failed”. RAID Status obviously remained “Degraded”.

A bit of digging around on the web turned up this Apple knowledgebase article on rebuilding software RAID mirrors, which pointed out two VERY usefully pieces of information:

  1. You should use the command-line diskutil for rebuilding a RAID. Sometimes Disk Utility will be unable to successfully
    rebuild a degraded RAID mirror.

    • (Not an issue, this is standard practice anyways.)
  2. You should not rebuild the rebuild a mirror while it is the boot volume. Rebuilding a RAID Mirror will sometimes fail if it is the boot volume.
    • (Major issue, as it defeats much of the benefits of running a RAID in the first place! Sure, the data is safe – VERY important – but now I have to take a mail server offline for 12hours while the RAID rebuilds?!?!?)

The successful rebuild of the mirror involved both the above steps. The mail server was booted to an external drive and diskutil was used to rebuild the mirror. Before doing anything, however, I created a backup image file of the server (just to be safe…). The server was offline for approximately 12 hours, but it might have needed less – once I was confident that the rebuild was progressing successfully, I tried to enjoy the rest of my Saturday.

The moral of this story is obviously that software RAID solutions are in no way a substitute of hardware solutions. If you need guaranteed uptime, you need to invest – but we all knew that already… right?

For more information on rebuilding a software RAID in OS X, read Apple’s knowledge base article: How to rebuild a software RAID mirror.

MCX Lessons from Macworld

January 20, 2009

wgmManaging OS X, Greg Neagle’s OS X sysadmin blog, has a great PDF of slides from Greg’s Macworld presentation on MCX & managed preferences in OS X. If you’re involved in client management in any way on OS X, you should probably take a minute to check this out.

You can download the PDF direct from his blog here.