Mounting Shared Network Drives with Concurrent Users/Fast User Switching?

[bumbletech]

I use a launch agent to connect users shared network drives at login. Things are going great with my new updates for the next school year, except that things get a bit odd when multiple users are signed in using Fast User Switching.

If user-A is logged in, and user-B logs in via Fast User Switching, user-A will have user-B's drives mounted as well. User-B's mount points will be appended with "-1" which means sidebar favorites added with mysides aren't pointing to the right location.

So, to try and be a bit more illustrative, this is what things look like when I run "mount" after this scenario:

//User-A@fileshare-01.school.net/staff$/User-A on /Volumes/User-A (smbfs, nodev, nosuid, mounted by User-A)
//User-A@fileshare-02.school.net/student_share on /Volumes/staff_share (smbfs, nodev, nosuid, mounted by User-A)
//User-A@fileshare-01.school.net/students$/User-B on /Volumes/User-B (smbfs, nodev, nosuid, mounted by User-A)
//User-A@fileshare-02.school.net/student_share on /Volumes/student_share (smbfs, nodev, nosuid, mounted by User-A)
//User-B@fileshare-01.school.net/students$/User-B on /Volumes/User-B-1 (smbfs, nodev, nosuid, mounted by User-B)
//User-B@fileshare-02.school.net/student_share on /Volumes/student_share-1 (smbfs, nodev, nosuid, mounted by User-B)

I could have my script check the mount point every time it runs and recreate the sidebar favorite with mysides, but I feel like better course of action would be to prevent other user's drives from mounting when Fast User Switching occurs. I've tried adding "su -l $user -c" before any of my commands and functions, but I get the same problem.

I'm using applescript inside of a bash script to mount any drives—something along these lines:

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

Any ideas?

[mm2270]

I believe this has been a problem in OS X/macOS for years now, like, since it was introduced even. When the OS mounts a share point, it mounts it into /Volumes/ which is accessible and readable by all accounts on the Mac, and of which, any mounted volumes there show up on the Desktop by default. So when the logged in account is switched to another one with FUS, because there is no logout occurring, which would unmount the shares, they remain mounted and the newly logged in account will see them already mounted.
Then your script is kicking in and trying to mount them again, so its doing what you told it to.

There's no great answer to this. My primary suggestion would be to not use FUS, although I'm guessing that's not the answer you'd like to hear. We moved away from it years ago because it just creates too many problems, between scripts not being able to really tell who is the logged in account, to users not being able to restart or shut down the Mac if another FUS'd account is left logged in in the background, to the issue outlined here, and some others I'm forgetting I'm sure. Its just not really a viable solution in a school or enterprise in my opinion. It just creates more issues than it solves.

To make my post a little more useful though, one possible angle you could explore would be to have your script first check to see if the share(s) is already mounted before trying to mount it again, and if so, unmount it first, then remount it as the user logging in. Its not the most elegant approach, and it could make the overall "mounting" process a little slower, but it could work to solve this issue for you. So meaning, have the shell portion of the script look for the share in /Volumes/ and if present run an unmount command for it to remove it, then mount it again but this time with the correct user share. The OS is not going to unmount already mounted shares when using Fast User Switching, so it will be up to you to do it in your script if you plan on sticking with FUS.

[rdwhitt]

We used FUS last year in our labs and ran into a similar issue; User1 logs in and plugs in an external USB drive then walks away. User2 logs in and has access to the USB. It's doubly fun when it's an encrypted drive.

One of my co-workers @jtratta created this https://github.com/jason-tratta/DriveUnMounter. It worked well for us, perhaps you can adapt it to you needs. We've decided to move away from FUS this year since it seemed to create more problems than it solved.

Good luck!

[Look]

I use similar commands but called through Casper instead and don't have that issue. It's possible I did in the past and fixed it somehow, but have forgotten (it happens :) )...
The primary difference I can see is I am calling them from Casper and I include the Username in the mount call to Finder.
Something like this:

mount volume "$protocol://${CurrentUser}@${serverName}/${shareName}"

Although I actually generate it like this...

True_Path=$(echo $Share_Path | sed 's//////'$Current_User'@/g')

Where $Share_Path was a passed variable that included everything including the protocol.