Resolving HomeSync Errors on SMB

Posted: October 27th, 2010 | Author: | Filed under: Active Directory, Collaboration, Mac OS X Server, Snow Leopard | Tags: , , , , , , , | No Comments »

This is a follow up post in regards to my previous update:

A client of mine is being plagued with HomeSync errors on a Windows backed file server. One user in particular had over 2,000 file sync conflict issues, two others had around 70. After investigating the logs I believe I have an explanation as to why HomeSync is failing. To understand my theory I’m going to explain a bit about permissions on the Mac side.

When any Mac users logs into the desktop their home is mounted from the server into a “magic” folder. I say “magic” because technically it’s not a folder, it’s a program. The directory “/Network/Servers” is an auto mount program, if you enter this directory on the command line or in the GUI and specify a sub directory, such as “/Network/Servers/” the computer will try to contact over AFP, NFS, and SMB, to get a share listing and then display that listing as subfolder to the FQDN. For our example we would receive the following folder listing as user1: user1$ ls -al /Network/Servers/
total 36
drwx—— 1 user1 wheel 16384 26 Oct 15:17 Homes user1$

We see here that there is only one entry “Homes” but notice the owner and group. The owner seems fine, user1, however the group is “wheel” Wheel is a local group on every Macintosh that is more or less a system group. The share is mounted as group wheel because the mounting program runs as “wheel” Thus all the directories inside of user1’s home folder also have the group “wheel”

Let’s compare group owner to what is assigned when we mount the share manually:

vaW80401YGAGZ:Volumes user1$ ls -al /Volumes
total 72
drwxrwxrwt@ 9 root admin 306 26 Oct 22:11 .
drwxrwxr-t 30 root admin 1088 26 Oct 13:14 ..
drwx—— 191 user1 DOMAIN\domain users 6450 21 Oct 11:05 CurrentProjects
drwx—— 1 user1 DOMAIN\domain users 16384 26 Oct 15:17 Homes
drwx—— 1 user1 DOMAIN\domain users 16384 26 Oct 15:36 Production
drwx—— 31 user1 DOMAIN\domain users 1010 15 Oct 14:11 Promo
drwx—— 41 user1 DOMAIN\domain users 1350 26 Oct 20:53 SCANS
lrwxr-xr-x 1 root admin 1 26 Oct 13:13 Workstation -> /
drwx—— 23 user1 DOMAIN\domain users 738 26 Oct 15:26 joost

See that? The group is different! The mac mounts the directory as the proper default group “DOMAIN/domain users” for the user user1. I know this is the default group for user1 by asking the AD server details about the user1 user:

vaW80401YGAGZ:Volumes user1$ id user1
uid=421864987(user1) gid=1278872894(DOMAIN\domain users) etc……

Now that we understand a little about permission sets in the Mac world I’ll explain my theory.

When I a HomeSync user authenticates for the first time the Mac must mount their home directory in /Network/Servers and thus the group owner is set to “wheel.” The contents of the users home directory is then copied to “/Users/” for our continued example it would be /Users/user1. Here’s the kicker: when the Mac wants to do any HomeSync after the initial is complete, it does not mount the user’s home directory to /Network/Servers. Instead the Mac mounts the home directory to /Volumes like a standard manual mount. Therefore the group ownership in the user’s local home folder DOES NOT match the group ownership of the user’s server side home folder. Thus, HomeSync tries to update the server side’s group ownership to the group “wheel.” This is usually when all the errors start spewing out of HomeSync because the Windows server has no record in Active Directory of the group “wheel”

I then went on to test my theory. I changed the group ownership for three separate user’s LOCAL home folders from “wheel” to “DOMAIN/domain users” For one user this resolved 68 of 70 HomeSync errors. For two others it resolved all of them.

There are other problems regarding HomeSync that are not included in this above mentioned theory such as illegal characters. For one example, Parallels is installing files into ~/Applications that have the { } characters in them. This is causing more problems to the HomeSync users. I have excluded this directory from synchronizing, however there are more HomeSync issues because of these illegal characters.

Apple Magic Triangle Deployment Results

Posted: October 15th, 2010 | Author: | Filed under: Active Directory, DNS, Kerberos, LDAP, Mac OS X Server, Migrate, Snow Leopard | Tags: , , , , , , , | No Comments »

