512FinderLeopard_Full.jpgAn ugly bug has surfaced in Snow Leopard that has resulted in users ending up loosing the contents of their home directories. It appears that a users home directory can be deleted if a users logs in to the Guest Account in Snow Leopard. This behavior has been confirmed by users on Apple’s discussion board, as well as in blogs like MacFixIt.

Apple has reportedly acknowledged the bug and is working to resolve the issue. It is important to note that this is only affecting users who have upgraded from Leopard (10.5) to Snow Leopard (10.6). Clean installs of Snow Leopard appear to be unaffected.

Until this bug is resolved it is highly recommended that the Guest Account be disabled on any systems that have been upgraded from 10.5, since accidently logging in to the Guest Account could potentially delete user data. To disable the Guest account follow the instructions below:

1. Open System Preferences.
2. Click Accounts.
3. Select Guest Account from the list of users & uncheck the box beside “Allow guests to log into this computer” (You may need to enter your password to do this).

If you require a guest account at your location, you can create a standard user account & enable Parental Controls to replicate the limitations of the Guest Account. Please be aware that the account will not be deleted when the user logs out, however.

If you have not yet upgraded to Snow Leopard, it is recommended that the Guest Account be disabled before upgrading your OS. You can then safely re-enable the Guest account once Snow Leopard has been installed without worry about data loss.

Unfortunately, the only way to retrieve data lost because of this bug is by restoring from a backup. If you need to restore your data & you have a recent backup, MacFixIt has an excellent article on how to restore a lost home folder.

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 ManagedClient.app 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/ManagedClient.app/Contents/Resources/createmobileaccount -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.

iphone_homeApple’s recently released iPhone OS 3.1 has caused headaches & more than a little confusion for some users with Microsoft Exchange accounts. While the OS 3.1 update improves security policy adherence for iPhones when connecting to Exchange Servers, it also has the unfortunate side effect of breaking security compatibility with pre-3GS iPhones & all but the most recent iPod touches. The end result: many iPhone users who upgraded to OS 3.1 suddenly fond they could no longer sync with any Exchange Servers!

Fortunately, the synchronization issue is limited to Exchange 2007 Servers running SP1 & above, & there is a work-around to re-enable synchronization. Unfortunately, the work-around requires either convincing Exchange administrators to create a security policy exception or rolling back to OS3.0 on the iPhone.

In order to re-enable Exchange syncing with pre-3GS iPhones, Exchange administrators will need to create an EAS policy exception that will allow connections to mobile devices that do not support device encryption (either globally or on a per-user basis).

If the creation of policy exceptions is not an option (& that will likely be the case more often than not) there are 2 options: 1) upgrade to iPhone 3GS or one of the latest 32GB or 64GB iPod touch models, or 2) rollback to OS 3.0 (what will undoubtedly be the most popular solution).

The easiest way to rollback to OS 3.0 is obviously to restore the phone from a recent backup using iTunes (you did create a backup before you upgraded your phone, didn’t you???). Apple has a support article detailing how to backup, update, & restore iPhones & iPods. In case of emergency (ie: no recent backups!) you can go to this site to download firmware for iPhones & iPods. [NOTE: This site is NOT supported by Apple in ANY way!!!)

Finally, Apple has also updated it’s Enterprise Deployment Guide for iPhones. If you’re a sys-admin involved in the deployment & management of iPhones &/or iPods in an enterprise environment, this doc is a must-read.

Snow Leopard Cheat-sheet

August 31, 2009

SnowLeopardLast Friday, Apple released OS X 10.6, “Snow Leopard” to the general public. There’s been quite a bit of excitement building around it’s release, although unlike the media & PR hype surrounding the release of Leopard, this time around the buzz seems a little more organic, building more through blogs, consultants, techs, & users instead of corporate PR departments.

While I haven’t yet done extensive testing of Snow Leopard’s newest features & enhancements (I spent the days following it’s release in the mountains of Garibaldi Provincial Park), I did make some time to put together a quick ‘cheat-sheet’ of key features, enhancements, & system requirements for the new OS. Be sure to stay-tuned, however. There’s sure to be more Snow Leopard posts to follow…

Snow Leopard Cheat-Sheet

$35 Upgrades!!!:

Thats correct. Apple is offering a $35 (US$30) upgrade disc for users who have OS 10.5 (Leopard). What Apple has not announced is that this upgrade disc will also upgrade your OS X 10.4 (Tiger) systems as well!  Thank you Apple for the cheapest OS upgrade in history…

Snow Leopard System Requirements:

  • Intel processor with 1GB of memory
  • 5GB of free hard drive space
  • DVD drive (for installation)

Key Features:

  • Speed – the first thing everyone is noticing is how much of a performance boost Snow Leopard is over pervious versions of the OS
  • Mail – support for Microsoft Exchange!!!
  • Cisco VPN support – Finally!!!
  • Ejecting volumes – no more “unable to unmount <NAME> because the disk is in use” errors
  • Customizable spotlight searching
  • Automatic print driver updates – boring but practical!
  • HFS+ read support for Boot Camp – access your OS X files while booted to Windows

iPhone SMS Security Patch

