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.
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.
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'.
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.
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.
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
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.
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.
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.
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.
automount and indeed, NFS, still have their place and use. Almost 40 years ago when I worked for Sun, we pushed the message that the network is the computer, but there was no implication that people should pretend network or the computer were unimportant and only the UX mattered. I will not enable SMB on my NAS because I have Windoze on my network and you cannot in any reasonable way really secure that as long as people are allowed access to those Windoze machines. AFP? Never worked well. I gave up fighting AFP long ago. NFS is the only one that has been around and stable long enough to be considered. But Apple doesn't want to do NFS for whatever reason that only benefits Apple. As a result, their implementation is functional, but has unnecessary unpredictability, as opposed to SMB's unpredictability which appears to be organic. User credentials for file access is good. User credentials for share access was always A Bad Idea, IMNSHO. Automount is good, and Finder not knowing about it is just an intentional shortcoming on Apple's part. Finder does show NFS mounts like any other. It is only the automount ones that aren't usually set up for browsing with Finder before mounting. Apple's paranoid whacking of auto_master has been part of Apple's updates for years and years now. I still wish there was a configuration location for automount that survived updates, but the only answer I have found is to put my maps in one or more files, and always manually add back the line(s) that includes those maps after updates. I have resigned myself to the fact that it is simply a manual step in the update process, because Apple wants it that way.