Use autofs on Mac OS X to mount network shares automatically during access

autofs.md

Autofs on Mac OS X

With autofs you can easily mount network volumes upon first access to the folder where you want to mount the volume. Autofs is available for many OS and is preinstalled on Mac OS X so I show you how I mounted my iTunes library folder using this method.

Prepare autofs to use a separate configuration file

autofs needs to be configured so that it knows where to gets its configuration. Edit the file /etc/auto_master and add the last line:

#
# Automounter master map
#
+auto_master		# Use directory service
/net			-hosts		-nobrowse,hidefromfinder,nosuid
/home			auto_home	-nobrowse,hidefromfinder
/Network/Servers	-fstab
/-			-static
/-          auto_smb    -nosuid,noowners
#/-			auto_afp	-nobrowse,nosuid

This will tell autofs to look for a file in the '/etc' folder with name 'auto_smb'. In this case I want to create a configuration for automatically mount SMB volumes. You are free to choose a different name and can also use afp/cifs/nfs etc.

Be aware that macOS updates can overwrite this file! Make sure you'll check the content of this file after you've updated. I've encountered this behaviour with the latest macOS Catalina 10.15.7 supplemental update.

Content of the configuration file

Normally Mac OS X tries to mount network shares into the '/Volumes' folder. This is the default folder for all mounted shares on a mac. However, if you try to directly mount into this folder, autofs will fail. You just add a '/../' in front of your desired mount path and Mac OS X will even accept the Volumes folder. However, some Mac OS Version doesn't like this so I switched over to use my own folder named '/mount'.

If you want to configure AFP, do it like this:

So add this line to /etc/auto_afp:

/../Volumes/music	-fstype=afp,rw afp://ip-address:/music

Mac OS X is clever enough to lookup the username and password from the Mac keychain so there's no need to add the username and password in clear text to the configuration file.

If you want to configure SMB, do it like this:

Add this line to /etc/auto_smb:

/mount/music    -fstype=smbfs,soft,noowners,nosuid,rw ://username:password@ip-address:/music

