Using Profiles to Mount SMB Volumes @ Login

Your situation is not uncommon, nor is the issue. Whether its through a profile or via AD bind settings or some other method, the OS will try to mount the share its directed to mount at login, despite the Mac not being in range of the share to mount it. I've had numerous back and forth conversations with folks in Apple Enterprise support on this. They insist it should not work this way, but our first hand, real life experience says otherwise. I can only conclude the folks in enterprise support are being given bad information, or there is some additional configuration needed to prevent this behavior that has been lost along the way, and isn't being conveyed.

In the end, we, and I think many places, simply use a LaunchAgent that runs an app or script at login, that first checks to make sure your specific network is available, then determines the correct share to mount based on the user logging in, AD groups, etc. and finally, mounts the share, or at least attempts to. If the network isn't available in step 1, it just exits, no hang up, no spinning wheels while it tries to access something it can't possibly access. Since we started using this method, almost all login issues around share mounts have disappeared.
You could look at something similar to this. Its a shame we have to craft our own solutions to these issues as Apple just refuses to acknowledge that its a problem with their OS. I guess fixing a server mount bug isn't too high on their list of priorities. Gotta get new watches and Apple TVs out the door after all.

Also just wanted to point out that Enterprise Connect, from Apple, might potentially solve the above issue as well since it can be configured to check for the availability of the internal network on network state change and mount or re-mount any configured shares as needed. So it seems Apple does have a solution to the issue, but its not baked into the OS.

Thanks @mm2270

I too submited a RADAR years ago when trying to acomplish this via MCX/OD. I thought maybe Profiles would make this more dynamic, responsive, robust.

I BEGGED Apple to just give me a administrative preference to hide Finder warnings when a Login Item's network drive is unavailabe Thats all I wanted. Something like this:

defaults write com.apple.finder DisplayNetworkDriveMountError -bool FALSE

or this

defaults write com.apple.finder SupressNetworkDriveMountError -bool TRUE

My JumpStart engineer even said "I think it should just work". I was cautiously optimistic. Looks like I may need to craft my own. Thanks Apple.

Would you mind sharing your LaunchAgent and a example mount script? I have a couple (crude) tests in the works, but would like to see examples from "the real world"

@dstranathan Unfortunately, I can't post the Applescript app that does the work of mounting the shares here, because its not something I created myself. The LaunchAgent is dead simple and just runs the app at login, nothing else.

Fortunately. you can take a look at @bentoms' (MacMule's) write up on his process here: https://macmule.com/2011/09/08/how-to-map-drives-printers-based-on-ad-group-membership-on-osx/

It should give you a good framework to jump off of.

what if they log in to their computer off campus, but then come on campus? Are you going to tell them to log out and log back in?

Instead of auto mounting drives. Why not give them the choice to mount drives when and if they want to?

For instance a self service that installs a book mark for the network share onto their dock. They can click on it to mount the share when ever they want to. Regardless of when they logged in. Or if their drive has dropped out.

@tcam That's actually why ours is a double clickable app that lives in /Applications/Utilities. If they are already logged into their account and need to mount their shares after reconnecting to the network, they just double click the app and it mounts the share. So, it runs automatically at login, but the end user has the choice of running it manually whenever they want as well.

I do a similar thing right now for laptop users. Its a simple folder named "Servers" in their local homedir containing shortcuts to the SMB volumes, with an alias in their Dock. Some like i, some hate it ("Eww - don't pollute my Dock you evil IT person")

I also provision my file server's URL in the Finder "Connect to Server" box too. Most user dont mind the Command + K (Go > Connect to Server...).

My users are trained on how to browse the LAN, and also use the Apple Menu > Recent Items > Servers too.

At the end of the day, my CIO wants the Mac user experience to be similar (if not identical) to the WIndows user experience at login time: "Boom - here are your network drives, you're welcome."

@dstranathan How about a script that runs at login and on network change? If you can ping it then mount it.

@spraguga

