Mapping Common Share.

aburrow
Contributor

I'm using a launch daemon based script to create a mount point and use "mount -t smbfs" to mount a common DFS share.

The script works fine, however the issue I'm encountering is.

The first user to login after imaging creates the mount point the permissions on the directory are preventing subsequent users who login from mounting the common DFS share.

A number of forum's I've visited all suggest that a logout hook script to umount the share is the way to go.

I'd like to stick with local scripts as the next phase will be to modify the script to only Map drives when connected to specific wired/wireless networks.

Is there a better way to map the common DFS share?
Logout hook's I thought were deprecated. What's the preferred method to run a script at logout/shutdown?

Thanks

1 ACCEPTED SOLUTION

frozenarse
Contributor II

What OS are you using? For our Mtn Lion clients we aren't using Launch agents anymore. Instead we are using Login triggered policies that run a script that uses the command: jamf mount -server SERVERNAME -share SHARENAME -type SMB

Then we have a logoff triggered policy that runs a script that dismounts that share by using the command: diskutil unmount /Volumes/SHARENAME

View solution in original post

6 REPLIES 6

JRM
Contributor

In your current launch daemon you could add a check to see if the mount is currently mounted, if it is mounted run an unmount command prior to (re)mounting it. You could also add your check to see which network you are on here.

aburrow
Contributor

The unmount is the issue I've currently got. As the mount point is created by the first user who logs in it seems that only the root user can unmount the share. Even when I login as a user with Admin rights the unmount command doesn't work.

aburrow
Contributor

Sorry on reading my original post I should have said launch agent not daemon. The launch agent runs as the user as I'm also mapping user specific shares.

frozenarse
Contributor II

What OS are you using? For our Mtn Lion clients we aren't using Launch agents anymore. Instead we are using Login triggered policies that run a script that uses the command: jamf mount -server SERVERNAME -share SHARENAME -type SMB

Then we have a logoff triggered policy that runs a script that dismounts that share by using the command: diskutil unmount /Volumes/SHARENAME

ryan_s
New Contributor II

I am not sure what I am missing here... @frozenarse. I'm not a strong scriptor so I am trying to apply what you've mentioned and not having luck.

The share that I am attempting to mount is this: smb://companyshare/homedirectory/<currentlyloggedinuser>

Based on what I've seen above and from other posts, this is my best guess as to how to apply this to my user's folder:

jamf mount -server companyshare -share homedirectory/rseys -type SMB

"rseys" is myself so I am using this to test in Terminal, but obviously this will be a general script for all users; later I believe I would replace this with something like:

#Capture the current user
USER=`ls -l /dev/console | cut -d " " -f 4`

jamf mount -server companyshare -share homedirectory/USER -type SMB

....I am sure I am missing something obvious

frozenarse
Contributor II

@rseys -
I'm not a 'script guru' either :)

I'm guessing the issue is that the folder you want to mount is nested under the homedirectory share.

We have several shares that are simply "Server/Share" format. For those we use the jamf mount syntax you see above.

We also have one share that is formatted "Server/Share/UserType/FirstLetter/Username". Hopefully that makes sense. For that share I do things a bit differently.

All this is part of a script ran at login.
We pull that path value from Active Directory and assign it to a variable i'll call $userSharePath.

I create a folder with their username under /volumes that i'll mount to: sudo -u $3 /Volumes/$3
Then I mount the share using this: sudo -u $3 mount_smbfs $userSharePath /Volumes/$3

And as part of the logoff script it unmounts that share like the other ones.

Again note that I'm not a scripting pro so perhaps that is not the best way to do things... But it has been working for us.