AFP file sharing on a Mac: what to use now that it is gone

Someone looking up AFP file sharing on a Mac is usually in one of two situations. Either an old NAS or an old Mac share stopped mounting and the address in the bookmark starts with afp://, or a working setup is being documented and the question is whether AFP is still a reasonable thing to build on.

The short answer for both is that AFP is finished as a client protocol on current macOS. This is not a setting that can be switched back on. The useful work is in confirming what a given connection actually uses today, moving the shares that still speak AFP, and knowing which parts of AFP behaviour have a direct replacement and which do not.

How to confirm AFP is really gone on a given Mac

macOS mounts network filesystems through bundles kept in one directory, and the list is readable without any special tooling. On macOS 27, ls /System/Library/Filesystems returns entries for apfs.fs, exfat.fs, ftp.fs, hfs.fs, msdos.fs, nfs.fs, ntfs.fs, smbfs.fs, webdav.fs and a handful of others. There is no AFP entry. The companion directory that Finder uses for its own network browsing, /System/Library/Filesystems/NetFSPlugins, contains ftp.bundle, http.bundle, nfs.bundle, smb.bundle and xpc.bundle. Again, no AFP.

The mount helper is gone too. Older macOS releases shipped /sbin/mount_afp alongside /sbin/mount_smbfs. On a current system only the SMB helper is present.

That is the whole explanation for the failure most people arrive with. An afp:// address typed into Finder's Go, Connect to Server, or stored in a login item, or baked into a backup script, has nothing left to hand the request to. The error text is usually vague about the cause, which is why the protocol is worth ruling in or out first before suspecting the network, the password or the NAS itself.

Apple's own documentation has already moved on. The current Mac Help page on setting up file sharing describes turning on SMB sharing and lists exactly two advanced options per shared folder: "Only allow SMB encrypted connections" and "Share as a Time Machine backup destination". The page on connecting to shared computers and servers says a Mac can reach "servers that use protocols such as SMB", and the address example it gives is smb://computername.example.com. AFP appears in neither.

What SMB gives back, and what it does not

AFP and SMB are both file sharing protocols, but they were built in different decades for different networks, and the trade is not one for one. Setting the comparison out plainly makes it easier to predict which habits will survive the move.

Behaviour	AFP	SMB on current macOS
Client present in macOS 27	No	Yes, smbfs.fs and /sbin/mount_smbfs
Documented by Apple today	No	Yes, in Mac Help and in Sharing settings
Connection encryption	Not offered in macOS Sharing	Per-folder option, plus client side forcing
Multiple network paths per session	No	Yes, multichannel, on by default
Time Machine over the network	Legacy route	Supported via a shared folder marked as a destination
Resource forks and extended attributes	Native	Carried, with caveats per server
Windows and Linux servers	Third-party implementations only	Native

The two rows worth dwelling on are encryption and multichannel, because they are the reasons the move is worth making on its own terms rather than only because AFP disappeared.

Encryption is per folder on the sharing side, and it can also be demanded by the client. Multichannel lets a single SMB session use more than one network path at once, which on a Mac with both Ethernet and Wi-Fi active is the difference between one link's throughput and the combination. Neither had an equivalent in the AFP era.

The row that causes real pain is the last but one. AFP handled Mac metadata natively because it was a Mac protocol. SMB carries the same metadata, but how faithfully depends on the server. A NAS running a recent build of Samba with the Apple extensions enabled will behave close to the old setup. An older appliance, or a Windows file server with no Mac-specific configuration, will lose Finder tags or colour labels, and will scatter ._ companion files. Tags are a common casualty, and anyone whose filing depends on them should test with a handful of files before moving a whole archive. A file manager that shows extended attributes directly, rather than only what Finder chooses to surface, makes that test much quicker, and the Features page lays out what that kind of view covers.

Reading what a mount is actually doing

Once shares are on SMB, the interesting question stops being which protocol and becomes which version, and whether encryption and signing are in force. macOS ships a tool for exactly this.

Running smbutil statshares -a prints the attributes of every mounted share: the server name, the SMB dialect in use, whether signing is on, whether the session or the share is encrypted, and which optional features the server negotiated. smbutil multichannel -a lists the channels in a session, which is how to confirm that a second network path is genuinely being used rather than merely available. Adding -f JSON to statshares makes the output easy to keep in a log and compare later.

This matters because SMB negotiates. Two Macs on the same network connecting to the same NAS can end up on different dialects with different security properties, depending on client settings and what the server offered at the time. A slow or flaky share is often a negotiation outcome rather than a hardware problem, and the negotiated state is visible in one command.

