Bash Scripting: Mount

Hey all. Hope you’ve all been enjoying the shockingly great weather we’ve had over the last few weeks. Or how about those Olympics? Team GB didn’t do too badly overall!

Ok, down to work. I apologise once again for the lack of posts. Working for our Mac Consultancy department that specialises in education installs, you can imagine that the summer break has been super-busy for everyone involved.

Without further ado, I’ve decided to take a look at, if not one of the most common commands, one of the most useful, the “mount” command.

“mount”…that wouldn’t have something to do with mounting shares by any chance?

Yes and no. The mount command can be used to mount other items, but this week I’ll be looking at its ability to mount network shares, specifically AFP (Apple File [sharing] Protocol) and SMB (Server Message Block).

This command is adapted to ‘mount_afp’ and ‘mount_smbfs’ for each protocol, so picking the correct version really will make your life easier. A second key point is that before you jump in and mount your volume, the Mac OS requires that a directory (or folder) is specified to mount the volume ‘on to’.

Essentially this dictates that each ‘mount’ command is preceded by a ‘mkdir’ (‘make directory’) command. For example, to mount the AFP share “MNH” on the server “mac.test.internal” you’d be looking at something like the following:

mkdir "/Volumes/MNH"
mount_afp "afp://mac.test.internal/MNH" /Volumes/MNH

So, what can I do with ‘mount_afp’?

So you’ve got the basic structure on how to mount an AFP volume using the command line, lets check out some options.

A lot of the authentication options for mount_afp are the same as for ssh (and many other terminal commands). So what if you want to mount the volume with a different set of credentials? Simply add [username]:[password] to the url. Example below (username is bob and password is 1234):

mkdir "/Volumes/MNH"
mount_afp "afp://bob:1234@mac.test.internal/MNH" /Volumes/MNH

Not too bad, not too bad, however it is a little insecure, what with having the username and password in the command. That’s not something you’d like to have laying around.
How about a compromise? Lets leave the username in there but ask for the password instead.

Example:

mkdir "/Volumes/MNH"
mount_afp –i "afp://bob@mac.test.internal/MNH" /Volumes/MNH

The Terminal window will request a password (for the network user, not the local user) which will be used to authenticate the user and, if authorised, to mount the requested share.

So by adding the ‘-i’ and removing the password we have secured our script a little more. But lets say you have a typical enterprise environment. I’m talking Kerberos (or SSO – Single Sign On). I’m talking multiple users on each machine. This script just can’t take those variables easily and securely.

Aha, I know some of you have spotted it already, but we can take advantage of Kerberos/SSO that is in place. Kerberos is one of those easier to configure but difficult to troubleshoot technologies to help users authenticate and authorise themselves, all without sending a single password across a (possible compromised or watched) network.

Now don’t worry, I’m not going to delve into the infinite realms of Kerberos in this post (maybe at a later date) I will get back on topic.
As you may have guessed, it’s a case of replacing the ‘authentication’ method area of the url with “;AUTH=Client%20Krb%20v2”.

For example:

mkdir "/Volumes/MNH"
mount_afp –i "afp://;AUTH=Client%20Krb%20v2@mac.test.internal/MNH" /Volumes/MNH

That’ll work for any user that logs in and has a Kerberos ticket!

What about smb?

Well mount_smbfs is a little simpler. The first option, using the username and password ‘baked’ into the script works as expected. Example:

mkdir "/Volumes/MNH"
mount_smbfs "smb://bob:1234@mac.test.internal/MNH" /Volumes/MNH

The second option, removing the password, works just as well but without the ‘-i’.

Example:

mkdir "/Volumes/MNH"
mount_smbfs "smb://bob@mac.test.internal/MNH" /Volumes/MNH

And finally, what about Kerberos/SSO? It’s even easier, just remove all authentication that is ‘baked’ in. Example:

mkdir "/Volumes/MNH"
mount_smbfs "smb://mac.test.internal/MNH" /Volumes/MNH

Summary

There you have it, that’s how to mount network shares via the command line. What’s the point, I hear you ask! Well, next time I’ll show you the power of rsync which, when used with something like ‘mount’ can provided massive opportunities!

Any hints, tips or opinions? Let us know in the comments below and I’ll try to respond to as many as I can.

