4 ms·

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

GeekyBear 5mo 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 5mo 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 5mo 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 5mo 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 5mo 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 5mo ago
        Apple was still using Kerberos when I was there not that long ago.
        ninkendo 5mo 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 5mo 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 5mo ago
      What's the panic?
    - donavanm 5mo 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 5mo ago
  [deleted]

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 5mo 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 5mo 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 5mo 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 5mo 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 5mo ago
      Apple was still using Kerberos when I was there not that long ago.
      - ninkendo 5mo 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 5mo 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 5mo ago
    What's the panic?
  - donavanm 5mo 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 5mo ago
[deleted]