AFP client for post macOS 15.5 macs

Slimes

Tinkerer
Jul 26, 2023
36
26
18
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?
 

thecloud

New Tinkerer
Oct 2, 2025
2
0
1
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.
 

Mk.558

Tinkerer
Nov 11, 2023
88
32
18
You're probably better off using a virtual machine like Basilisk II or QEMU. If you want EtherTalk, aka not-AFP over TCP, you'll have more work to do, because the kernel doesn't support AppleTalk.
 
  • Like
Reactions: thecloud

thecloud

New Tinkerer
Oct 2, 2025
2
0
1
You're probably better off using a virtual machine like Basilisk II or QEMU. If you want EtherTalk, aka not-AFP over TCP, you'll have more work to do, because the kernel doesn't support AppleTalk.
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.
 

rdmark

Moderator
Staff member
Oct 3, 2021
190
257
63
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.
 

rdmark

Moderator
Staff member
Oct 3, 2021
190
257
63
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.
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? ;)