August 10, 2009

iphone_homeThe iPhone OS 3.0.1 that was released on July 31 patched a security flaw that could have allowed hackers to remotely control iPhones by launching a text-message attack. Security researchers publicized the exploit at the Black Hat cybersecurity conference and Apple posted the security patch the following day.

While Apple moved quickly, Chris Miller, one of the researchers who publicized the exploit noted that he notified Apple about the flaw nearly a month earlier and that it was first discovered in OS 2.0. It may have taken a public exposure to jump start the release.

Read more about the SMS exploit at Wired.com.

iphone_homeOn of my personal favorite features in version 3.0 of the iPhone OS is the internet tethering. My internet recently went down & it was a day or two before a tech was out to fix it (that’s service, isn’t it?). With several deadlines looming, tethering my laptop to my phone meant not having to spend two days working out of a coffee shop. Unfortunately, the deadlines also meant that I didn’t think to check Rogers’ policy (& pricing!) on tethering beforehand.

Turns out it’s not so bad. From the iPhone Smartphone Plans page on the Rogers website:

Tethering Policy
Tethering is the use of your phone as a wireless modem to connect to the Internet from your computer. For a limited time, if you subscribe to a data plan which includes at least 1GB of data transmission between June 8, 2009 and December 31, 2009, and if you have a compatible device, you may use tethering as part of the volume of data included in your plan at no additional charge. Tethering cannot be used with data plans of less than 1 GB.

For the time being, at least, data is data as far as Rogers is concerned. What will happen as of January 1st, 2010 is anyone’s guess, but for now as long as you have subscribed to a data plan of 1GB or more, there are no additional charges for data transfers using tethering.

X1Zero also wrote an excellent article for iPhone in Canada on the tethering policy for Rogers & Fido.

Follow this link for Apple’s System requirements for internet tethering.

Happy tethering!

apple-mail-iconI recently started experiencing an issue with Apple’s Mail application – every time I would select an email with an attachment, Mail would freeze for a few seconds before shutting down with the standard “unexpected quit” error dialog. I originally suspected corrupt emails, thinking back to issues with corrupt emails crashing Entourage if the Preview pane was enabled. Except that this time Mail would crash on EVERY email with an attachment – & there was no way that every email coming in was getting corrupted.

I cleared caches, rebuilt the mail index, removed Mail’s plist, even repaired permissions – all for nothing.

I finally stumbled onto a thread on the Apple Discussions forum suggesting that Mail might not be the correct version for the OS that I was running (10.5.7) & that the 10.5.7 combo updater should be re-installed.

Sure enough, here’s the version I was running when Mail was crashing:

Mailv3

And here’s the version that SHOULD be running under 10.5.7:

Mailv3.6How does this happen?

I had recently performed an archive & install on my laptop & being my overly cautious self, I hadn’t deleted the old System files (the Previous System folder). Turns out that when I ran the 10.5.7 combo updater after doing the archive & install, the combo updater actually updated the files in the previous System folder, not the newly installed System files!!!

The fix? Move the Previous System folder to the trash & re-run the 10.5.7 combo updater. Suddenly Mail is v3.6 & everything runs flawlessly again!

Thanks to Ernie Stamper on the Apple Discussions board for identifying this deceptive (& peculiar) bug!

iphone_homeI recently ran into some serious issues getting a client’s Shaw email account configured on their new iPhone. Using the settings copies from Mail, sending or receiving email on the phone would hang, sometimes taking the better part of 15 minutes & sometimes never sending at all. Often the the entire send/receive process would hang, requiring a reboot of the phone.

A bit of research (& a call to Shaw tech support for confirmation) revealed that Shaw has particular settings for use with mobile devices and that the standard settings used with desktop email applications will not work. More importantly, using Shaw’s own SMTP servers is not recommended by Shaw – for best performance, Shaw recommends using the SMTP server provided by Rogers or Fido.

What is frustrating about this arrangement, however, is that my experience has shown that even when using the SMTP server from Fido or Rogers, if wifi is enabled & connected to a wireless network, sending mail still takes so long as to be virtually unusable. In fact, in a thread posted on eh-mac.ca, a user states that Shaw tech support recommended disabling wifi when sending email – something which I confirmed provides a dramatic improvement in performance sending email.

Sigh.

On that note, the following are the settings to be used for setting up Shaw email on your iPhone. Please be aware – if you lan to configure a Shaw email account on your iPhone it is HIGHLY recommended that you disable wifi before sending email!

Setup Shaw email on the iPhone:

  1. Touch Settings
  2. Touch Mail, Contacts, Calendars
  3. Touch Add Account
  4. Touch Other
  5. Acount & Password are your Shaw email account & password
  6. Select select the POP tab
  7. Username is the part of your email before @shaw.ca
    1. ie: for name@shaw.ca would be name
  8. Host: pop.shaw.ca
  9. Outgoing Mail Server: gprs.fido.ca (Fido) or smtp.rogerswirelessdata.com (Rogers)

Remember! If you have trouble sending email over wifi, turn your wifi OFF & resend!

Shaw’s Residential Email Service Details (external link)

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.