12 Replies to "Bash Scripting: Mount"

  • sebus

    Anybody having an idea how to mount afp share (Novell OES NSS volume presented via afp) when user authenticates against AD, without need for the second password prompt?

    Users are synced from eDir to AD (so both username & password is the same)

    I can do mount_afp & that fails, mount_afp -i requires password

    sebus

  • Hi Sebus,

    have you tried using mount_afp with the “;AUTH=Client%20Krb%20v2” entry to use kerberos authentication?

    I’m guessing the user session has a TGT without an issue too?

    Darren

  • Lee Kerwin

    Hello Darren,

    I understand this is an old thread, but was wondering if you could please answer the following questions for me?.

    1. Connecting to an SMB Windows share or OS X server (10.7 and above) does not work with disk quotas, it only seems to see the full volume, although AFP from OS X seems to work. Does quotas work with SMB on OS X server above 10.7?

    2. I’m unable to connect via Kerberos using the following mount command error -5002, but seems to work with SMB without a problem.

    mkdir /Volumes/share
    mount_afp “afp://;AUTH=Client%20Krb%20v2@server/share” /Volumes/share

    I have tried numerous different ways, pushing with profiles, LauchAgents, login items, login hooks but nothing seems to work.

    Any help would be greatly appreciated.

    Regards.

    • Darren Wallace

      Hi Lee,

      Thanks for your comment.
      1) I vaguely remember this being an issue in the past but I’m afraid I can’t remember the fix / workaround. However, on a side note, I’d suggest getting those devices onto a newer OS as this can not only potentially resolve the issue, but include huge numbers of Bug and Security fixes.

      2) I’d suggest testing from the GUI. If this also doesn’t work, then it is likely an issue with Kerberos. Maybe the client isn’t getting a Kerberos TGT ticket, maybe the server isn’t using kerberos for AFP. Maybe it’s also a bug?

      Hope these give you some pointers for next steps!

      Darren

  • Lee Kerwin

    Hi Darren,

    Many thanks for your quick reply. Our clients are currently running 10.9 – 10.11, we have one 10.6 server that seems to work with disk quotas for both AFP and SMB”, we also have 10.10 servers but quotas only work for AFP and not SMB. This is when connecting to any share from the clients below.

    From clients 10.9 – 10.11 we cannot get to mount AFP with Kerberos using the switch “;AUTH=Client%20Krb%20v2”, this works for SMB but we cannot use this method to connect due to quotas not working with SMB.

    We seem to have a valid Kerberos ticket, as we can successfully connect via the GUI without the need to authenticate.

    Any help or tips would be much appreciated.

    Regards.

    • Darren Wallace

      Hi Lee,

      Thanks for providing more information.

      You may be able to switch out your below lines:
      `mkdir /Volumes/share
      mount_afp “afp://;AUTH=Client%20Krb%20v2@server/share” /Volumes/share`

      With this (re-type rather than copy and paste):
      mount_script=`/usr/bin/osascript > /dev/null << EOT
      mount volume "$protocol://${serverName}/${shareName}"
      EOT`

      Swap out "$protocol" for the protocol (in your case afp), swap out "${serverName}" for the server address and "${shareName}" for the name of the share. This method seems a little better as it will use a more GUI-style mounting method (with the GUI reported as working fine with your testing) and also doesn't rely on the successful creation of the directory to mount on.

      Hope that helps

      Darren

  • Lee Kerwin

    Hello Darren,

    I had recently tested with AppleScript commands using a login hook, but we had issues mounting the share, due to the hook running as root. We could see the share from the terminal, but not on the desktop. I also tried launching the script as a user “su $1” but the login window just locks with a spinning progress bar.

    Looking remotely at the precesses, the osascript seemed to be stuck for some reason. If I kill the process the login finishes and we are presented with a desktop.

    As you say, this method would probably fix our problems, but we was just having difficulty getting the script to launch to as a user. Unfortunately we don’t seem to be having much luck.

    Much appreciated for your time and help.

    Regards.

  • Lee Kerwin

    Hi Darren,

    Currently our Mac network storage is separate from the PCs, as a result we are unable to use the home path on the AD account as the script queries AD, then mounts the storage based on the OU.

    We would like to use SMB to share the same storage as our PCs, but unable to do so because the lack of disk quota support. We also use the Casper suite for managing our Macs, and we’ve tested the scripts using a LaunchAgent.

    This seems to work for us, but our script also removes and redirects the local home folders to the network, this can be a little slow sometimes. If the desktop is available to the user, they can start saving files before the redirect occurs, then work is lost. The hook method would be better, as this script would have finished before the desktop is available to the user.

    Thanks again and much appreciated, we will certainly try the script and see what results we get.

    Regards.

  • Ben

    Hey Darren,

    Hopefully you’re still monitoring this and will allow me to pick your brain a bit. I’m trying to set up smart-card and kerberos usage on a Sierra test system, and we want to pull away from AD credentials for everything. I am trying to recreate a login script that we use to mount shares, and wanted to get SMB shares mounted utilizing kerberos credentials. I ran it on our shares, and got a usage response.

    usage: mount_smbfs [-N] [-o options] [-d mode] [-f mode] [-h] [-s] [-v]
    //[domain;][user[:password]@]server[/share] path

    Any on what I did wrong? I copied your code lines, and replaced your share information with mine.

    • Darren Wallace

      Hi Ben,

      Thanks for your comment. To my knowledge, the usage of mount_smbfs hasn’t changed in Sierra, which would suggest the context you’re using may have an issue. Without seeing what you’re trying (which you may not wish to post publicly) it’ll be hard to see what’s not working.

      To be honest, we have switched to using a more AppleScript style mounting which works really well. You can find the code and details on its usage here.

      Good Luck!

      Darren

Leave a Reply

Your email address will not be published. Required fields are marked *