Auto mount a network drive on a Mac: ready at every login

Mounting a share by hand takes four clicks. Doing it every morning, and again after every sleep on a different network, is what turns four clicks into a search for automation. macOS has four separate mechanisms for this, they behave differently, and the one that gets recommended most often is also the one that fails most often on a laptop.

Picking between them starts with being precise about what "automatic" means here, because the four answers solve four different sentences.

What is actually being asked for

There are three distinct requests hiding behind the same phrase.

The first is mounted at login. The share should be present when the desktop appears, and nothing should have to be clicked. This is the request most people have, and it assumes the network is up and the server is reachable at that moment.

The second is mounted whenever possible. The laptop moves between an office, a home network and a coffee shop, and the share should reappear whenever the server comes back into reach. That is a repeated attempt rather than a single one, and no login item can do it.

The third is mounted when something touches it. Nothing is mounted until a path is used, at which point the mount happens invisibly. This is how automounted home directories have always worked, and it is the only one of the three that costs nothing when the share is not in use.

Naming which of the three is wanted eliminates two of the four mechanisms immediately.

Login Items is the supported answer

The route Apple documents needs no scripting. Mount the share once through Go then Connect to Server, then add the mounted volume to the login items list.

Apple's description of Login Items and Extensions settings is explicit about what belongs there: the apps, documents, and server connections that open automatically at login. The Kind column in that list distinguishes app, document, folder and volume, which confirms that a mounted volume is a first-class entry rather than a trick. The settings live in System Settings, General in the sidebar, then Login Items and Extensions.

Two supporting details make this behave better than it otherwise would.

Credentials belong in the keychain, which happens on its own if the box to remember the password was selected the first time the share was mounted. Without that, the login item produces an authentication dialog at every login, which is worse than the four clicks it replaced.

The Finder has to be willing to show the result. In the Finder, choose Finder then Settings, and confirm that the Connected servers checkbox is selected under General and again under Sidebar. Apple lists this first among the checks for a Mac that cannot connect to another computer, and with both cleared, a mount that worked leaves no visible trace anywhere.

One warning sign is built into the list. Apple notes that an indicator appears next to an item that will not open automatically because it was moved or deleted. A login item pointing at a volume that has been renamed on the server shows up there rather than failing silently.

Where the login item quietly fails

The login item is one attempt, made at one moment, and that moment is early.

On a desktop machine on Ethernet, the network is up before the login window is dismissed and the attempt succeeds. On a laptop on Wi-Fi, the association and the DHCP lease may not have completed, and the attempt fails. Nothing retries it. The share is simply absent, and the usual conclusion is that the login item "did not work", when in fact it ran and lost a race.

The second failure mode is more obvious and equally common. A laptop that logs in somewhere the server is not reachable produces a failed mount, sometimes with a dialog. There is no sensible behaviour available to a single attempt here, which is the whole reason the other three mechanisms exist.

There is a third one worth knowing about because it looks like corruption. Connecting to the same share twice without disconnecting produces a second mount point with a number appended, and scripts that expect one fixed path start writing into the wrong place. Confirming with mount | grep smbfs in a terminal shows exactly what is mounted and where, and that check takes seconds compared with the time spent puzzling over a folder that appears empty.

The AppleScript route, and what it is for

AppleScript can mount a volume directly, and unlike the login item it can be given the details rather than relying on what is already remembered.

The command is part of the standard scripting additions installed with macOS. Its dictionary describes mount volume as mounting the specified server volume, takes a name or URL path as its direct parameter, and offers optional as user name and with password parameters, with the documented note that both are omitted for guest access. The result is a specifier for the mounted volume, so a script can go on to act on what it just mounted.

Saved as an application and added to the login items list, this behaves like the plain login item with two differences worth having. It can mount several shares in one pass, and it can carry a try block so that a failure does nothing rather than producing a dialog on a network where the server was never going to answer.

The cost is credential handling. A password typed into the script source is a password stored in a readable file, which is a step backwards from the keychain. Leaving the optional parameters off and relying on the keychain entry created by the first manual mount keeps the script free of secrets, and is the version worth using.

Keeping it mounted with a launchd agent

For the second request, mounted whenever possible, the mechanism is a launchd agent: a small property list in the user's LaunchAgents folder that runs a script under conditions rather than once.

The keys involved are documented in the launchd.plist manual page on every Mac, and three of its notes change how the job should be written.

