4

Apple have confirmed to me (https://openradar.appspot.com/radar?id=4948585099558912) that with macOS 10.12, permissions to create a folder inside /Volumes require root access.

Using the mount command requires that the mount point exists first, so you're going to have to sudo to create that folder for the mount point.

I develop an app which presents a list of network shares to a the user, and allows them to selectively mount them. I handle this by firing off a command process in the background which uses mkdir and mount to mount the network drive. Of course this now fails, as it doesn't have permission to create the mount point.

One option I am looking into is modifying sudoers to give all users permission to use mkdir.

Can anyone else think of a way to programmatically mount a network drive via Terminal without password prompts, or messing with sudo?

  • It looks like the same prompts might be occurring when using AppleScript too: apple.stackexchange.com/questions/245819/… – mattdwen Aug 16 '16 at 22:49
  • As this affects more than the current user it seems that Apple have now got the correct permissions you need an admin account to do this = if you don't it is a security hole and should not be possible – Mark Aug 16 '16 at 22:51
3

As I answered at macOS Sierra: AppleScript mount volume keeps asking for login, I think the way to do it now is to create the mount point somewhere the user does have write access to, such as the user's home directory:

mkdir -p ~/mnt
mount_smbfs "//my_username:my_password@my_hostname/share" ~/mnt
  • If it is app-specific, I'd recommend ~/Library/Application Support/AppName/mnt or something similar. – Kent Sep 23 '16 at 4:46
  • Marked as accepted, as it does get around the fundamental problem. I'm stuck with an issue though in that the share name on the server isn't correct, and creating /Volumes/WhatEverNameIWant was a hack to make the name on the desktop better for the user. – mattdwen Sep 25 '16 at 23:29
  • Glad to see this workaround, but I don't see how this is more secure than the previously available mount capability. It's like Apple is locking the henhouse door while the henhouse window is wide open. – Br.Bill Dec 16 '16 at 23:35
3

Here's good news around Sierra the mounting challenges: The original Unix automountd works again as it is supposed to work.

Do as root this: Add into your /etc/auto_master for example this line to a static mount map. I called it "Media", but you can do anything you like.

/etc/auto_master:
/Volumes/Media   auto_media

then make a file /etc/auto_media with the entries of your mount-points, these are two in example for picture and music. My Synology NAS fully supports apple files system, but you can do this on any file server and pick other file system. See man auto_master.

/etc/auto_master:
Bilder  afp://yournasuser:naspw@Media/Bilder
Musik   afp://yournasuser:naspw@Media/Musik

Also make the mountpoint folder manually mkdir /Volume/Media and reload all with automount -vc If you now click as a USER in Finder to the /Volumes/Media folder, Finder will automatically show the subfolders Bilder and Musik. If you click into one of those, automountd will automatically mount the volumes AS the USER that was requesting it and NOT as root. This is the key to the solution!!! Check out the mount status, it will show the following:

Type mount
...
map auto_media on /Volumes/Media (autofs, automounted, nobrowse)
//yournasuser@Media/Bilder on /Volumes/Media/Bilder (..automounted,.. mounted by yourMacUser)

Please note the "mounted by Username" at the end of the last line above.

I realized that the mkdir /Volumes/Media is persistent on one Mac, but all folders in /Volumes are wiped out on another Mac. In this case you have to execute after a the reboot a script that creates the folder and reloads the automounter. Something like this:

#!/bin/sh
mkdir /Volumes/Media
automount -vc

I hope this works for everybody.

2

For those that want a really sophisticated solution, I remembered from my Unix basics 20 years ago, how executable automount maps work. Here, the mapfile is not a static map, but a executable script, which outputs basically the parameters for the mount points. The good thing about this, is that you can fix other things in these scripts, like waking up a sleepy NAS, or adding additional links to the mounted devices. Here is how it goes

/etc/auto_master
/Volumes/Media  auto_exec

create a script in /etc and make it executable (chmod +x /etc/auto_exec) by the automount daemon. Here is mine:

#!/bin/bash
# By www.stefan-ried.de 11/2016
# Open Source
#
# Name or IP of you NAS
server="yourNASServername"
# List of share you want to mount
shares="Bilder Musik Tina GemeinsameDateien"
# NAS use name
user="yourNasUser"
# NAS PW
userpw="yourNasPW"
# local logfile 
logfile="/tmp/automounter.log"
#
# automountd calls this without an argument to show the folders 
# or with a specific folder name as argument to retrieve the mount parameter for it
# 
# Make sure this file is in /etc and executable (chmod +a), call it auto_exec
# Add to /etc/auto_master for example this line
# /Volumes/Media    auto_exec
# 
# automount will then execute this file when the folder is accessed
# Reload the changes to your auto_master and auto_exec with automount -vc
# use tail -f /tmp/automounter.log to see whats going on, when you ls into /Volume/..
# have fun
#
if [ $# = 0 ]; then # List keys
    echo `date` "Showing Folders/Keys" $1   >> $logfile
    for mountpoint in $shares; do
        echo -e "$mountpoint"   >> $logfile
        echo -e "$mountpoint"
        # create symbolic links for legacy mount points under /Volumes
        # you can comment this out, if you don't need it
        if [ ! -L /Volumes/$mountpoint ]; then
            echo -e "Create Sym Link Volumes/$mountpoint"       >> $logfile
            ln -s /Volumes/$server/$mountpoint /Volumes/$mountpoint
        fi
    done
# fire a WOL to the NAS
    /usr/local/bin/wolcmd 0011321906C8 10.0.0.2 255.255.255.0 4343 >> $logfile
#   
else
    echo `date` "Requesting Mountpoint" $1  >> $logfile
    for mountpoint in $shares; do
        if [ $1 = $mountpoint ]; then
            echo -e "afp://$user:$userpw@Media/$mountpoint \\"      >> $logfile
            echo -e "afp://$user:$userpw@Media/$mountpoint \\"
        fi
    done
fi

So, what does the script do in addition to the statis solution, I've posted above?

  1. You have all parameters as variables in the beginning. Please fill it out.

  2. It adds via symbolic links the legacy mount points. This is very handy, as before for example my music folder was mounted on /Volumes/Musik, but it it appears under /Volumes/Media/Musik. The link makes is also visible under /Volumes/Musik again.

  3. It shoots and wake-on-lan to my NAS. Download the wolcmd here for example: https://www.depicus.com/downloads/wolcmdmac.zip Thanks to the author, for sharing this freely. You need to put it at any location consistent the script. I put it at /usr/local/bin

  4. It logs all actions under a logfile. You can monitor it freely by running for example "tail -f /tmp/automounter.log" in a terminal window. Only these mounts are executed where the corresponding folder is touched.

1

In case your /Volumes/mountpoint folder disappears after reboot, and you don't find on the net quickly enough how to run something at boot or login time. Here what I did:

Put into the user's launch agent folder: /Users/YourMacUser/Library/LaunchAgents the following file

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
 <dict>
  <key>Label</key>
  <string>de.stefan-ried.mounter</string>
  <key>Program</key>
  <string>/Users/YouMacUserFolder/Library/LaunchAgents/mount-startup.sh</string>
  <key>RunAtLoad</key>
  <true/>
 </dict>
</plist>

The my mount-startup.sh script is this:

#!/bin/sh
# By www.stefan-ried.de 11/2016
# Open Source
#
# Name or IP of you NAS
server="Media"
# List of share you want to mount
shares="Bilder Musik Tina GemeinsameDateien"
# NAS use name
user="YourNasUser"
# Mac PW
userpw="your Mac user pw"
# local logfile 
logfile="/tmp/automounter.log"
#
# automountd calls this without an argument to show the folders 
# or with a specific folder name as argument to retrieve the mount parameter for it
# 
# Make sure this file is in /etc and executable (chmod +a), call it auto_exec
# Add to /etc/auto_master for example this line
# /Volumes/Media    auto_exec
# 
# automount will then execute this file when the folder is accessed
# Reload the changes to your auto_master and auto_exec with automount -vc
# use tail -f /tmp/automounter.log to see whats going on, when you ls into /Volume/..
# have fun
#
echo `date` "Startup" $1    >> $logfile
if [ ! -e /Volumes/$server ]; then
        echo -e "Create Volumes/$server"        >> $logfile
        echo $userpw |sudo -S mkdir /Volumes/$server 
        echo $userpw |sudo -S automount -cv >> $logfile
fi
# fire a WOL to the NAS
echo $userpw |sudo -S /usr/local/bin/wolcmd 0011321906C8 10.0.0.2 255.255.255.0 4343 >> $logfile
# 
for mountpoint in $shares; do
    # create symbolic links for legacy mount points under /Volumes
    # you can comment this out, if you don't need it
    if [ ! -L /Volumes/$mountpoint ]; then
        echo -e "Create Sym Link Volumes/$mountpoint"       >> $logfile
        echo $userpw  | sudo -S ln -s /Volumes/$server/$mountpoint /Volumes/$mountpoint
    fi
done

That's what the script do at user-login time.

  1. It check if the mount point in /Volumes is there, creates it and reloads the automounter. this was the main task of the script. The rest is luxury.

  2. It wakes up the NAS. The NAS is also woken up by the auto_exec script if a automount folder is accessed. But NAS drives takes some time to boot, and maybe the MacUser does something else after login. Once they click on the automount folder, the NAS is running already then. Double wol doesn't hurt.

  3. Also create the legacy mount links under "Volumes" again. Double doesn't hurt.

Please note, that this agent script is designed to run under USER privileges. Usually the sudo command asks for a password. I've surpressed this by the "echo $passpw | sudo -S ..." hack. Obviously, storing a password explicitly in a script file is not professional at all and just ok for my home usage. To do this professionally, you should load this launch script into the root /Library and not into the user Library. The you can just delete all the "echo $passpw | sudo -S " part before the actual command.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .