Time Capsule has been unsupported since 2018 (last shipped 2013):
* https://en.wikipedia.org/wiki/AirPort_Time_Capsule
I think there's some population of folks that have been doing NAS TM backups over AFP, and they'll now have to switch to SMB.
* https://en.wikipedia.org/wiki/AirPort_Time_Capsule
I think there's some population of folks that have been doing NAS TM backups over AFP, and they'll now have to switch to SMB.
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.
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
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 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.
And yes, Im sure theres a very lonely radar bug for this. But even MM of revenue wont fix “edge cases” like this.
Small world!
...the last version of Server shipped in 2021 (and the last real version shipped almost a decade before that).
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
Windows 8 is nearly a decade and a half old as well.
Time really does fly.
* https://www.samba.org/samba/history/samba-4.8.0.html ("vfs_fruit")
* https://wiki.samba.org/index.php/Configure_Samba_to_Work_Bet...
I don't recall when I stopped running netatalk on my NAS and switched to pure Samba, but I think it was before 2018.
philosophically I would beg to differ about any premise assuming we can trust the castle and moat model. Even on home networks.
A backup of my 2TB MacBook literally takes weeks.
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.
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.