Mounting Network Drives via Config Profile's

KCH080208
New Contributor II

I have been using config profiles to mount two network drives we have since we got the suite. This past week we changed the drives up a bit so i did some testing by setting up a new config with our old settings and put a few computers in there. I than updated the path in that config. so it was for example smb: etworkdrive.school.eduj-class and it changed to smb:dfs.school.eduj-class. For all my test cases it replaced the old share with the new one and my login items reflected that as well. Since implementing this I have had a few calls where people are getting multiples of the drives. I checked their login items and sure enough they have 4 network drives and two config profiles. One that has the old drives and one that has a new one.

Am I correct in saying that if I were to just update a config profile it should than just update that config profile on the computer not add a new one and still have the old?

9 REPLIES 9

davidacland
Honored Contributor II
Honored Contributor II

Assuming you're editing the same config profile on the server that's certainly what should happen.

From what over seen, mounting shares from config profiles hasn't been very reliable and we've had to do some remedial work after changing server or share names.

It's the same with Apple's Profile Manager.

We stick to login scripts for now until this gets a bit more stable.

KCH080208
New Contributor II

is there a login script on jamf somewhere that you followed?

davidacland
Honored Contributor II
Honored Contributor II

Hi, this is a cut down version of the script we use sometimes:

#!/bin/bash

username="$3"
    if [ -z "$username" ]; then       # Checks if the variable is empty (user running script from Self Service)
        username="$USER"
    fi
    echo "User: $username"
protocol="$4" # This is the protocol to connect with (afp | smb)
    echo "Protocol: $4"
serverName="$5"   # This is the address of the server, e.g. my.fileserver.com
    echo "Server: $5"
shareName="$6"    # This is the name of the share to mount
    echo "Sharename: $6"

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

exit 0

You add the script and set the parameter labels as:

d6c44fa5f08e41508dd5c13204dc665d

Once thats in place you can re-use the script in a policy, setting the relevant options:

fb84afe362b84e1cbc4ece001fa85b3a

Hope this helps.

bentoms
Release Candidate Programs Tester

@KCH080208 Here's my version. Which isn't dissimilar to what @davidacland poated.

carlo_anselmi
Contributor III

Hello everyone, despite the not so encouraging comments and suggested alternative routes, I am testing config profiles to manage network volumes with a "login items" payload.
I can limit the profile (applied at user level) to a specific Active Directory usergroup and its network volumes. This all seems to work fine, except when the computer if off network (e.g.: laptop)
When there's no network available, being the profile still there, an error message appears in the Finder, as the server is obviously not reachable
fc6aa3e943244231ba08f76bcea36706

Would you think there's a workaround for this? Many thanks for your help!
Ciao
Carlo

davidacland
Honored Contributor II
Honored Contributor II

I don't think the config profile approach is that flexible unfortunately. It just adds the share to the login items and doesn't do any checking whether the Mac is on or off the network.

A scripted approach with a policy would let you restrict it to network segments to avoid the error.

BrankoM
New Contributor

@davidacland tried running the script to mount our network share using the login trigger in the policy, but can't get it to work as it seems to attempt to mount the share before the Finder has loaded properly. What trigger do you use to run the policy?

davidacland
Honored Contributor II
Honored Contributor II

If its a school setup we normally use the login trigger. In some other cases we've used Self Service instead.

Are you running anything else at login?

We do enable "Perform login hook actions in background" in the computer management > check-in settings (just in case thats causing the issue).

BrankoM
New Contributor

@davidacland Thanks! Enabling "Perform login hook actions in background" did the trick!