osascript network drive mount in 10.12

amprice
New Contributor

Has anyone tried running something like this via a script on 10.12
Server=Correct_Server_Address
Mount_Point=TempStore
RESULT=osascript -e "try" -e "mount volume "smb://$Server/$Mount_Point/"" -e "end try"
The mount point mounts but a folder /Volumes/TempStore is created with 111 permissions and the actual mount point ends up being /Volumes/TempStore-1
The script runs without issue on 10.11.X.
Before the script runs /Volumes does not have a TempStore entry.
I guess it's either an undocumented new feature or a bug.

17 REPLIES 17

Kennedy
New Contributor II

My map drive scripts don't work in Sierra, as I force them to mount to a folder in /Volumes, but with Sierra I don't have permissions to create the folders first. A SIP thing perhaps?

Started mounting them to /tmp and all good.

al_platt
Contributor II

Not SIP, but /Volumes is no longer world writable, you need to run as root or sudo

https://derflounder.wordpress.com/2016/09/21/macos-sierras-volumes-folder-is-no-longer-world-writable/

Look
Valued Contributor III

Running as a script in a policy from Casper here and it works on 10.12

osascript<<END
tell application "Finder"
mount volume "$True_Path"
end tell
END

$True_Path is in the form protocol://username@server/share they mount into Volumes as you would expect.

mrheathjones
New Contributor III

I actually mount network shares via applescript using "mount volume" command which i have no issues with.

russeller
Contributor III

@amprice if you didn't want to run a Casper Policy as root at login, you could also create a Launch Agent that will run:

<key>LimitLoadToSessionType</key>
<string>Aqua</string>

and that will run as root when the user logs in. Those are stored in Macintosh HD > Library > LaunchAgents. This is a pretty handy site for answering launchd questions: launchd.info

amprice
New Contributor

Thanks for the responses.

If I copy and paste the three lines above (with the correct server address) in to terminal the share mounts Ok but the problem is that before the share is mounted a folder TempStore is created in /Volumes with posix permissions of 111, the share is then mounted as TempStore-1.

I've tried the suggestion by @Look but the same thing happens, a folder /Volumes/TempStore is created and then the Mount point is created called TempStore-1.

bentoms
Release Candidate Programs Tester

@amprice Are you running the script as the user or via the JAMF binary (therefore root).

10.12 made some changes, which means that users can create volumes in / but not root etc.

rvegab00
New Contributor

Filling in for my empty Mac Tech position here so go easy on me. I think I'm having similiar issue to @amprice. I can run the map script successfully from terminal but if i put it as a policy in casper it doesn't work. Is that because it is running as a JAMF binary like @bentoms stated? How would i work around this to get the script to run on login for users if I can't use it in a policy?
I place the script in self service and it will run there as well. But at log in, even with a delay of 1 minute it doesn't run.
Thanks in advance.

nkalister
Valued Contributor

Just had this reported in my environment.
@amprice I'm seeing the exact same thing as you- as soon as the OS displays the authentication window, it creates an inaccessible directory under /Volumes. then, after authenticating, the share is mounted, but in another directory with incrementing numbers appended.
I found that switching from

osascript -e 'mount volume "smb://foo/bar"'

to

osascript -e 'open location "smb://foo/bar"'

avoided the problem.
I'll be filing a radar on that one, looks to be pretty clearly a bug with the mount volume command on Sierra.

nkalister
Valued Contributor

coupe of other things I noticed today on this . . .

  • open location will open a finder window displaying the share contents after it mounts. mount volume does not. this was actually a problem for our developers
  • specifying a username and password or just the username with mount volume ALSO avoided creating the inaccessible directory

blinvisible
Contributor

I ran into this problem today, deploying Sierra 10.12.6 for the first time onto some lab iMacs. I can confirm that changing the mount call from "smb://${Server}/${Mount_Point}" to "smb://${USER}@${Server}/${Mount_Point}" is a viable workaround. Thanks @nkalister for figuring that out!

GabeShack
Valued Contributor III

@nkalister When I try this approach it always prompts the user to click a connect button for each share it mounts. Do you know a line of script that would essentially hit the return key? I would like to use this method as it works much better than the old Share Mount Script in the JAMF resources. Just need to get that connect button off the screen...lol.
Gabe Shackney
Princeton Public Schools

Gabe Shackney
Princeton Public Schools

nkalister
Valued Contributor

that's a new 'feature' in Sierra:
https://support.apple.com/en-us/HT207112

instructions at that link for how to turn it off with defaults.

GabeShack
Valued Contributor III

Interesting. Thanks!
Gabe Shackney
Princeton Public Schools

Gabe Shackney
Princeton Public Schools

gskibum
Contributor III

I ran into this today. But I had a bit of a wrinkle.

I was trying to mount multiple shares. Changing from "mount volume" to "open location" would work for the first share in the script but the rest would be ignored. So I only changed the first share in the script to "open location" and kept the rest at "mount volume" and that solved that problem for me.

dstranathan
Valued Contributor II

Related question:

Is it possible to tell AppleScript to mount SMB volumes at a custom mount point other than the default /Volumes?

I know this can be achieved with Bash (via the /sbin/mount command), but can AppleScript do this?

I can't find the appropriate AppleScript syntax to accomplish this. Please advise if you know a way to utilize custom mount points with AppleScript...

blinvisible
Contributor

@dstranathan Other than using a do shell script command inside the AppleScript to call one of the /sbin/mount* binaries, not that I'm aware of.