This is a follow up to my last blog entry: Magic Triangle Setup with Windows File Server backed Portable Home Directories. Myself and a team of amazing people deployed the Magic Triangle solution in an architectural firm that recently was involved in a merger and needed to be brought into one unified “domain.” I place that word in quotations after some disagreements and long discussions with AD administrators as to the default definition of the word. Before we begin let’s just go over our Magic Triangle deployment and the roles of our servers.

  • is the local AD domain controller.
  • is the Windows based file server for all network home directories
  • is the Open Directory server which was also bound to AD
  • is the OD replica and netboot server for Deploy Studio
  • For all intensive purposes, the migration went fairly smoothly. The client was quite happy with the result, although the users of the network do not have as fast of a desktop environment as they did with a pure Macintosh network. The final outcome was Mac clients bound to both AD and OD. AD handled all the user and group authentication and authorization while OD took care of computer and group client management through MCX. I put a standard computer heirarchy in place on the OD side for computer group so different settings could be applied to different sets of computers. Such as, making all laptops automatically create portable home directories and install the HomeSync menu in the top menu bar. However, there was one very strange problem I encountered while binding the Macintosh clients to the Open Directory server.

    Normally, when you set “Require authenticated binding between directory and clients” to on in Server Admin the Mac client will prompt you for directory administrator credentials when binding a client. However, this was not happening for us. We were using 10.6.4 server and client everywhere, yet the clients were just not asking for authentication. Thus, a computer record was not being generated on the server side. What I did for the first few test cases was create computer records manually inside of Workgroup Manager, but this was not fun and tedious.

    Update: One of my readers, JJ, pointed out a great kb article from Apple on how to require directory authentication while binding. End of Update

    I whipped up a quick AppleScript to bind the clients for me, this script had the diradmin login and pass embedded in it which I know is not best practice yet it was a temporary fix. The reason for using the script is so that the command line utility dsconfigldap is passed the ‘-f’ flag which forces the client to authenticate to the directory server.

    The script is as follows:

    tell application "Terminal"
    do shell script "dsconfigldap -u diradmin -p 'diradminpass' -f -a -c `hostname` -n -l localsudouser -q localsudopass -v > /Users/Shared/odbind.log" with administrator privileges
    do shell script "echo 'Writing Search policy to plists' >> /Users/Shared/odbind.log" with administrator privileges
    do shell script "defaults write /Library/Preferences/DirectoryService/SearchNodeConfig 'Search Node Custom Path Array' -array '/LDAPv3/'" with administrator privileges
    do shell script "defaults write /Library/Preferences/DirectoryService/SearchNodeConfig 'Search Policy' -int 3" with administrator privileges
    do shell script "defaults write /Library/Preferences/DirectoryService/ContactsNodeConfig 'Search Node Custom Path Array' -array '/LDAPv3/'" with administrator privileges
    do shell script "defaults write /Library/Preferences/DirectoryService/ContactsNodeConfig 'Search Policy' -int 3" with administrator privileges
    do shell script "echo 'Successfully added the Open Directory server to your search path' >> /Users/Shared/odbind.log" with administrator privileges
    do shell script "echo 'Writing LDAP in your search paths' >> /Users/Shared/odbind.log" with administrator privileges
    do shell script "dscl /Search -append / CSPSearchPath /LDAPv3/" with administrator privileges
    do shell script "dscl /Search/Contacts -append / CSPSearchPath /LDAPv3/" with administrator privileges
    end tell
    tell application "Finder"
    display dialog "Computer is now bound to Open Directory as " & (do shell script "hostname")
    end tell

    File Migration from Apple Filer to Windows Filer

    This was one of the more challenging issues at hand. We had a whole bunch of OD user’s home folders on two Apple XRAIDs served out via AFP and needed to move the data to the Windows Filer using SMB. What we ended up doing is creating an LACP link to a MacPro and using the following script to migrate the users one by one. is a shell script that mounts two network homes for one user, one from AD and one from OD. It then transfers all data from OD to AD via rsync. To make this script work it depends on a couple things.

  • The users to be migrated are entered into a file called ‘users’ with NO extension in the following format
    1. oduser:aduser
  • When the script executes it will create the folder /Users/Shared/syncit_logs and two log files for each user. username.log username.err. The .log is all the stdout of rsync while .err is all the errors.
  • And finally when you download the script you’ll need to edit the variables at the top of the script with the FQDN’s for you file servers and shares.

    You can get the script here.


    Home Directory Ghost Mount
    One issue that we’ve seen appear more than once is home directory ghost mounting. When a user logs out of their profile sometimes their home directory does not unmount cleanly. As a result when the user tries to log in again on the same workstation they are unable to due to the computer believing the home directory is already mounted. This may also affect logins of the same user account to other workstations due to the home directory filer not timing out the mount session.

    Slow Network File System Access
    There have been at times severe client stalls due to slow file system access. This was noticed on literally zero network traffic congestion. This is a noted issue from many different implementations of using SMB shares for Mac home directories. Read for more information. One suggested solution is to turn on Internet Sharing on the Mac client, however this is not a wise idea.

    Portable Home Directory Will Not Sync
    Sometimes homesync will become cranky. Definitely cranky. The easier and fastest way to resolve a home directory that does not sync is to perform the following.

  • Erase the contents of the users’s ~/.FileSync and ~/Library/FileSync directories.
  • Manually mount the user’s network home directory and erase the same directories on the server
  • Try the sync process again. Note: It will take longer to catalog the file system.
  • For most HomeSync problems it usually has something to do with file conflict resolution. To find out always open and look at FileSyncAgent.log. Try to perform a FileSync and watch the output of the log. If you are having problems with an initial sync try erasing the login.keychain file found in ~/Library/KeyChains on both server and client. Many times this will cause problems due to The Chicken and The Egg issues.

    Illegal Characters in File Names
    “ ‘/ \ + * ( ) [ ] are all illegal characters for file names on the Windows File Servers, as are directories or files that end in a space. As a result you may have issues creating working with these files. The Windows file server use unicode to map these characters, however there are failures often. Resolution is done by manually replacing filenames. This is also a LARGE contributor to File Sync failing.


    Like I mentioned at the beginning everything went quite smoothly. There were of course strange things that happened through out the deployment, and the short one week runway I had to prep for this was WAY too short but in the end we pulled it off. If any of you out there are planning on deployment or need questions answer feel free to contact me via the About Me button at the top of blog!

    Update: Please check out my next post regarding HomeSync errors on an SMB server.

    Update 2: One of my readers, JJ, pointed out a great kb article from Apple on how to require directory authentication while binding.