Unfortunately you will need to add the user and password to the resource :( You can try to lock it down further using the Mac OS permissions but that won't help when the attackers user got admin rights as well.

If you're using macOS Catalina 10.15 and macOS Big Sur 11

You’ll just have to prepend your existing automount paths with /System/Volumes/Data. This is because macOS creates a second APFS volume for your user data, whereby the existing system installation is moved to a read-only APFS volume.

This is the version of /etc/auto_smb in Catalina:

/System/Volumes/Data/mount/music    -fstype=smbfs,soft,noowners,nosuid,rw ://username:password@ip-address:/music

Modern way using synthetic.conf

Thanks to rjc I now know about synthetic.conf. From the man page:

synthetic.conf describes virtual symbolic links and empty directories to be
created at the root mount point.  Because the root mount point is read-only
as of macOS 10.15, physical files may not be created at this location.  All
writeable paths must reside on the data volume, which is mounted at
/System/Volumes/Data.

synthetic.conf provides a mechanism for some limited, user-controlled file-
creation at /.  The synthetic entities described in this file are
synthesized by the kernel during early system boot.  They are not
physically present on the disk, but when the system is booted, they behave
as if they were within certain parameters.

which sounds exactly what we want. Create a new file /etc/synthetic.conf. If it does not exist, create the file with this content:

# create a symbolic link named "music" at / which points to
# "System/Volumes/Data/mount/music", a writeable location at the root of the data volume
music   System/Volumes/Data/mount/music

The first column describes the symbolic link at /. The next column is separated with a tab and describes the location under / which should be linked to the first column. You can also leave the second column empty. This would create an empty folder in which we could automount again. If you want the minumum amount of changes, use example from above. After a reboot the folder should be available at the root of your macOS installation.

Restoring autofs after macOS updates

The recent macOS updates seem to overwrite the /etc/auto_master file. You can try to set the file to read-only using the extended attributes of macOS. For more details see this blog post. Please add the entry for your autofs file again to the auto_master file and save the file. We'll try to set the auto_master file to read-only, in hope it won't be overwritten again.

~ ❯ ls -lO /etc/auto_master                                         at 20:55:44
-rw-r--r--  1 root  wheel  - 226 May  6 20:49 /etc/auto_master
~ ❯ sudo chflags schg /etc/auto_master                        ✘ INT at 21:01:04
~ ❯ ls -lO /etc/auto_master                                         at 21:01:10
-rw-r--r--  1 root  wheel  schg 226 May  6 20:49 /etc/auto_master

The file is now write protected. You can try to edit it again with sudo and it will be read only. Its the same as when you set the file write protected in the finder.

if you use

sudo chflags noschg /etc/auto_master 

it will be writeable again.

Access the folder and see autofs in action

You now need to restart the autofs service with the command 'sudo automount -cv'. If you now type mount, you'll see a listing of currently mounted volumes. Your desired volume shouldn't be mounted, so unmount it with 'sudo umount /Volumes/volumename' or 'sudo umount /mount/music' before we continue.

You can now switch to '/Volumes/music' or '/mount/music' folder or let it list on the terminal. If you're using macOS Catalina you can open /System/Volumes/Data/mount/music. Once you do that autofs will automatically try to mount the desired volume into this folder.

See an example and explanation in action

Visit my blog post where I explain this gist a little bit more in detail. A complete list of blog posts with autofs can be found here.

[...] will the share be available automatically?

The whole point of autofs is to only mount required filesystem upon request, i.e. access so, if you aren't connected to the VPN, don't try to access the NFS share. Access it once you connect to the VPN and either, let it time out and autofs deal with it, i.e. unmount it automatically after a set time, or you can do so manually - both after you aren't accessing the share any more, and before you disconnect from the VPN.

Can anyone here confirm that autofs mounts using SMB on newer macOS release is just broken? I have had no luck getting it to work. I have followed the instructions cited here closely and have used in many times in the past but its been a while on macOS so I don't think that its an issue with my configuration.

To clarify, the only way that I can mount SMB shares is if I embed the credentials in the direct map config file which is not practical in a multi-user environment.

SMB client mounting in a multi user environment does not work, because of how SMB works. For SMB, you need to make sure you have compatible credentials negotiation protocol and each user needs to do a user mount in their user directory. I recommend using either NFSv4 or if that is not possible, using a 3rd party mounting utility to mount volumes at login by user.

If you use a single mount point, the first user to mount the share is the owner and nobody can use it unless you use a shared account. The typical mounting solution for SMB works best for unsecured networks where all users access shares based on a share password instead of a user password.

Well currently, we are using SMB network mounts as login items, which has worked fine, and I don't think that is much different from what you are describing. I haven't tested NFSv4 before but I do know that it has had stability issues in the past, so I am reluctant to use it. And quote honestly, I don't have the experience to implement it.

I have used autofs in the past extensively on Linux, and a few times on macOS, and I am pretty sure that I have used it together with SMB.

On a different forum, I found another admin who claims he has autofs and SMB without embedding credentials into the map file. Its just not working for me.

Okay, so then you are using it in the one way I said it works. You mount each use using their own credentials to a different mount point (inside the user folder). That is the only way it can work with autofs as well. To not use hard-coded credentials, you have to use Kerberos authentication, or lan manager authentication, both of which can only happen after the user provides their credentials at login, and through the authentication wrapper mechanism. This is a complex solution and possible, but it’s easier to use 3rd party software to manage the mounts in this case, so that it just works. I managed to achieve what you want but it was fickle so I switched to amounting took that each user runs at login to achieve this.

Thats what is so puzzling, it's a fully kerberized environment ( I forgot to mention that ), so it should work fine.

What is the third-party software that you are referring to? I have not found anything out there that would replicate the features of autofs. I need the mounts to dismount/disappear once they become idle, and based on what I know, autofs is the only thing that can do it gracefully.