upvote
I still use AFP on my NAS for a few reasons:

1. When I benchmarked it, AFP was significantly faster than SMB. Both with SMB2 and SMB3. Even when transport encryption was turned off.

2. On SMB2+, symlinks created by the client are not real symlinks. They're "Minshall+French" links which only look like symlinks to other SMB2+ clients. To the server and NFS mounts they look like flat files with the target path encoded in them.

3. It exposes a different precision for certain timestamps. Software that uses this metadata to decide whether a file needs to be updated will see almost every file as needing a resync.

It's been a year or two since I checked the status of these. The situation may have improved since last I looked.

reply
Yeah I recently migrated my NAS and took the opportunity to switch from AFP to SMB for my Time Machine backups. There were so many problems like the ones you describe that I gave up and went back to AFP. Looks like I'm going to be forced to spend a weekend with Claude figuring this out.
reply
I gave up on timecapsule because performance has gotten worse and worse year over year. I replaced it with a periodic rsync backup to a NAS that is in turn backed up in other ways

The upside is that it's dead simple when it comes to how the backup is stored. In 10 years time, having files in a filesystem will still work, but I imagine restoring an old time machine backup will require quite a bit of work

If you wanted to you could probably figure out how to do apfs snapshots before rsyncing

If you exclude pointless stuff like browser caches it's also pretty performant compared to timecapsule, and the transfer is properly encrypted

reply
They discontinued sales in 2018, but continued to support Time Capsule backup over AFP through macOS 26 (Tahoe).
reply
It's been more than a decade since they replaced AFP with SMB as the default protocol for file sharing, and they've been warning that AFP would be going away for years.
reply
Yeah but AFP is still performing way better than SMB on Mac for any fast networking. Like 10GigE and faster. Apple SMB stack is a disaster, and thoroughly unprofessional. NFS is faster, too, but unfortunately the Finder, being the rat nest of bugs it is, has often trouble with NFS shares.
reply
macOS 26 still has a hard kernel panic if you try to mount an NFS share with krb5 auth but don’t have a valid Kerberos ticket. 100% reproducible.

Every OS update I try mounting with no ticket, get a panic, fill in the error reporting dialog with a nice “hope you had a nice holiday break!” message or whatever is seasonally appropriate, with the same simple steps to reproduce. It’s just kinda comical at this point.

My guess is kerberized NFS has absolutely zero users within Apple, and it’s likely hard to find an engineer there who even knows what Kerberos is anymore.

I used to work at Apple and I’d have filed a radar for it but now I’m just a customer so I’m powerless.

reply
Hah. I actually had opendirectory, OSX clients, and CentOS/RedHat clients running krb5 NFS off of netapp filers circa … 2008? Lots and lots of NFS in the (mansfield) hardware org at that time. I think krb on osx started getting hard around 2010 when they moved tickets and other credentials to a process aware in memory store. Became difficult to use TGT or machine identity for automation.

And yes, Im sure theres a very lonely radar bug for this. But even MM of revenue wont fix “edge cases” like this.

reply
What's the panic?
reply
It's been a while since I worked at Apple, but back in the day the entire OS X Server team made extensive use of kerberized NFS shares for moving around large files...

...the last version of Server shipped in 2021 (and the last real version shipped almost a decade before that).

reply
Apple was still using Kerberos when I was there not that long ago.
reply
Hmm, the more I think about I think you’re right, they likely still do use kerberized nfs, but I think the auth layer they use is… different. Without giving too much away, the internal SSO software ends up either wrapping or providing Kerberos tickets in some way, so I’m imagining that code path doesn’t panic.

In fact that’s probably the clue… everyone internally at Apple using krb5 auth with nfs is probably using the internal SSO software and the code path for “vanilla” Kerberos (ie. Ticket Viewer.app and so on) has zero testing. Maybe I’ll write that into the next crash tracer report I type up :-D

reply
IIRC I had some really nasty move/duplication issues with NFS the last time I tried it in Finder.app. (and the whole UID mess)
reply
deleted
reply
Have they, by chance, also fixed the issue where MacOs' SMB implementation is unusably slow when copying many small files?

A backup of my 2TB MacBook literally takes weeks.

reply
Did they ever work? No, seriously. I've had a couple of them and the few times I really could have used them I discovered that they represented the worst backup solution I've ever had the misfortune to deal with. Slow, very hard to use beyond their primary integration with the OS (which isn't good to begin with), there's really no good way to keep an eye on how they are doing (what's actually backed up, if it is still there) and the performance is worse than any hand rolled solution I've ever used.

They never supported it properly in the first place and then it just meh'ed out of existence.

I hope "the new Apple" is going to take software seriously.

reply
Time Machine support is also dropping support over SMB1 so whatever new solution needs to support SMB2/3.
reply
SMB2 came out with Vista and SMB3 was Win8 so they are not new protocols either.
reply
That just ended up inadvertently reminding me, Windows Vista is actually almost old enough to be at the minimum legal drinking age in the US.

Windows 8 is nearly a decade and a half old as well.

Time really does fly.

reply
Where "new" in this case could be a NAS running Samba from 2011? Samba added official support for Time Machine much later, but I think it was possible on earlier versions with some extra steps.
reply
reply
That's when Samba gained official easy to use support for being used with Time Machine. I'm pretty sure it was possible long before then, IIRC by changing a setting on the Mac to allow selecting unsupported network volumes.

I don't recall when I stopped running netatalk on my NAS and switched to pure Samba, but I think it was before 2018.

reply
I only meant new as in someone currently owns a Time Capsule and has to replace it with something "new" that supports newer SMB versions.
reply
I've added support for Samba 4 (running SMB3) to the Time Capsule so it can work with modern macOS: https://github.com/jamesyc/TimeCapsuleSMB
reply
SMB1 has major security issues but even those ignored (which a lot of people on private home networks shouldn't be too worried about) it's also slow as hell on MacOS
reply
> people on private home networks shouldn't be too worried about

philosophically I would beg to differ about any premise assuming we can trust the castle and moat model. Even on home networks.

reply
philosophically, it depends on who you are. If you're Sam Altman or Vitalik Buterin, yeah, your private home network should be considered to be under attack by hostiles trying to steal from you, but for the rest of us, the NSA isn't going to make an international incident trying to get at your Plex server.
reply
For the rest of us we have IoT devices and guests malware filled devices constantly probing the internal network.
reply