I havent played with the "On Network State Change" Triggers yet. I was worried that it would be too chatty or too intense on the JSS (I have less than 300 Macs and our JSS is on-prem, so probably not, but hey - I'm new to JAMF and using kid gloves so far)

I havent played with "Custom Events" or "Make Available Offiline" either - they both look promising.

If I cant get Profiles to do my bidding for SMB mounts at login time, Ill likely either

A - Use a local script and LaunchAgent (deployed via a pkg)
B - Use a Policy (combined with scripts)

@mm2270

Illl take a look at Ben's information. Thanks.

I didn't realize you used AppleScript (figured it was Bash).

FWIW, I've tried profiles to mount shares and found too many bugs and oddities to use them in production.

Switched back to scripts used in JSS login policies. Much more manageable and predictable.

Thanks, @davidacland

Just curious, are you scoping the Policies to Network Segments, or are you doing the "Am I on the LAN?" logic from inside your scripts?

Edit - Oops, I just rememebered that you cant scope a Policy to a Netwrok Segment like you can with a Profile.

I normally put the logic in the script. I've had lots of cases where the IP address hasn't updated quickly enough in the JSS for network segments to work.

@dstranathan If you create a department then assign a network segment to that department, you can scope policies to the department. Not sure if it will help you but thats what we do to make network segments a bit more useful in our environment.

@nigelg I have both Departments and Network Segments set up in my JSS. However, in many (but not all) situations, I have departments that are in multiple segments (or vice-versa)

It looks like I I cannot assign multiple Departments to a Network Segment. Correct?

I have moved my network mount logic from Profiles into Policies.

I have a rough but effective script running that pings the file server and mounts drive(s) if ping is succesful - and fails silently otherwise. So far it is working OK. Much better than the janky Profiles I was testing previously.

What are your thoughts on the Frequency and Triggers for mounting SMB drives? Here is my current Policy:

Trigger: Login (duh)
Frequency: Ongoing
Make Available offiline: No
Payloads: The Payload for this Policy is just a single Bash script. I have not added a "Maintenance" Payload to update inventory. I see no reason to do so in this context, do you?

Script (stanza formatting sucks, I know...)

#!/bin/bash
#
#####################################################################################
#                                                                             Info:
####################################################################################
#
# Created December 2015
#
# SMB Volumes:
# -Collaborate
# -Projects
#- Homedirs
#
# Steps:
# Ping the file server once. 
# If server is available, mount the SMB volumes. 
# If server is not available, do nothing. Fail silently.
# Add logging information later?
# Will the dirs creted in /Volumes clean-up properly later? Avoid "drive-1" issues!
#####################################################################################
#                                                                       Variables:
#####################################################################################
#
SERVER1=server.domain
# $USER is determined by OS X (current user who is executing the script)
######################################################################################
#                                                                         Main:     
#####################################################################################
#
if /sbin/ping -q -c 1 ion.sgc.loc &> /dev/null
then
echo "File server $SERVER1 is responding. Mounting network volumes...";
#
# Mount Network Home Directory:
# Not using AD for this right now.
mkdir /Volumes/$USER; mount -t smbfs //$SERVER1/Homedir/$USER /Volumes/$USER
#
# Mount Common Drives:
/bin/mkdir /Volumes/common; mount -t smbfs //$SERVER1/common /Volumes/collaborate
/bin/mkdir /Volumes/projects; mount -t smbfs //$SERVER1/projects /Volumes/projects
#
exit 0
else
echo "Timeout. File Server $SERVER1 is not responding. Network volumes will not be mounted."
exit 1
fi

I agree, no need to update inventory every time as nothing is changing on the client. For the drive mounting code, I use AppleScript in bash these days as it handles the mount point creation a lot cleaner:

# Mount the drive
    mount_script=`/usr/bin/osascript > /dev/null << EOT
    tell application "Finder" 
    activate
    mount volume "$protocol://${serverName}/${shareName}"
    end tell
EOT`

There's a copy of our full script here: https://github.com/amsysuk/public_scripts/blob/master/shareConnect/shareConnect_Casper.sh

Thanks @davidacland

Im playing with your example code. Working Ok for my environemnt.

Big picture clarification:

You are scoping this to All computers and All users? (The script code decides who mounts what)
You are querying dscl for AD (or LDAP) group memberships, not using JAMF Departments.

I like the use of AppleScript's native hooks into OS X as I dont have to mess with creating the mountpoint sub -directories (and worrying if the sub-directories getting cleaned-up at unmount time, etc)

Applescript is definitely the way to go in regards to mounting a sharepoint as it simulates the Finder process, so no need to mess with pre-creating sharepoint directories, then mounting the share. Doing it that way generally leaves the directory in place when the share disconnects, so its not so great. Applescript handles this much better.

As for collecting inventory, I'll second that its not necessary to add that. However, check that its not already enabled in the policy, since I believe new policies have that option enabled by default. I may be wrong about that, but I thought that was what I saw one time.

EDIT: Ignore me on the Maintenance payload comment, I was thinking of the Restart Options payload being enabled by default (though not actually configured) Maintenance is not configured in new policies until you add it.

Hi,

The script example has the group membership logic built-in, although in most cases I prefer to use the built-in JAMF AD group membership functionality.

So in the policy we scope to all computers and use limitations to specify which AD groups can mount the share.

As we're an MSP, I have the code for dseditgroup in there in case a client can't or won't allow the JSS to access AD.

On a side note with AppleScript, talking to one of my colleagues today it was mentioned that the Finder activation bit might not be needed, cutting it down to:

# Mount the drive
    mount_script=`/usr/bin/osascript > /dev/null << EOT
    mount volume "$protocol://${serverName}/${shareName}"
EOT`

I haven't had a chance to test this yet though.

The "activate" verb wasnt required.

# Mount the drive
    mount_script=`/usr/bin/osascript > /dev/null << EOT
    Tell application "Finder"
    mount volume "$protocol://${serverName}/${shareName}"
    end tell
EOT`