Yosemite Automatic Home Drive Mount

jamesdurler
Contributor

Hi there,

We are currently testing 10.10 and are experiencing the following problem.

Our macs are bound to AD and when they log in the UNC path from AD is used to mount the home folder. This worked fine in 10.8/10.9.

For some reason, the home folder is now not mounting at all in 10.10. All I am seeing is a question mark on the dock which would indicate a nil alias but it seems like the share is not mounting at all as I am not seeing anything in /Volumes/ . Is anyone else having similar problems with yosemite and the AD plugin?

46 REPLIES 46

denmoff
Contributor III

I'm seeing this as well. Can you mount via the finder? I was at least able to do that without entering my credentials.

jamesdurler
Contributor

Yea it works perfectly via the finder and doesn't request credentials. Need to resolve the issue with it not auto mounting however. Not seeing any useful logs on why its failing !

sburrows
New Contributor III

We have noticed this on our 10.10 test machines as well, but sometimes it will mount. It seems to be hit or miss. When it doesn't mount, usually logging off and back on again resolves the issue.

I have always had issues with AD home drives mounting reliably with OS X. Using a Connect to Server entry seems to work every time.

dgreening
Valued Contributor II

Strange how this functionality is almost always broken when a new Mac OS drops...

davidacland
Honored Contributor II
Honored Contributor II

This is one of the reasons we disable that option and use a login script instead. It mounts every time this way.

just finished a 10.10.1 deployment with a login script and all is well.

mm2270
Legendary Contributor III

Like @davidacland, we disabled that function in the AD plug-in long ago and use a custom app/script called at login by a LaunchAgent and have no issues with mounts. In addition to working more reliably. it also helped us get around problems for some users where the network wasn't available and the plug-in was not timing out in an appropriate amount of time, so they were getting a very long login delay while the Apple AD plug-in kept attempting to mount their share. The script in the app checks to see if it can connect to our network first, and only if successful tries to mount their home share, or just exits. Having it as a double clickable app in the Applications folder means users can just double click it if they connect to the network later and it mounts their home drive.

jamesdurler
Contributor

thanks for the idea davidacland and mm2270. i put this together this morning. the only issue I'm having is using dockutil to add the drive in the dock - works perfectly when launching the script locally however, running it as a launch agent doesn't seem to work. this may be useful for some one

#!/bin/bash

#Script to check if we have a network connection and then mount users home drive
#This will be delivered by launch agent

#Author: James Durler
#Date: 3/12/2014

logFile="/var/log/UAL/homedrive.log"
touch $logFile

function mountDrive {

#Using $USER to determine the user running this command to be used in the dscl command to find users SMB Home Path smbhome=dscl '/Active Directory/ARTSLOCAL/All Domains' -read /Users/$USER SMBHome | awk '{print $2}' | sed -e 's/\\/smb:///g' | sed 's:\:/:g' echo "Untrimmed SMB Home Path is $smbhome" >> $logFile #trim the variable smbhome, so we can test if the file share we are trying to mount to is available #first we are removing the smb:// - this should always be the start of the users smbhome path newsmbhome=$(echo $smbhome | cut -c 7-) echo "Removed the smb:// variable is now $newsmbhome" >> $logFile #now remove everything after the first /, so delimitting by the / after INF-FS06 newersmbhome=$(echo $newsmbhome | cut -f1 -d"/") echo "Removed everything after the first slash, we now have the file share to ping for availability $newersmbhome" >> $logFile

#now pinging the file share to see if it is available if ping -c 1 $newersmbhome &> /dev/null;then #file share is available echo "Mounting Home Drive" >> $logFile mkdir /Volumes/Home Drive mount -t smbfs $smbhome /Volumes/Home Drive/ echo "adding dock item" >> $logFile /Users/Shared/dockutil.py --add /Volumes/Home Drive/ --view grid --display folder /Users/$USER else #file share is unavailable echo "File share is not responding" fi
}

#Check if the home drive is already mounted before doing anything else
if [ -d /Volumes/Home Drive ]
then
echo "Home Drive already Mounted, exiting Script"
exit 0
fi

if ping -c 1 inf-dc01 &> /dev/null;then
#inf-dc01 is responsive, get users SMB home path echo "inf-dc01 is responsive, getting users SMB home path" mountDrive

