Connect to a server from a Mac: the address is half the problem

A share appears under Network on Monday and refuses to appear on Tuesday. Or it appears, and the login is rejected. Or it mounts, works all afternoon, and is gone after the laptop sleeps on a different network. All three get typed into a search box as the same question. They are three different problems, and the fix for one does nothing for the others.

macOS offers two ways to reach a server, and the difference between them is the fastest diagnostic available. Naming which route is failing narrows the cause before anything gets changed.

Two routes in, and they fail for different reasons

The first route is browsing. Open a Finder window and click Network in the Locations section of the sidebar. Apple notes that if nothing appears in the Locations section, holding the pointer over the word Locations reveals the control that expands it. Double-click the machine to connect to, then click Connect As. If the other Mac has screen sharing turned on and the privileges allow it, a Share Screen button appears in the same place.

The second route is the address. In the Finder, choose Go then Connect to Server, type the network address in the Server Address field, and click Connect.

These two routes do not depend on the same machinery. Browsing depends on discovery, and discovery is local. Apple's troubleshooting page states that a machine using Bonjour, or a Windows SMB or CIFS server, has to be on the same local network or subnetwork as the Mac. Typing an address does not depend on discovery at all, and Apple adds the useful corollary: when the computer is not on the local network or subnetwork, it may still be reachable by choosing Go then Connect to Server and typing its address.

That single distinction resolves a large share of these searches. A server that never shows up under Network, but connects fine once its address is typed, is not broken and neither is the Mac. Discovery traffic is simply not crossing the boundary between the two networks. Nothing about credentials, permissions or the server's configuration needs to be touched.

The reverse case points somewhere else entirely. A server that appears under Network but rejects the login is a discovery success and an authentication failure, and the next place to look is the account list on the other machine rather than the network.

The address is where most attempts actually fail

An address has three parts: a protocol, then a DNS name or an IP address, then a pathname. Apple's own reference page for servers and shared computers a Mac can connect to lists the accepted formats.

What the other end is	Address format
SMB or CIFS server, or a Windows shared folder	smb://DNSname/sharename or smb://IPaddress/sharename
NFS server	nfs://DNSname/pathname
WebDAV server	http://DNSname/pathname

Two details in that reference save real time. The computer name works in place of the DNS name. And if the shared folder is left off the end of an SMB address, the volume can be chosen from a list after the user name and password are accepted. Typing smb://fileserver and picking from what comes back is often faster than guessing at a share name, and it also answers the question of whether the account can see anything at all.

Apple's list of what a Mac can reach covers Mac and Windows computers with file sharing turned on, Windows computers with shared folders, AirPort disks and Time Capsules, SMB or CIFS, NFS, FTP and WebDAV services running on UNIX, Linux and Windows servers, and FTP servers.

The FTP entry carries a limit worth reading before planning around it. Apple states that FTP access through the Finder is read only: files can be copied from the server, but copying files to it may require a separate FTP application. Anyone whose workflow is upload rather than download has hit the ceiling of what the Finder does here, and no address format changes that.

Three names for the same Mac, and only one of them fits

Half the failed addresses come from typing the wrong kind of name. A Mac carries three identifiers, and Apple documents where each one is displayed.

Computer name

In System Settings, General in the sidebar, then About. The name sits to the right of the Name field and can be edited there. This is the label other people see when they browse the network.

Local hostname

In System Settings, General, then Sharing, shown at the bottom of the window and editable through the Edit button. Apple describes the rule: the local network name is the computer name with .local added, and spaces replaced by hyphens. A machine called My Computer answers to My-Computer.local, and the name is not case sensitive, so my-computer.local reaches the same place.

Network address

In Sharing, clicking the information control next to a service that is switched on displays the address for that service. Apple's examples show File Sharing producing something like smb://10.212.167.33 or smb://name.example.com, Screen Sharing producing a vnc:// address, and Remote Login producing a user name joined to a host by an at sign.

One line in that page explains a symptom that otherwise looks random. The network address is supplied by the DNS server the computer uses, and where no DNS service is in play, the address is derived from the computer name instead. So a .local name that works at a desk can stop working over a VPN, because the mechanism that resolved it never left the local segment.

What the Connect As sheet is actually deciding

After the address is accepted, macOS asks how to authenticate, and the three options are not interchangeable.

