Network Share Links & Duplicate Volumes Mounted

Question

Level 1

9 points

Network Share Links & Duplicate Volumes Mounted

We've noticed a new issue on workstations we've updated to OS X Sierra recently. Specifically, using our .inetloc files to connect to a share more than once causes a duplicate share to appear in the (hidden, by default) /Volumes folder. This duplicate share will be the same name of the share that was already mounted, but with a '-#' appended, with the # beginning at 1 and incrementing each time you double-click the shortcut again. Additionally, these folders do not show the standard 'mapped share' icon, but instead show a folder icon with a restricted access tag (red dot with white horizontal line).

To assist our users in reaching network shares on our various file servers (via SMB), we provide .inetloc shortcut links to each share on each users desktop. We create these by using the 'Connect to Server..." option in the Go menu in finder. After inputting our smb path, we select the whole link and drag to the desktop to create the shortcut .inetloc file for each share.

We've been able to test this same set of shortcuts on systems running 10.9, 10.10, and 10.11 and do not see the same behavior on these OS's. We can verify visually in Finder, and also within the /Volumes directory in Terminal using 'ls -la', that the duplicate volume folders do not appear when clicking our .inetloc links multiple times.

However, on several computers running 10.12.x, we are able to reproduce this behavior.

In practice, the biggest issue we've noted with this behavior is that when users forget they have already mounted the share via the link, they will click it again because a Finder window pops up immediately on that location. But, since the /Volumes folder is hidden by default, users are unaware that a new '-#' share has been mounted. Then, when attempting to save files that were already open FROM the share before it was duplicated BACK to the share, the saving application can get confused about the path to that file. Depending on the application used, the storage system in use, and the number of duplicated shares showing up in the /Volumes folder on the workstation, this can lead to lost data, failed save/rename operations, and who knows what else...

MacBook Pro with Retina display, macOS Sierra (10.12.2)

Posted on Jan 23, 2017 12:49 PM

Reply

Answer 1

Dec 13, 2017 5:58 PM in response to mbrown.atx

Any updates? I'm having this issue as well.

Reply

Answer 2

mbrown.atx Author

Level 1

9 points

Jan 28, 2017 12:22 AM in response to mbrown.atx

My current workaround...in this form, you still need to copy/edit this script as many times as you have share links to create, and it doesn't account for all errors and edge cases that might come up, but it's a start and should provide some relief. You'll need to open Automator, create a new App (or w/e you'd like to use...), drag Utilities->'Execute AppleScript' from the Library pane into the right-hand pane, paste in this script, and edit the fields described. I'll clean it up and continue to update it as I find bugs, or until the issue is fixed.

(* This is a small script intended to safely mount a remote share via smb/afp. It first attempts to verify connectivity with a fileserver, then checks to see if the volume (or another volume of the SAME name) is already mounted to the default /Volumes folder. If not mounted, it will attempt to mount the share normally. If the drive is mounted in either case, a Finder window will open at the share location *)

-- Variable for connection state

set isConnected to true

-- Variable for fileserver IP/FQDN. Be sure to change this IP to match your fileserver IP/FQDN

set fileServer to "10.10.10.10"

-- Variable for share name. Be sure to change this to match the name of the share you want to mount to /Volumes.

set shareName to "MyShare"

-- Try to ping your fileserver, change connection state variable if this fails

try

do shell script ("ping -o -t 2" & fileServer)

on error

set isConnected to false

display dialog "Network is unreachable - Check network settings." buttons {"OK"} default button "OK"

end try

-- If successful, check /Volumes directory for share and try to mount if not found.

if (isConnected is true) then

tell application "Finder"

if not (disk shareName exists) then

try

mount volume ("SMB://" & fileServer & "/" & shareName)

on error -- If this fails due to insufficient permissions, kick out an error message indicating need for password and remove the derelict shareName folder(s) from /Volumes.

display dialog "Share access denied. Enter your password to continue."

tell application "System Events"

do shell script ("rm -rf /Volumes/" & shareName & "*") with administrator privileges

end tell

end try

end if

-- Finally, if /Volumes/shareName still exists, open it in a Finder window.

if (disk sharName exists) then

open ("/Volumes/" & shareName) as POSIX file

end if

end tell

endif

Reply

Answer 3

mbrown.atx Author

Level 1

9 points

Jan 28, 2017 12:24 AM in response to mbrown.atx

(* This is a small script intended to safely mount a remote share via smb/afp. It first attempts to verify connectivity with a fileserver, then checks to see if the volume (or another volume of the SAME name) is already mounted to the default /Volumes folder. If not mounted, it will attempt to mount the share normally. If the drive is mounted in either case, a Finder window will open at the share location *)

-- Variable for connection state

set isConnected to true

-- Variable for fileserver IP/FQDN. Be sure to change this IP to match your fileserver IP/FQDN

set fileServer to "10.10.10.10"

-- Variable for share name. Be sure to change this to match the name of the share you want to mount to /Volumes.

set shareName to "MyShare"

-- Try to ping your fileserver, change connection state variable if this fails

try

do shell script ("ping -o -t 2" & fileServer)

on error

set isConnected to false

display dialog "Network is unreachable - Check network settings." buttons {"OK"} default button "OK"

end try

-- If successful, check /Volumes directory for share and try to mount if not found.

if (isConnected is true) then

tell application "Finder"

if not (disk shareName exists) then

try

mount volume ("SMB://" & fileServer & "/" & shareName)

on error -- If this fails due to insufficient permissions, kick out an error message indicating need for password and remove the derelict shareName folder(s) from /Volumes.

display dialog "Share access denied. Enter your password to continue."

tell application "System Events"

do shell script ("rm -rf /Volumes/" & shareName & "*") with administrator privileges

end tell

end try

end if

-- Finally, if /Volumes/shareName still exists, open it in a Finder window.

if (disk sharName exists) then

open ("/Volumes/" & shareName) as POSIX file

end if

end tell

end if

Reply

Answer 4

mbrown.atx Author

Level 1

9 points

Feb 13, 2017 3:24 PM in response to mbrown.atx

Received a reply to my bug report from apple - apparently this is a duplicate report of bug report #28688741. However, access to this bug report is apparently restricted and there is no way to get further information about it.

So go now, minions - seek out your Apple buddies and point them to this bug report. Needs to get fixed asap.

Reply

Answer 5

mbrown.atx Author

Level 1

9 points

Feb 17, 2017 7:06 AM in response to mbrown.atx

I just wanted to note I've just had a support technician for our storage system provider test this out in a lab over the past couple of days and he reports this 'wildly stupid' behavior in Sierra is immediately reproducible, and that as far as he is aware there is no way to change this behavior from the storage system's configuration.

Reply

Answer 6

mbrown.atx Author

Level 1

9 points

Feb 17, 2017 8:53 AM in response to mbrown.atx

I can now confirm that the issue is still present in macOS 10.12.4 Beta (16E154a)

Reply

Answer 7

mbrown.atx Author

Level 1

9 points

Jan 24, 2017 8:25 PM in response to mbrown.atx

Can verify this is still an issue in 10.12.3.

Reply