elif ping -c 1 inf-dc02 &> /dev/null;then #inf-dc02 is responsive, get users SMB home path echo "inf-dc02 is responsive, getting users SMB home path" mountDrive

elif ping -c 1 inf-dc03 &> /dev/null;then #inf-dc03 is responsive, get users SMB home path echo "inf-dc03 is responsive, getting users SMB home path" mountDrive

elif ping -c 1 inf-dc04 &> /dev/null;then #inf-dc04 is responsive, get users SMB home path echo "inf-dc04 is responsive, getting users SMB home path" mountDrive

else echo "No Domain Controller is responding, do nothing" fi

davidacland
Honored Contributor II
Honored Contributor II

In case it helps, I have been using mount -t smbfs for years, always had mixed results with folders being left behind, drives not mounting etc.

I've started using osascript a bit more recently which for your script would look like this:

# Mount the network home
    mount_script=`/usr/bin/osascript > /dev/null << EOT
    tell application "Finder" 
    activate
    mount volume "smb://${smbhome}"
    end tell
EOT`

It handles creating the mount point and can switch between kerberos and username/pasword very nicely.

(the EOT bit at the end can't have any whitespace before it in case anyone wondered!).

jamesdurler
Contributor

Hey David,

Thanks for that. My major problem right now is that dockutil for some reason isn't working properly when used with a launch agent.

a user launch agent executes this script - running the script manually works perfectly and populates the dock.

Has anyone had similar issues with dockutil and launch agents? I can see it is trying to add the dock item as the dock is killed and refreshed but no icon is added.

davidacland
Honored Contributor II
Honored Contributor II

Not sure about other people but I have always had this behaviour from dockutil. Sometimes it will work fine, other times it will fail. I've had more success using it to write into the user template folder so its not trying to do too much at login.

Its probably not dockutil's fault, the Dock is a surprisingly difficult thing to manage. I've had inconsistent results using Workgroup manager in the "olden" days and config profiles more recently. Preference caching in the recent OSes are making it even harder! Just to rule that out, try adding "killall cfprefsd" at the start of the dock util script.

russeller
Contributor III

Looks like they've made some changes in 10.10 with LaunchAgents. See here: http://stackoverflow.com/questions/26761552/osx-yosemite-loginwindow-agent-not-persisting-into-login it says:

I have heard that 10.10 has a complete rewrite of launchd, and that it no longer executes multiple launchd processes for each user but only has one and uses xpc (cross process communication).

I haven't done much more research but I was using a LaunchAgent with ```
LimitLoadToSessionType = Aqua;
```
and it is not launching in 10.10.1 when a user logs in to mount their homefolder. I'm looking at permissions, etc. I might have to change how it launches at login if I can't find a way to use a LaunchAgents in 10.10. Has anyone else figured this out already?

russeller
Contributor III

This guy kept accidentally calling a Launch Agent a "Lunch Agent", seems like a better name.
https://discussions.apple.com/thread/6622442?start=0&tstart=0

russeller
Contributor III

Yep- It was a permission problem for me. Works now.

RobertHammen
Valued Contributor II

@jamesdurler, I'm trying something similar (on Mavericks) with a launchd (to run the mountdrive script as the user), and while the SMBHome is mounted, dockutil doesn't add it to the Dock correctly (it adds the folder icon, but clicking on the it just reveals an empty folder). If I remove that folder from the dock, dismount the SMBHome, and then re-run the script manually, it works. Is this what you are seeing?

dmw3
Contributor III

Does a Launch Agent occur after pre-boot on an encrypted disk? If it does then it might solve a problem with encrypted disks.

Looking for a way around the issue of FileVault/Yosemite/AD UNC mapped home folder on a non-networked computer.

RobertHammen
Valued Contributor II

Yes. LaunchAgents run as the user, after the user logs in. Which of course happens after the FV2 preboot.

jubei
New Contributor II

Do you guys mind sharing your login scripts and user launch agents? Having this same issue. Thank you!

esantiago
New Contributor

Having the same issue. Our network home folder won't mount. It appears as a question mark on the dock.

Yosemite 10.10.3
JSS 9.72

davidacland
Honored Contributor II
Honored Contributor II

@esantiago are you using the AD plugin in directory utility to mount the SMBHome? If you are, a ? in the Dock is quite common for first login. I would suggest mounting the network home via a script instead.

GitHub link to our script is in this thread: https://jamfnation.jamfsoftware.com/discussion.html?id=14283

esantiago
New Contributor

@davidacland

Hey,

I am using the directory utility to mount the SMB home. Do I need to turn that feature off in directory utility for that script to work. I set that script as a log on script through policy in JSS. However It's still not mounting. I checked the logs of the policy and it shows it retrieving the SMBHOME attribute for esantiago ....

Thanks for your help

davidacland
Honored Contributor II
Honored Contributor II

Correct, you would use one or the other.

I would suggest testing it manually first when logged in as an AD user. If you are using in a Casper policy you might want to switch $USER for $3 as the policies will run as root otherwise.

dijuremo
New Contributor

So I am on 10.10.3 and I see that the user's home directory mounts, but it has the wrong permissions, which is why the user cannot access it. Any idea how to get this fixed?

I know some of you have suggested using scripts, but will those work when a user connects to the machine via ssh?

ae204212:~ root# grep nethome /etc/auto_master /nethome auto_nethome -nobrowse,hidefromfinder
ae204212:~ root# cat /etc/auto_nethome * -fstype=smbfs ://ae.nas.gatech.edu/&
ae204212:~ root# mount | grep dijuremo
//dijuremo@ae.nas.gatech.edu/dijuremo on /nethome/dijuremo (smbfs, nodev, nosuid, automounted, nobrowse)
ae204212:~ root# ls -ld /nethome/dijuremo
drwx------+ 1 root ADDomain Users 16384 Apr 29 18:21 /nethome/dijuremo

So I had tried to log in the machine as "dijuremo" and as you can see, the file system is mounted, but, the mount point is owned by root, so the user cannot write to it and this is messing up things.

davidacland
Honored Contributor II
Honored Contributor II

If I'm using mkdir to create the mount point and mount_smb, I would have the user do both of the tasks so there isn't a permissions issue.

dijuremo
New Contributor

Furthermore, I have discovered that mounts seem to work for "admin" users, but not regular users. I have two accounts, my account ae-dijuremo (which is an admin in the OS X machine) seems to be able to get the home directory mounted properly. However, dijuremo, a regular user, cannot.

ae204212:~ root# ls -ld /nethome/*
drwx------ 1 ae-dijuremo wheel 16384 May 5 15:19 /nethome/ae-dijuremo
drwx------
1 root ADDomain Users 16384 Apr 29 18:21 /nethome/dijuremo

FAIL for dijuremo
ae204212:log root# ssh dijuremo@localhost
Password:
Last login: Tue May 5 14:54:29 2015
Could not chdir to home directory /nethome/dijuremo: Permission denied
-bash: /nethome/dijuremo/.bash_profile: Permission denied

Success for ae-dijuremo
ae204212:log root# ssh ae-dijuremo@localhost
Password:
ae204212:~ ae-dijuremo$ pwd
/nethome/ae-dijuremo

dijuremo
New Contributor

@davidacland I am using automount in this case, which automatically should create the folders, so I think the issue is somehow with this daemon on the new OS X 10.10.X.

In our AD, all users have their attributes set, inluding home directories, so auto mount should try to mount the homes in /nethome/$username

msnowdon
Contributor

@davidacland ,

I just upgraded to Yosemite and now I am having the same problem regarding the home directory showing up as a question mark. If I use your script, do I have to modify anything? Also, how do I automate the clearing of the checkbox in Directory Utility "Use UNC path from Active Directory..."?

Thanks

Mark

davidacland
Honored Contributor II
Honored Contributor II

It will run as is, although there are a lot of script snippets on this thread now so I'm not sure which one we're talking about!

I'm referring to this:

https://github.com/amsysuk/public_scripts/blob/master/mount_SMBHome/mounthome.sh

To stop the AD plugin trying to mount the share you use dsconfigad in Terminal (or as part of a policy). I can't remember the exact option but if you use man dsconfigad in the terminal it shows you the available options.

mgarman
New Contributor III

I am experimenting here as well. I have a working Homes folder share on a Windows 2008 R2 server with Enumeration enabled. When accounts are created in AD, the user home is created, but empty. Permissions to this point are correct: User has rw for all subfolders and files. There is no Everyone ACL in this folder. All folder permissions for non-admin group access above this point are set only for "This folder only". Only administrator accounts have rw for "All Files and Subfolders" in the home share. The server also has Group Logic's ExtremeZ-IP set to share out the home folder share using AFP with Use for Home Folders enabled.

Client is a 10.10.3 iMac that is bound to AD with Force local home unchecked. Use UNC path is checked. Protocol is either AFP or SMB

Starting from an empty home folder, if AFP is enabled for the client protocol, the first login creates the usual home folder structure. Everything works and it works as expected.

Starting from an empty home folder, if SMB is enabled for the client protocol, the first login creates the usual home folder structure BUT an ACL for Everyone is applied to all of the top level folders EXCEPT Library and Documents. This Everyone ACL denies traverse permission to all users which includes the user, admin users and everyone else. The user can create folders on their Desktop, but can't see them. They can't see Music, Pictures, Documents, Movies folders that are there, but can't be seen.

Since OS X is building this initial folder structure, The Everyone ACL must be coming from the AD Plugin when using SMB as the protocol?

Anyone else see this?

msnowdon
Contributor

@dpeterka ,

All my home folders are pre-created when accounts are created in AD. The permissions are set at that time. Users logging on with a Mac dont change the ACL at all. We have 'Force local home directories" checked off. I also have "Use UNC path from Active Directory with network protocol:" set to CIFS.

I have a separate Config Profile to show all drives & network shares on the desktop.

Everything seems to be working fine for me. I should mention we are not using Enumeration yet since the servers still need to be upgraded.

Thanks

Mark

mgarman
New Contributor III

@msnowden,

When you say home folders are pre-created when accounts are created in AD, does that include the Apple specific subfolders like Desktop, Documents, Downloads, Library, Movies, Music, and Pictures? If so, how are you doing that from AD? All I am seeing is a home folder named after the username that is empty. The subfolders are created upon first login from a Mac.

msnowdon
Contributor

@dpeterka ,

We are checking (selecting) "Force local home directories" so there are no Apple specific folders being created. If you do not select that option, I believe it works as a roaming profile.

mgarman
New Contributor III

OK, so our findings are that while the home folder is created properly (when the AD account is created), the Apple specific subfolders have permissions issues when they are created when the user logs in for the first time. The user template being using on OS X is not creating correct permissions.

Upon further investigation, one permission that is being applied is Deny Delete to Everyone. This should not keep the user from seeing the contents of their Desktop folder, but it does. Remove this permission and the user has access. This happens when the home folder is auto mounted using SMB.

Using AFP (via ExtremeZ-IP) - to the same server and empty home folder - the Apple folders are created - also with the Deny Delete to Everyone permission. In this case, the user CAN read and write into their Desktop folder. They can even delete the Desktop folder despite the Deny.

I'm just not understanding these permissions and the user experience here.

bcourtade
New Contributor III

Something I found with DFS in our environment is that the home folder would mount to the root of the DFS share, so a path like smb://domain.com/data/staff/user would mount to /Volumes/data. So if you have any other policies that mount from the same DFS namespace, such as a smb://domain.com/data/shared folder, they would fail. Or if the other policy goes first, the home folder mount would fail and show a question mark because /Volumes/data/ already existed.

Once I disabled the automatic home share mount and set up a profile to mount smb://domain.com/data/ once at logon, all my problems seemed to go away. The alternative I suppose would be to make sure that home folders are under a different namespace than everything else.

marklamont
Contributor III

If anyone is interested I have written a script, which we bundle into an automator app, that will allow users on non AD bound Mac's to connect their home drive easily. It prompts for their username and password then connects to AD to find the home folder path then mounts it.

I also did a version for AD bound Mac's which is of course easier.

both of these can be set as a login item and run manually as required.

I will post my code if anyone wants it?

tburris
New Contributor

Hey, gang. Just getting into scripting the login call. I'm guessing your scripts are all built with the predetermined fact that user name and user share name are the same?

For us, users have a separate AD login from their directory path for the network home drive.

davidacland
Honored Contributor II
Honored Contributor II

@tburris that would work fine. If the correct value is listed in the SMBHome attribute in AD, then the script I posted above would work ok.

If it's different, you can alter or add to the server path variable to accommodate the changes.

jamesdurler
Contributor

yea exactly, if the server name differs from the value in smbhome you can just cut the server name out from the variable its stored in and then add the correct server name to the variable.

brunnalls
New Contributor

@marklamont

I would love to checkout your scripts for non AD bound machines. This has been proving to be a major headache to get functional.

Thanks!

marklamont
Contributor III