StartInterval starts the job every N seconds, and the manual states that if the system is asleep when the next interval would fire, that interval is missed. A laptop that sleeps between networks therefore gets its next attempt after waking rather than at the moment it reconnects, which is usually acceptable and worth knowing rather than discovering.

RunAtLoad runs the job once when it is loaded, and the manual advises avoiding it on the grounds that speculative launches have an adverse effect on system boot and user login. The same reasoning that makes a login item lose its race applies here.

KeepAlive defaults to false and can be set to true to keep a job running unconditionally, or given a dictionary of conditions for selective control. For a mount script that exits after each attempt, the interval is the right lever and KeepAlive is not.

One more key matters because agents and daemons are not the same thing. LimitLoadToSessionType restricts the configuration file to sessions of the stated type, and the manual notes it applies only to jobs which are agents. A mount belongs to a logged-in user's session, so it belongs in a user agent.

The script the agent runs should test before acting. A mount attempt against an unreachable server is slow and noisy, so checking that the host answers first, and checking that the mount point is not already occupied, turns a chatty job into a silent one.

autofs mounts on access instead of at login

The third request is served by the automounter, which has been part of macOS all along and is the only route that costs nothing while the share is idle.

The automount manual page describes the mechanism: it reads /etc/auto_master, along with any local or network maps that file includes, and mounts autofs on the appropriate mount points so that mounts are triggered on access. The default timeout is stated there too. An automounted filesystem is unmounted if it has not been referred to within one hour, which is 3,600 seconds, and the -t option changes that.

The master map file on a stock Mac is short, and the auto_master manual page documents both its format and the entries that ship in it. A line takes the form of a mount point, a map name, and an optional comma separated list of default mount options. The /- entry with -static is the hook for direct maps, which is where a specific share pinned to a specific path goes. Entries under /Network/Servers come from -fstab.

Two options in that file are easy to confuse, and the manual separates them explicitly. nobrowse in the master map is used on maps that could produce too many entries for browsing to be practical, and it is described as distinct from nobrowse used as a mount option, which affects visibility to the Finder. hidefromfinder is the one that sets the hidden flag on the root directory of the map.

After editing a map, sudo automount -vc applies it, where -v prints what is being done and -c flushes cached information. The verbose output is the difference between a working configuration and an hour of guessing.

Two properties of this approach are worth weighing. A share mounted under a path of choice, rather than under whatever the Finder decided, is stable for scripts, and that alone justifies the setup for anyone whose work touches the share from a shell. The flip side is that the mount happens on access, so the first command that touches it pauses, and an editor's file browser can trigger a mount simply by listing a directory.

The four routes side by side

Route	Answers	Retries	Credentials
Login Items with a mounted volume	Mounted at login	No	Keychain
AppleScript application in Login Items	Several shares at login	No	Keychain, or in the script
launchd user agent on an interval	Mounted whenever possible	Yes, on the interval	Keychain
autofs direct map	Mounted when touched	On each access	Keychain, or nsmb.conf

The column that decides most cases is the second one. A desktop machine that stays on one network needs no retries and should use the supported route with nothing added. A laptop needs retries, and no amount of configuration will make a single login attempt into a reliable one.

Anyone reaching for the automounter should note the mount_smbfs manual page as well, since it is what the lower layers end up calling. It documents reading ~/Library/Preferences/nsmb.conf for additional configuration parameters and a password when run with -N, and it documents the nobrowse and automounted mount options, the first keeping the volume off the desktop and the second flagging the mount point as having been mounted by the automounter.

Where the mount stops being the problem

Once the share is reliably present, the remaining friction is not about mounting at all. It is that the path in a shell and the folder in a window are two representations of the same thing that have to be kept in sync by hand, which is why mount gets typed so often in the first place. A window that holds the folders and a terminal in the same place removes that translation step, and comparing how file managers handle panes, remote volumes and a shell is the shortest route to deciding whether that is worth changing. For work that continues away from the desk, picking up the same session from an iPhone or iPad is a separate question worth asking of whatever is chosen.

What to change first

Decide whether the machine needs one attempt or repeated ones, because that single answer picks the mechanism. A desktop on Ethernet should use Login Items and nothing more. A laptop needs a launchd agent on an interval, or an autofs direct map if the share is mostly touched from a shell, and in that case Atriens keeps the folders and that shell in one window.