6 ms·

Time Capsule has been unsupported since 2018 (last shipped 2013): * https://en.wikipedia.org/wiki/AirPort_Time_Capsule https://en.wikipedia.org/wiki/AirPort_Ti

Time Capsule has been unsupported since 2018 (last shipped 2013): * https://en.wikipedia.org/wiki/AirPort_Time_Capsule 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.

TimTheTinker 6mo ago
They discontinued sales in 2018, but continued to support Time Capsule backup over AFP through macOS 26 (Tahoe).
- GeekyBear 6mo ago
  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.
  - wazoox 6mo ago
    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.
    - NegativeLatency 6mo ago
      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)
    - ninkendo 6mo ago
      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.
      - jballanc 6mo ago
        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).
        saagarjha 6mo ago
        Apple was still using Kerberos when I was there not that long ago.
        ninkendo 6mo ago
        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
        e28eta 6mo ago
        If you want a slightly different black hole to send your report to, you could use Feedback Assistant: https://developer.apple.com/feedback-assistant/ https://developer.apple.com/feedback-assistant/
      - saagarjha 6mo ago
        What's the panic?
      - donavanm 6mo 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.
  - deleted 6mo ago
    [deleted]
giantrobot 6mo ago
Time Machine support is also dropping support over SMB1 so whatever new solution needs to support SMB2/3.
- stackskipton 6mo ago
  SMB2 came out with Vista and SMB3 was Win8 so they are not new protocols either.
  - winocm 6mo ago
    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.
- wtallis 6mo ago
  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.
  - throw0101c 6mo ago
    Samba 4.8 from 2018: * https://www.samba.org/samba/history/samba-4.8.0.html https://www.samba.org/samba/history/samba-4.8.0.html ("vfs_fruit") * https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X https://wiki.samba.org/index.php/Configure_Samba_to_Work_Bet...
    - wtallis 6mo ago
      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.
  - 6mo ago
runlevel1 6mo ago
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.
- adastra22 6mo ago
  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.
  - tedd4u 6mo ago
    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.
    - adastra22 5mo ago
      Thanks. I have my own hand-rolled solution on my Ubuntu-based homelab server. Using netatalk, I think?
bborud 6mo ago
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.
- sersi 6mo ago
  I just wish the new CEO decides to do a snow leopard release. Also change the macos release to when it's done instead of yearly
procaryote 6mo ago
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
SebastianKra 6mo ago
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.
- TMWNN 6mo ago
  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.

TimTheTinker 6mo ago

They discontinued sales in 2018, but continued to support Time Capsule backup over AFP through macOS 26 (Tahoe).

GeekyBear 6mo ago
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.
- wazoox 6mo ago
  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.
  - NegativeLatency 6mo ago
    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)
  - ninkendo 6mo ago
    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.
    - jballanc 6mo ago
      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).
      - saagarjha 6mo ago
        Apple was still using Kerberos when I was there not that long ago.
        ninkendo 6mo ago
        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
        e28eta 6mo ago
        If you want a slightly different black hole to send your report to, you could use Feedback Assistant: https://developer.apple.com/feedback-assistant/ https://developer.apple.com/feedback-assistant/
    - saagarjha 6mo ago
      What's the panic?
    - donavanm 6mo 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.
- deleted 6mo ago
  [deleted]

giantrobot 6mo ago

Time Machine support is also dropping support over SMB1 so whatever new solution needs to support SMB2/3.

stackskipton 6mo ago
SMB2 came out with Vista and SMB3 was Win8 so they are not new protocols either.
- winocm 6mo ago
  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.
wtallis 6mo ago
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.
- throw0101c 6mo ago
  Samba 4.8 from 2018: * https://www.samba.org/samba/history/samba-4.8.0.html https://www.samba.org/samba/history/samba-4.8.0.html ("vfs_fruit") * https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X https://wiki.samba.org/index.php/Configure_Samba_to_Work_Bet...
  - wtallis 6mo ago
    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.
- 6mo ago

runlevel1 6mo ago

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.

adastra22 6mo ago
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.
- tedd4u 6mo ago
  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.
  - adastra22 5mo ago
    Thanks. I have my own hand-rolled solution on my Ubuntu-based homelab server. Using netatalk, I think?

bborud 6mo ago

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.

sersi 6mo ago
I just wish the new CEO decides to do a snow leopard release. Also change the macos release to when it's done instead of yearly

procaryote 6mo ago

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

SebastianKra 6mo ago

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.

TMWNN 6mo ago
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.