For four decades, the Apple Filing Protocol quietly underwrote every "just works" file-sharing experience in the Apple ecosystem. That era has ended. Apple deprecated the AFP client in macOS Sequoia 15.5, carried a removal warning through macOS 26 Tahoe, and shipped the macOS 27 "Golden Gate" developer beta with no AFP client at all. If your storage estate still serves Mac clients over afp://, the compatibility gap is live today, not on a future roadmap.
This deprecation goes well beyond a Finder cosmetic change. Apple has pulled an entire protocol stack out of the client OS, which forces every storage engineer supporting mixed Mac/Windows/Linux environments to finish a transition that has technically been recommended since OS X 10.9 Mavericks in 2013. This post walks through the timeline, the protocol-level case for SMB3, and the migration details that tend to bite teams who treat the cutover as a simple checkbox flip.
The timeline, for the record
- 2013 — Mavericks makes SMB2 the default file-sharing protocol on macOS; AFP becomes legacy.
- 2020 — Big Sur removes the AFP server role entirely. Macs can no longer host AFP shares, only connect to them.
- May 2025 — Sequoia 15.5 formally deprecates the AFP client, with an explicit note that it "will be removed in a future version of macOS."
-
2026 — macOS 27 ships without an AFP client.
mount_afp, Finder's AFP handling, and AFP-based Time Machine targets are gone.
Any NAS, SAN gateway, or file server still relying on Netatalk or a legacy AFP stack to serve Mac clients now has a hard deadline. Third-party AFP implementations that depend on macOS-side kernel extensions or FUSE-based mounts are affected too, since Apple's kernel extension deprecation is running on a parallel track.
The case for SMB3 specifically
Teams still running SMB1, or unauthenticated SMB2, purely to keep older Time Capsules or NAS units alive should treat this as the moment to stop. SMB1 lacks integrity verification and carries a long history of exploitation, including EternalBlue-class vulnerabilities, so it belongs disabled at the server regardless of client OS. SMB 3.x is the real target, for reasons that hold up at the protocol level.
Encryption and signing. SMB3 supports AES-128-GCM/CCM encryption per-share or per-connection, along with mandatory signing options AFP never offered natively. Any Mac fleet moving data over untrusted network segments picks up a real security gap closed here.
Multichannel. SMB3 Multichannel lets a single session span multiple NICs or RSS-capable interfaces at once, which matters for engineers pushing large media or scientific datasets from Mac workstations into NAS/SAN backends. AFP had nothing comparable; its single-TCP-stream design was a persistent throughput bottleneck on high-bandwidth workflows.
Persistent handles. SMB 3.0 and later support transparent failover for clustered file servers, so a client can survive a node failover without throwing the application-level errors AFP clients would generate. This matters directly for anyone fronting storage with Windows Failover Clustering, a Samba CTDB cluster, or clustered NetApp/Isilon nodes.
Leasing and oplocks. SMB2/3 leasing gives finer-grained caching semantics than AFP's older locking model, cutting round trips on read-heavy workloads while still invalidating correctly on writes.
Native APFS/HFS+ metadata handling. Modern SMB implementations, particularly Apple's own SMB client/server and Samba with the fruit VFS module, can carry macOS-specific metadata such as resource forks, Finder info, and ACLs over SMB using AAPL extensions. That closes most of the old argument that AFP handled Mac metadata better.
Where migrations go wrong
Time Machine has no native SMB destination path from Apple's own tooling. Time Machine over SMB does work, but only through NAS vendor implementations that advertise the correct SMB extensions — Apple's Time Machine SMB spec, or fruit:time machine = yes in Samba. Time Capsules and older NAS units that only speak AFP or SMB1 are effectively end-of-life for Mac backup duty. Budget the hardware refresh or the migration to a Samba/vfs_fruit backend now, before the next macOS upgrade forces the issue.
Case sensitivity and Unicode normalization. AFP quietly handled case-insensitive, Unicode-NFD-normalized behavior that Mac users relied on without knowing it. SMB servers, especially Samba on Linux, default to case-sensitive, NFC-normalized filesystems. Left unaddressed, that mismatch produces duplicate-looking files, sync conflicts, and broken alias/.DS_Store behavior. Setting case sensitive = auto, default case = lower, and enabling vfs_fruit with fruit:encoding = native on Samba approximates the old AFP behavior. Do this before cutover, not after the tickets start coming in.
ACL model mismatch. AFP largely exposed POSIX-style permissions to macOS clients. SMB3 exposes full NTFS-style ACLs on any filesystem that supports them — NTFS, ReFS, or POSIX ACLs mapped through Samba. On a POSIX-only backend, check how vfs_fruit/vfs_acl_xattr map inherited permissions, since Mac users accustomed to POSIX simplicity can be confused by NTFS-style ACL inheritance showing up in Finder's Get Info panel.
Extended attributes and resource forks. Legacy AFP volumes stored resource forks and Finder metadata through AFP-native mechanisms. Moving that data to SMB/CIFS shares without vfs_fruit (Samba) or an equivalent AAPL-extension target quietly drops custom icons, color labels, and Finder comments during the copy. Migrate with rsync -E or Apple's ditto rather than a generic cp or rsync to keep those attributes intact.
Authentication path. AFP commonly rode on simple Kerberos or password auth with minimal negotiation overhead. SMB3 environments should run Kerberos through Active Directory or a properly configured Samba AD DC, with NTLM fallback disabled where possible. macOS's SMB client is increasingly biased toward Kerberos-first negotiation anyway, so this also avoids fallback surprises.
The operational takeaway
Treat this as a forcing function rather than a footnote about one deprecated protocol. Any storage architecture still treating AFP as a supported client path needs an inventory pass now: NAS firmware versions, Netatalk instances, Time Capsule-class hardware, and backup jobs that quietly depend on any of it. Standardize on SMB3 with Kerberos authentication, confirm vfs_fruit/AAPL extension support on every Samba-backed share serving Mac clients, and test Time Machine over SMB explicitly rather than assuming it works. Apple has set a hard deadline. Getting the storage layer caught up before the next macOS upgrade lands fleet-wide will save a lot of last-minute triage.
If you're staring down a similar migration, or any storage decision that needs to hold up under production pressure, that's exactly what Mitaka Digital works on. We help media and entertainment teams design and migrate storage and archive infrastructure that stays reliable at scale, from on-prem NAS and LTO through hybrid and cloud. Have a project in mind? Get in touch at mitaka.digital and let's talk through your setup.
Top comments (0)