Why Does My Network Drive Disconnect on Mac? Causes & fixes

Your Mac disconnects from a network drive because either your Mac or its network link is going idle, the server is closing idle sessions, or the mount/credentials on macOS aren’t staying persistent. Start with quick checks: test over wired Ethernet, stop macOS from sleeping, and remount the share with authentication; if it still drops, collect timestamps and ask the server/NAS admin to check idle timeouts and session logs.

Symptom: what you see and when it happens

You see the mounted share disappear from Finder, file copies fail with an I/O or connection error, or an open document shows "file not found" when you try to save. This usually happens after a period of inactivity (minutes to hours) or when the Mac sleeps, switches Wi‑Fi networks, or the NAS/server restarts. If you see a literal error message, copy it exactly before disconnecting; the exact message varies by server and macOS version.

Before you start (scope, preconditions and safe checks)

• Scope: macOS client-side troubleshooting up to collecting evidence for a server or IT escalation; not deep NDA-protected corporate server changes.

• Preconditions: you can disconnect and reconnect the drive without losing unsaved work; you have user credentials for the share if required.

• Safe checks and stopping conditions:

• Save work before unmounting or restarting network services.
• Note current settings you change so you can revert them.
• If your Mac is managed by IT, check policy or ask permission before changing network or startup items.

• Tools you may use: Finder, System Settings (System Preferences on older macOS), Terminal for simple pings, and access to a wired Ethernet port or a USB‑C dock.

Quick checks to do now (fast, reversible steps)

These steps isolate the most common local causes: Wi‑Fi instability and macOS sleep/power settings.

• Prerequisites: save work you can’t lose and have the server address and credentials ready.

1. Test on wired Ethernet to rule out Wi‑Fi.

1. Plug an Ethernet cable into your Mac or dock and turn Wi‑Fi off.

1. In Finder choose Go > Connect to Server and enter the share address, for example:

smb://server.example.local/share

1. Observe: if the mount stays connected while wired, Wi‑Fi is the likely cause; if it still drops, proceed to the next checks.

2. Toggle Wi‑Fi and reconnect.

1. Turn Wi‑Fi off, wait 10 seconds, turn it back on, then remount the same SMB address.

1. If reconnects succeed but later drop again, the issue is probably link instability or power management.

3. Check basic reachability with ping (stop after a few lines if you see packet loss):

ping -c 5 server.example.local

• Expected: minimal packet loss and stable latency. Packet loss or high latency indicates a network problem to fix first.

4. Enable "Reconnect at login" for the mount as a short-term convenience: add the mount in Finder, then add it to Users & Groups > Login Items to have macOS try to remount at login.

If it still disconnects: check macOS power, credentials and per-user settings

Do these safe, reversible checks next to see if the problem is local to your Mac.

• Before changing settings, save work and jot down current values so you can revert.

1. Prevent sleep for testing.

1. Open System Settings > Displays (or System Preferences > Energy Saver on older macOS) and disable automatic display sleep or enable the setting that prevents the Mac from sleeping when the display is off for a test period.

1. Disable any "Put hard disks to sleep when possible" option if present.

• Expected result: if macOS sleep or disk-sleep caused the disconnects, the share should stay mounted while the Mac remains awake. If it still drops, continue diagnosing.

2. Test a different macOS user account or Safe Mode.

1. Create a new local user (System Settings > Users & Groups), log into that account, mount the share and observe.

1. If the share stays in the new user, the issue is likely a per-user login item, keychain, or mount preference.

3. Inspect keychain and saved credentials.

1. Open Keychain Access and look for saved passwords for the server; delete stale entries, then reconnect and re-save credentials when prompted.

• Expected result: fixing bad or duplicate credentials prevents repeated authentication failures that can drop mounts.

4. Check for per-user login items that may unmount shares.

1. Open Users & Groups > Login Items and remove items that may interfere, or add the network mount here so macOS handles it at login.

5. Test with another Mac or device on the same network.

• If other devices keep the same share connected, the problem is likely your Mac. If they also drop, the issue is server or network-side.

Protocol and server-side checks to request or perform next

If local checks point away from your Mac, gather evidence and ask your admin or vendor to inspect server/NAS and network settings.

• Things to check on the server/NAS (requires admin access):
• SMB/AFP idle/session timeout values that disconnect clients after inactivity.
• Server keepalive settings or TCP session timeout.
• NAS firmware settings for client session limits or aggressive power saving.
• Whether SMB signing, encrypted transport, or protocol version mismatches affect session stability.

1. Collect these details before contacting admin: NAS brand and model, firmware version, protocol used (SMB vs AFP), how you mount the share, and timestamps of disconnects.

1. Ask the admin to temporarily extend idle timeouts or enable server-side keepalives and to check session logs for your client at the disconnect times.

• Expected result: if server-side idle timeouts were the cause, extending the timeout or enabling keepalive should stop the disconnects. If not, provide logs and timestamps and request deeper network tracing.

A safe diagnostic sequence you can follow now

Follow this order to isolate where the disconnects originate: local Mac → link → server.

1. Reproduce the symptom and note the time.

1. Test wired Ethernet with Wi‑Fi off and mount the share as shown earlier.

1. Keep the session idle for longer than the previous drop interval while monitoring.

1. If it drops on wired, run the ping test while idle and collect timestamps.

ping server.example.local

1. If wired stay stable, switch back to Wi‑Fi and test again to confirm link instability.

1. If instability persists on wired, collect timestamped logs and contact the server admin with: what you did, exact mount path, authentication type, and disconnect times.

• Expected interpretation: stable on wired but not on Wi‑Fi = Wi‑Fi or router issue. Drops on wired = server or network infrastructure problem requiring admin logs.

Verify the fix

How to confirm the problem is resolved.

1. Reproduce the original sequence (same client, same network, same mount).

1. Let the session sit idle longer than the previous drop interval while you monitor Finder and Terminal.

1. Optionally, run a continuous copy or open a large file to exercise the connection.

1. While idle, keep pinging the server to watch for packet loss:

ping server.example.local

• Expected result: the share remains in Finder, file operations succeed, and pings remain stable. If it stays connected past the previous drop point, the change likely fixed the issue. If it still drops, collect logs and escalate to IT or the NAS vendor.

Preventing recurrence

• Use wired Ethernet for critical mounts when possible.
• Enable "Reconnect at login" for mounts you regularly need.
• Use authenticated mounts (not guest) because servers often treat guest sessions differently.
• Ask your admin to increase server idle timeouts or enable server-side keepalives if allowed.
• For a short-term local workaround, a scheduled script that touches a small file periodically can keep a session active; check your IT policy before running scheduled scripts on managed machines.

Conclusion

If wired testing and disabling sleep stop the disconnects, the issue was likely your Mac or Wi‑Fi. If the drive still drops on wired, collect timestamps and escalate with the exact mount path, protocol, and client logs so your server/NAS admin can check idle timeouts and session logs.