The same reasoning applies to browsing. smbutil view //user@server lists the shares a server is offering, which separates "the share name changed" from "the credentials are wrong" without any guesswork in Finder. smbutil identity //user@server goes one step further and prints how the server sees the connecting account, which settles arguments about permissions that look wrong on the Mac side but are really a mapping problem on the server.

There is a practical reason to record this output at the point where a share is known to be working well. When the same share turns slow six months later, a saved listing of the dialect, the signing state and the channel count is the fastest way to tell what changed. Guessing from Finder's behaviour alone rarely narrows it down.

Moving an old NAS or Mac share across

For a share hosted on another Mac, the work is small. In System Settings, General, Sharing, turn on File Sharing, then open Options and turn on "Share files and folders using SMB". Shared folders are listed in the same pane, the Public folder of every account on the Mac is shared automatically, and per-folder access can be granted to specific users or groups. The network address to hand out appears in the same pane under the File Sharing indicator, in the form smb:// followed by the name or the IP address.

For a NAS, the sequence is firmware first, then protocol. Appliance vendors have been retiring their AFP services on their own schedule, and a unit that still advertises AFP is usually also running a build of Samba old enough to negotiate a dialect no longer considered acceptable. Updating the firmware, enabling SMB with the Mac extensions, and only then repointing clients avoids a second round of troubleshooting.

Two details reliably cause trouble on the way across. Old bookmarks and login items keep their afp:// prefix and have to be recreated rather than edited. And any script or backup job that calls mount_afp needs rewriting around mount_smbfs or around open smb://, because the binary it expects is not on disk any more.

When the other end cannot speak SMB at all

Some hardware will never be updated. A network drive from the AirPort era, a scanner that writes to a share, or an appliance whose vendor no longer publishes firmware, may only ever offer AFP. Three honest routes exist, and the choice depends on how often the files are needed rather than on how the device is supposed to work.

Keeping one old Mac on an older macOS as a bridge works, and is common in studios with archive volumes. The old machine mounts the AFP share and re-shares the contents over SMB. It is a maintenance liability, since that machine stops receiving security updates, so it belongs on an isolated network segment rather than on the main one.

Pulling the disk is better when the data is static. An archive volume that has not changed in years does not need a protocol at all. Copying it to a drive that current hardware can read, and verifying the copy, removes the dependency permanently.

Using a different protocol on the same device is the option people miss. Many older appliances also offer NFS, FTP or WebDAV, and macOS still ships clients for all three, which is visible in the same filesystem listing that no longer mentions AFP. None of them carry Mac metadata as well as SMB with the Apple extensions, but for pulling files off a legacy box once, that hardly matters. Mounting over NFS and copying with a tool that preserves what it can, then checking the result, beats keeping an unpatched Mac alive for the sake of a folder that is read twice a year.

What none of these routes restore is the old convenience of an address that simply worked from every Mac in the building. That convenience is now tied to SMB, which is worth accepting early rather than rebuilding around a protocol with no client left. Access from a phone or a tablet follows the same rule, since the standard file browsing there also speaks SMB, and From iPhone and iPad covers what carries across when the Mac is not to hand.

Tuning SMB when it feels slower than AFP did

The most common complaint after a move is that Finder feels sluggish in large directories. This is usually cacheing and notifications rather than raw throughput, and macOS exposes both through a configuration file, /etc/nsmb.conf, documented in man nsmb.conf.

The keys that address directory sluggishness are dir_cache_max and dir_cache_min, which default to 60 seconds and 30 seconds and control how long a directory listing is cached, and dir_cache_async_cnt, which defaults to 10 and sets how many queries may run at once to fill that cache. notify_off turns off change notifications for servers that handle them badly. On the security side, signing_required defaults to no and can be turned on, while force_sess_encrypt and force_share_encrypt demand encryption from the client side rather than waiting for the server to offer it. Multichannel is governed by mc_on, on by default, with mc_max_channels at 9 and mc_prefer_wired available for machines where Wi-Fi should not be preferred.

Changes belong in a [default] section, or under a server name, or under a specific server and share, and the man page marks which keys are valid at which level. Values should be changed one at a time, with smbutil statshares -a used to confirm the effect, because several of these keys trade safety for speed and it is worth knowing which one bought the improvement. Doing that loop in a window that has folders and a shell side by side removes most of the friction, and the Compared with other file managers page covers how tools differ on that point.

What to change first

Start by confirming the protocol rather than the symptom: run ls /System/Library/Filesystems on the Mac that fails, and note the absence of an AFP entry. Then rebuild the connection as an SMB address and check the result with smbutil statshares -a before touching any other setting. If the far end cannot offer SMB, decide now whether the data is static enough to copy off once and retire, because a bridge machine is a commitment. A single window that keeps the mount, the shell and the notes together shortens the whole exercise, which is what Atriens is built around.