Mapped Drives Missing After Restarting a Mac? Keep Mounted

Yes — mapped network drives can disappear after you restart a Mac. The usual causes are the network or VPN not being available when macOS tries to restore mounts, or saved credentials not accessible at login. Start with the simple reconnect-at-login steps below; if those don’t work, use autofs or a small login script for a more durable solution.

Symptom: what you see and when it happens

You had network shares mounted (SMB, AFP or NFS) and after you log out, restart, or reboot the Mac the shares are gone from Finder or the Desktop. The Finder sidebar or mount-point directory is empty, and applications that relied on the share report “file not found” or similar errors.

• This usually appears right after you sign in or just after a restart.
• If you saved a login window session that included Finder windows pointing at the share, Finder can open the window but the contents are missing until the share is mounted.

If there is an explicit error message from the system when a mount fails, that exact message will vary by macOS release and mount method.

Before you start (applicability and safe checks)

• Check the protocol you used to mount the share: SMB, AFP or NFS. AFP is legacy and may not be supported by all servers.

• Confirm how you mounted the share: Finder > Connect to Server, an automount map, mount_smbfs, or a third-party tool.

• Check whether the share is in Login Items: open System Settings > General > Login Items. On older macOS releases this control is under System Settings > Users & Groups > Login Items.

• Verify network availability at login: your Mac must be on the same LAN, or your VPN must be connected, before the mount is attempted. Wi‑Fi can come up later than Ethernet.

• Confirm saved credentials: when you first connected, did you allow the password to be saved to Keychain? If not, the mount can fail silently at login.

• Note permissions and system protection: advanced fixes (editing /etc/auto_master, creating launchd plists) require an admin account and may be affected by System Integrity Protection. Back up config files before you edit them.

Fix 1 — Quick, reversible: reconnect at login (recommended first)

These steps are the lowest risk. Do them before editing system files.

1. Mount the share manually in Finder: Go > Connect to Server and connect to the share.

System Settings > General > Login Items

2. When prompted for credentials, choose to save the password to Keychain so the system can use it at login.

3. Add the mounted share (or an alias to it) to Login Items so macOS will open it after you sign in.

4. If Login Items still fail to mount reliably, create a small Automator app or AppleScript that opens the share and add that app to Login Items instead.

try
	tell application "Finder" to open location "smb://fileserver/share"
end try

Expected result: after you sign in the share window opens and the share appears in Finder. If you still see a password prompt at login, Keychain did not provide the credential or the saved item requires confirmation. If the share does not appear, the network or VPN was not ready when the Login Item ran.

Fix 2 — If Login Items are unreliable: add a delayed login script (user-level)

Use this when you only need the mount in your user session and you suspect the network is still initializing at login.

1. Create a script that waits a short time and then mounts the share with Finder or mount_smbfs.

#!/bin/bash
sleep 10
open "smb://fileserver/share"

2. Make the script executable:

chmod +x ~/scripts/mount_share.sh

3. Save a small launch agent plist in ~/Library/LaunchAgents to run the script at login, or wrap the script in an Automator app and add it to Login Items.

Expected result: the script runs after login and opens the share once the network is up. If it still fails, check Keychain access and whether the VPN or DNS is available when the script runs.

Fix 3 — System-level mounts with autofs (more durable)

Use autofs (automount) when you need mounts available system-wide and to mount on demand. This is more durable but requires admin access and careful editing.

1. Back up the current master map:

sudo cp /etc/auto_master /etc/auto_master.backup

2. Edit /etc/auto_master to add a direct map. For example, add this line to reference a new map file:

/-    /etc/auto_smb

3. Create /etc/auto_smb with the mount entry. Use credential files or Kerberos where possible; avoid embedding plaintext passwords.

/mnt/share -fstype=smbfs ://username:password@server/share

4. Reload the automounter and show verbose output:

sudo automount -vc

5. Access the mount point to trigger the automount: open /mnt/share.

Expected result: the path mounts on access and stays available while in use. If it does not mount, check permissions on map files, automount status, and whether System Integrity Protection blocks edits on your macOS release. If unsure, consult Apple’s developer documentation for your exact macOS version because keys and paths can change across releases.

Fix 4 — launchd job for network-aware mounts (alternative to autofs)

Use a launchd job that waits until the network is ready or the VPN is connected before mounting.

1. Create a script that checks network reachability (or VPN state), then mounts the share using open or mount_smbfs.

2. Put a user-level plist in ~/Library/LaunchAgents that runs the script at login and can be configured with KeepAlive or StartInterval options.

Expected result: the job mounts the share after network conditions meet your criteria. If it fails, inspect the job logs in Console.app and confirm the script runs when you expect.

What to check if problems continue

• Keychain: open Keychain Access and confirm the saved password is present and allowed to be used by the system at login.

• DNS and name resolution: if the mount uses a hostname, test with ping or dig to confirm it resolves.

• VPN: confirm the VPN establishes routes and DNS before the mount attempt; some clients provide an API or a launchd event you can wait for.

• Server-side SMB settings: some SMB servers require particular dialects, signing, or Kerberos; confirm server compatibility.

• Finder privacy/permissions: recent macOS releases may require explicit permission for automation or for a Login Item to control Finder; check System Settings > Privacy & Security.

• Logs: open Console.app and search for automount, mount_smbfs, mount, or your server name around the time of login to see errors.

Verify: how to confirm the drive is mounted and the fix worked

• In Finder the share appears in the sidebar or on the Desktop (if you enabled Desktop icons).

• In Terminal list mounts:

mount | grep -i smb

• Or check disk usage for the share:

df -h | grep -i servername_or_share

• Test persistence: log out and back in, then reboot. If the mount comes back automatically after these actions the fix worked.

What to expect if the test fails: a Keychain prompt at login, a mount error in Console.app, or no network route to the server. Diagnose those specific failures next.

Prevent this from happening again

• Save credentials to Keychain when you connect, or configure Kerberos or a secure credential file with limited permissions for system mounts.

• Prefer autofs for server-side mounts you want available to all users and to mount on demand.

• If you use VPNs to reach the server, configure a login or launchd step that waits for the VPN or for the network route to be available before mounting.

• For critical workflows, prefer Ethernet or an automatic VPN-on-login so the network is ready at the start of the session.

Conclusion

If a Login Items + Keychain approach doesn’t solve the problem, use a delayed login script or autofs for a more reliable, system-level mount. If the issue persists, check Keychain access, DNS, VPN timing and server compatibility; consult your IT team before changing system files on a managed Mac.