we've been seriously scratching our heads on this issue for the last few days. It's now time to ask other professionals on possible solutions for this.

The situation and what we're attempting to do:

We have some mac computers that we've joined to the campus Active Directory domain (which we don't have domain admin privileges on). These mac users use their AD accounts to login to their macs, which of course authenticates with the campus DCs using kerberos. We are trying to set them up as "mobile accounts", such that they hit their network home in most cases, but can fall back to an auto-synced local home directory. This network home resides on a Windows 2012 server we control, and they hit it via SMB.

For whatever reason, their mac computers are NOT correctly mounting the network location as their home. The users have full R/W access to the network location, and they are easily able to mount to it once they login to their macs. The issue seems to be getting the computer to respect what we've specified to be their network home directory in Active Directory.

To clarify again, we do NOT have domain admin privileges on the domain we're authenticating into. We do have the ability to set a couple special attributes on the user accounts such as "homeDirectory" and "unixHomeDirectory". I've set the value to "\server.something.edu\username" for both attributes, although technically the "homeDirectory" attribute should only be used by Windows users.

Anybody have a solution to this? We've exhausted our Google searches, read through countless threads everywhere and couldn't find a solution. Which is unusual because this seems like something that would be commonly done in an enterprise environment where windows and macs need to interop.

What I think the mac SHOULD be doing is taking the "\server.something.edu\username" string from Active Directory on login, mounting it, and setting it as the user's network home.

And just so others don't suggest it, we have already set the correct options in the mac's Directory Utility program to "Use UNC path from Active Directory to derive network home location" using the SMB network protocol.

Additionally, here are some of the string formats we've used for the "unixHomeDirectory" and "homeDirectory" attributes in Active Directory, and their results:

//server.something.edu/username (created the directory locally)

://server.something.edu:/username (couldn't locate, set home to / )

smb://server.something.edu/username (couldn't locate, set home to / )

//server.something.edu:/username (created the directory locally)

I know some of the above sounds silly, but we thought we'd try random formats because we're not even sure what format it's really trying to accept.

Another important question I guess is are we setting the correct ActiveDirectory attribute by using "unixHomeDirectory"? Are we supposed to be setting something else to have the MAC recognize and use it as its' network home location?

The Mac is running OSX 10.10 (Yosemite), and we're trying to get it to mount to a Windows Server 2012.

Thanks for any insight into this!

  • Nice to see other Higher-Ed people on here.
    – Joel Coel
    Sep 25, 2015 at 19:57

2 Answers 2


Okay, after a lot of further digging, we've managed to come up with a solution.

The apparent problem: It seems like the MAC OS doesn't enable network-home syncing via the GUI, even if you have all the options set correctly.

There's a binary executable found here: /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount

It doesn't have a man page, but running it without any arguments/switches lists some options for it.

We used this line (from the same dir as the executable): ./createmobileaccount -vsn username -u smb://some-server/share/username

This enables the mobile account to use a network share as its real HOME directory, and correctly syncs all the user's profile items.

After running the above command, to ensure that everything's working as expected (or to further configure the sync options), go to Users & Groups in system preferences, and when you highlight the user, you should now see the "Settings.." button enabled for the Mobile Account. Here, you can select which folders to have synced, at what time intervals, etc. You probably also want to check the "Show status in menu bar" option, which will allow the OS to display an icon on the menu bar for the user to quickly sync between the local and network stores, and quickly access the sync preferences.

Hope this is helpful to someone. Cheers!


As far as I know, OS X ignores the unixHomeDirectory attribute. It uses the homeDirectory attribute to figure out where the Windows home is and mount that. The homeDirectory attribute must be in UNC format, which means it should start with two backslashes, and use backslashes as path delimiters. I don't know if it's critical, but generally there'll be a single shared folder on a server, with different users having their homes as subfolders of that shared folder. Thus, the standard format for the homeDirectory value is something like "\server.something.edu\sharedfolder\username".

Also, when the OS X client is set to use "mobile" accounts, it will always use a local home folder on the client (usually /Users/username). It'll try to mount the network home (when it's available) and can be configured to sync between that and the local home, but the local is always what's directly used.

  • Hey Gordon, thanks for the information about the attributes. That's very important information that I was unable to dig up while scouring through various searches. I found a solution to getting the mobile accounts working correctly, as posted by my answer. It required the use of a command line tool to truly enable mobile accounts using a network store as its home. Cheers!
    – Isaiah Lee
    Sep 29, 2015 at 17:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.