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.
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.
If you're using Synology, a couple years ago they finally published a help article that lists (IIRC) 3-5 settings important to switching from AFP to SMB. I had tried before that but to no avail.
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
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.
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.
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.
> 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.
I filed a radar while working there on a bug that was introduced in 2009 and it's still not fixed because it was low in the stack and the person responsible for it said they didn't think it was wise to make changes that late in the beta cycle (it was close to the annual release). It's never been fixed. I stopped checking major releases about five or six years ago.
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.
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).
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.
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.
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
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.
What I have done to maintain the integrity of my Time Machine backups (to UnRAID, via SMB):
For the "sparsebundles break" issue:
* Back up to multiple targets. I use both mbentley's Time Machine Docker image (only one backup per source machine) and UnRAID's built-in Time Machine functionality (multiple backups of same machine allowed).
* Use spaceinvader1's macinabox Docker image to have a local way to `fsck_apfs` the above sparsebundles.
* When one irreparably breaks, delete it and replace it with a copy of a working one from another of the above targets.
For the "backups are incredibly slow" issue:
* One of the above targets is to an SSD.
* Use TheTimeMachineMechanic's "Speed" option after a backup to determine the slow spots. Look at patterns in "Current:" lines. Pumping the output to an LLM is very helpful here.
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.
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.