Is anyone working on an AFP client for modern macOS? It’s been deprecated since 15.5. A client that can connect to both netatalk and classic mac AFP shares would be ideal. Does this exist?
AFP client for post macOS 15.5 macs
- Thread starter Slimes
- Start date
I'm aware of at least two AFP client projects: afpfs-ng and afp-perl. Both support AFP over TCP, rather than over AppleTalk (i.e. the same as every macOS release has since Mac OS X Tiger.) Both are command-line tools that will run on macOS as well as BSD and Linux systems.
One question is whether your idea of an AFP client means full integration, where mounted server volumes appear in the Finder. That currently requires FUSE support on macOS, which means installing a 3rd-party closed-source kernel extension. Apple has deprecated kernel extensions, but (unlike AFP) has not specified a cutoff release for them yet. MacFUSE would need to get rewritten as a userspace system extension at some point if support for kernel extensions is dropped. A project to do that was started a couple of years ago as FUSE-T, but its development has been sporadic and it has some concerning open issues relating to data corruption and extended attribute support.
The AFP client in macOS Tahoe (26.0.1 as of today) still works fine, and given Apple's expected schedule, it will continue to work fine until the next major OS release in Fall 2026. But the clock is ticking.
One question is whether your idea of an AFP client means full integration, where mounted server volumes appear in the Finder. That currently requires FUSE support on macOS, which means installing a 3rd-party closed-source kernel extension. Apple has deprecated kernel extensions, but (unlike AFP) has not specified a cutoff release for them yet. MacFUSE would need to get rewritten as a userspace system extension at some point if support for kernel extensions is dropped. A project to do that was started a couple of years ago as FUSE-T, but its development has been sporadic and it has some concerning open issues relating to data corruption and extended attribute support.
The AFP client in macOS Tahoe (26.0.1 as of today) still works fine, and given Apple's expected schedule, it will continue to work fine until the next major OS release in Fall 2026. But the clock is ticking.
Agreed. One nice thing about running a Mac OS 9 VM in QEMU is that you don't have to worry about the host system having an AFP client or AppleTalk support, because the guest system supports both. There's also no need to install a kernel extension.
Note: for the Mac OS 9 VM to mount shares over EtherTalk (i.e. servers using AFP versions prior to 3.0), QEMU needs to be running in bridge networking mode rather than the default user mode, so that non-TCP/IP protocol packets can be used. That requires running QEMU as root, which you can do with 'sudo'. But if you only need to mount AFP-over-TCP shares, then the default configuration running as the normal user will work fine.
FWIW I have been tinkering with my own fork of afpfs-ng on and off for a few years. I have fixed a lot of bugs and improved the code quality while adding support for MacFUSE. But there's some fundamental flaw with the FUSE code that makes it extremely unstable on contemporary systems (Linux and macOS both). After just a few files transferred the afpfsd process always gets deadlocked. This is not a bug that I introduced, but the way all other forks behave too. I suspect something changed in the FUSE library over the years that exacerbated some design flaw in this software. I haven't given up yet but it's proven challenging to debug.
The good news is that the CLI client (afpcmd) works quite well which is handy in a pinch. But obviously most people want a nice GUI with drag'n'drop for file management, so it's not a mainstream solution.
The AppleTalk discussion is a moot point though, I think, because f.e. Netatalk running on Linux can act as a bridge between TCP and AppleTalk AFP clients.
The good news is that the CLI client (afpcmd) works quite well which is handy in a pinch. But obviously most people want a nice GUI with drag'n'drop for file management, so it's not a mainstream solution.
The AppleTalk discussion is a moot point though, I think, because f.e. Netatalk running on Linux can act as a bridge between TCP and AppleTalk AFP clients.
Has Apple announced the removal date for the AFP client yet? I saw MacRumors and other news sites making assumptions, based on some warning messages you get recently when attempting to use AirPort and Time Capsule devices. But beyond the deprecation notice in the Sequoia 15.5 release notes, I haven't seen any hard evidence yet, per se.
This is totally just me coping though. I have a faint wish that Apple will just keep the good ol' "mount_afp" command around in macOS as an easter egg. How hard can it be for them?
You're right; there's no removal date specified. The support article for Sequoia 15.5 (https://support.apple.com/en-us/121011) has this wording:
More confirmation can be found in https://support.apple.com/en-us/102423, which says:
Using the phrase "a future version of macOS" doesn't guarantee that this removal occurs in macOS 27, it just checks the required box for that to happen. Note that AFP isn't only the mount_afp command -- you also need the kernel extension (afpfs.kext) which provides the necessary AFP filesystem support. They wouldn't be "removing" AFP if that was left in. I suspect that there is telemetry which will show whether a lot of Tahoe customers are still using AFP, and that would factor into the removal timeline.
More confirmation can be found in https://support.apple.com/en-us/102423, which says:
Using the phrase "a future version of macOS" doesn't guarantee that this removal occurs in macOS 27, it just checks the required box for that to happen. Note that AFP isn't only the mount_afp command -- you also need the kernel extension (afpfs.kext) which provides the necessary AFP filesystem support. They wouldn't be "removing" AFP if that was left in. I suspect that there is telemetry which will show whether a lot of Tahoe customers are still using AFP, and that would factor into the removal timeline.
Apple needs to fix longstanding issues with their SMB client before folks finally give up using AFP. Granted, most all of the commercial NAS solutions have dropped AFP (using Netatalk), but there are still plenty of Netatalk servers out there running side-by-side with Samba or some other solution. Apple's warning may apply to just Time Machine itself, and not the complete removal of the AFP client from the system and in Finder.
You are more optimistic than me. The removal is almost certainly being driven by security concerns over having code in the system which is using old algorithms and auth methods. The easiest path for them is just to remove that code and point to SMB as its replacement, rather than to justify the continued existence of AFP for connections to legacy systems.