Guest works only if the shared computer permits guest access. It is the quickest way to test whether the path and the address are right, because a guest connection that succeeds proves the network half of the problem is solved.

Registered User uses a login name and password on the other machine. Apple adds the condition that matters here: if the other Mac has "Only these users" selected, the login name has to be on its list of allowed users. An account that exists is not the same as an account that has been granted access.

Using an Apple Account requires that the account is set up in Users and Groups settings on both Macs, not just the one being connected from.

For SMB shares on a Mac specifically, there is one more gate on the far side. Apple's instructions for SMB file sharing include a Windows File Sharing list where the On checkbox has to be selected for each user who needs to reach the share from a Windows computer, with that user's password entered. A Mac with File Sharing on and SMB enabled can still refuse a Windows client whose account was never checked in that list.

Getting the same share back without typing it again

A connection that has to be rebuilt by hand every morning is the complaint underneath a lot of these searches, and macOS has four separate mechanisms for it. They are worth knowing apart, because they survive different things.

Recent servers is the shortest. The Apple menu has a Recent Items entry that includes servers, and the Connect to Server dialog has a pop-up menu at the far right of the Server Address field holding the same list.

Favourites are more durable. Entering an address in Connect to Server and clicking the add control keeps it in the dialog permanently, which removes the retyping without automating the mount.

The Finder sidebar can hold the other end directly. Apple's instruction is to select the shared computer, network area or workgroup, then choose File then Add To Sidebar. This keeps the destination one click away even when it is not currently mounted.

Login Items is the mechanism that actually reconnects without being asked. Apple's description of Login Items and Extensions settings says these are the apps, documents and server connections that open automatically at login, and the Kind column in that list distinguishes app, document, folder and volume. A mounted volume dragged in there is what turns a share into something that is simply present after a restart.

One check belongs here too, because it produces a mount that appears to have failed when it has not. 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 in its own troubleshooting page for a reason. A successful mount with both checkboxes clear leaves no visible sign anywhere.

When neither route works

At the point where browsing and a typed address both fail, the remaining causes are short enough to walk through in order, and Apple's page for a Mac that cannot connect to another computer lists them.

Start with the obvious and unglamorous one: the other end may have been shut down, restarted, or disconnected from the network. Servers that are reached every day get assumed to be up, and a restart that finished an hour ago looks exactly like a permissions problem from this side.

Next, check that the name being looked for is the right one. Apple's wording is that the DNS name or IP address may be needed rather than the name of the computer, which is the same trap as the .local name that only resolves on one segment.

Then check the Mac's own connection. In System Settings, Network in the sidebar, the indicator next to the type of connection should be green. A Mac that is on Wi-Fi without a usable route produces errors that read like server errors.

Two firewall and network conditions round it out. Apple states that a Windows SMB or CIFS server with its firewall turned on may be unreachable, and that for Connect to Server to work, both ends need to be connected to the internet and not connected to private networks. A VPN on either side is enough to break a connection that worked yesterday, and that is worth eliminating before anything gets reconfigured.

The half the Finder does not address

Once a share is mounted it behaves like a disk, and for opening and saving documents that is the end of the story. Two things stay awkward, and they are the reason this task keeps coming back.

The first is the shell. A mounted volume lives under a mount point, and moving between a Finder window showing the share and a terminal working inside it means translating between a window and a path by hand. Dragging a folder into a terminal window pastes its path, which is a workaround rather than a fix.

The second is the gap between the two sides. Copying, comparing and renaming across a local folder and a remote share means two windows and a lot of pointer travel, which is exactly the shape of work that dual pane file managers exist for. The practical question is not which window is prettier but whether the folders, the shell and the remote volume are reachable without switching windows, and comparing how file managers arrange panes, remote volumes and a terminal answers it faster than trying transfer clients one at a time. Where the remote work continues away from the desk, reaching the same session from an iPhone or iPad is a separate axis worth checking against whichever tool is chosen.

What to change first

Decide which of the two routes is failing, because that alone rules out half the possible causes. If the server never appears under Network but a typed smb:// address reaches it, stop looking at credentials and put the address in Favourites. If the mount is fine and the friction is switching between a Finder window and a shell inside it, the thing to change is the window, and Atriens keeps folders, a terminal and remote volumes in one.