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.

I should add some more/better usage.

┌──(dap  hubris)-[~]
└─% smb-mount --help 
Usage: smb-mount [OPTIONS] COMMAND [ARGS]...

Options:
  --help  Show this message and exit.

Commands:
  auth       Establish the authentication.
  auth-pass  Establish authentication, password from `pass`.
  check      Verify authentication.
  mount      Mount volume.
  unmount    Unmount volume.

The auth-pass may only be useful if you use pass and adopt the same scheme as I do.
Alternately, there is the pass sub-command.

┌──(dap  hubris)-[~]
└─% smb-mount auth --help
Usage: smb-mount auth [OPTIONS]

  Establish the authentication. I keep the user passwords in `pass -c
  Auth/SMB/${server}/${user}`. However, this requires interaction with the
  YubiKey for each access. Accordingly, I cache them in the system keychain,
  presumably protected by the keychain unlock password (ie: login password).

Options:
  --server TEXT    SMB server address
  --user TEXT      SMB user name
  --password TEXT  SMB password
  --help           Show this message and exit.

To add a new key-chain entry:

┌──(dap  hubris)-[~]
└─% smb-mount auth       
Enter SMB server address [nas.local]: my-local-nas.local
Enter SMB username [dap]: some-other-user
Password: 
Repeat for confirmation: 
┌──(dap  hubris)-[~]
└─%

Subsequently, you have to edit the python script and add in the desired mounts, using my-local-nas.local in the server column and some-other-user in the user column of the table.

It would be possible to adjust things so that /nas/${user} was owned by ${user} and each user had their own copy of the smb-mount script and then /nas/${user}/home would possibly be only accessible to that user (controled by the permissions on /nas/${user}/..

rudelm/autofs.md