Ryan Hates Samba

It's not exactly a secret that I'm not a fan of Microsoft. I've made a very successful career out of avoiding Microsoft software whenever and wherever possible. So the fact that Apple has inexplicably decided to sunset AFP (Apple Filing Protocol) in favor of SMB (Server Message Block, Microsoft's file sharing protocol) to put it bluntly - really pissed me off. I've been happily using NFS, AFP, FTP, SCP... pretty much damn near any other file sharing protocol that isn't SMB for about as long as I've been seriously working with computers. I can't say I'm surprised, the writing has been on the wall for a while now. Apple has been slowly moving towards deprecating, and eventually removing AFP altogether since Mac OS X Mavericks. After upgrading my MacBook to the macOS 26 Developer Beta, upon first boot I was greeted with the wonderful message that I could no longer make new Time Machine backups, and that in the next version of macOS, AFP would be officially removed. I've been putting it off for a while now, but Apple has officially forced my hand; I have to switch to SMB.

My gripes about SMB are mainly technical. If you're running a Windows based fileserver, setting up an SMB fileshare with domain level authentication is braindead simple. It's just a few clicks, a trained lab monkey could probably do it. However, I do not, nor would I ever even consider putting something as important as my NAS or TimeMachine backups on a Windows box. Comparatively, I've been running Netatalk (the open source implementation of AFP on Linux) - with domain level authentication - as my primary file sharing protocol (including with TimeMachine) for macOS clients - the only kind of computer I own outside my Openshift lab - flawlessly for years. It's been stable, reliable and performant, and it's mDNS (multicast DNS, aka; avahi/bonjour) magic helps it seamlessly integrate with macOS clients. The forced downgrade to SMB is a massive step backward in functionality, reliability and performance. Not only that, but it (samba) is incredibly complicated to set up; nigh impossible with domain level authentication, because... reasons?

I don't claim to be a storage or Kerberos/LDAP guru, nor would I want to be. I just need my files to be accessible over the network and I want to waste as little brain power on getting to that goal as humanly possible. Being forced to go from AFP, which consists of a single, simple, easy to understand config file to the complicated, convoluted mess that is Samba did not make me happy.

My first attempt at setting up Samba, I wanted to make it like for like with my currently working AFP setup. I wanted to just be able to use my domain credentials to mount shares and peform Time Machine backups, and I want my NAS to show up in Finder as a Mac Pro, not an ugly beige box PC stuck on the Windows BSOD.

One of the things I've always loved about macOS has been the extreme attention to detail and the beautiful design aesthetic of the UI. It's the little things, like devices identifying themselves as the actual model of hardware they are that really make macOS feel like a much more cohesive user experience in my opinion. However, I wasn't about to bend over backwards just to change what icon my NAS shows up as. At this point, I just needed to be able to continue using Time Machine and to access my files without the ticking AFP time bomb waiting to wreak havoc. Granted, we know that the next version of macOS is over a year away. If Apple sticks to their typical release cycle for macOS 27, it will likely go GA some time in September of 2026 so I've still got plenty of runway to get things figured out.

My first attempt at enabling SMB shares just using the ZFS cockpit plugin was an absolute failure. So much for ease of use... the problem - as it always is - with Samba is authentication. Trying to enable domain level authentication with Samba is infuriatingly complicated. Why they couldn't just allow Samba to leverage the built-in PAM system on Linux instead of having it handle it's own kerberos and LDAP nonsense is beyond me... Apparently, installing and configuring Winbind is a hard requirement for domain authentication using Samba, which immediately became a problem for me because I don't even have winbind installed. 100% of my Linux servers are domain joined using ipaclient. For quite literally every single other workload in my lab with the capability to do LDAP authentication - Linux itself, Gitea, Openshift, Ansible Automation Platform, Cockpit, OPNSense, etc. - I have this set up and working flawlessly, with a two way domain trust to my Active Directory environment no less. But Samba with domain authentication eludes me.

After spending several hours fighting with Samba trying to get it allow IDM users to mount shares using domain credentials, I ultimately just gave up on it. I would love to just be able to use the same credentials for everything (kind of the whole point of using a federated authentication solution like IDM or Active Directory) but at the end of the day, I am a pragmatist and right now I just need my fileshares and Time Machine to work. I threw in the towel on using domain credentials and fell back to the far simpler solution of using local accounts and allowing access via smbpasswd. Personally, I consider this a crappy workaround at best, and a dirty hack and potential security issue at worst. But for now, it's getting the job done.

In order to get Samba to play nice with macOS clients, you're going to have to add some 'cheat codes' to your smb.conf, none of which seem to be documented anywhere official, save for a scattering of blog and forum posts around various OSS communities (like ubuntuforums.org... gross).

Here's my current smb.conf for my NAS server hosting my TimeMachine backups:

[global]
  workgroup = CUDANET
  netbios name = stor02
  security = user

  log file = /var/log/samba/%m.log
  log level = 1

# Fruit global config
  fruit:aapl = yes
  fruit:nfs_aces = no
  fruit:copyfile = no
  fruit:model = MacPro5,1

# Permissions on new files and directories are inherited from parent directory
  inherit permissions = yes

# Samba will automatically "register" the presence of its server to the rest of the network using mDNS. Since we are using avahi for this we can disable mdns registration.
  multicast dns register = no

# Protocol versions
  client max protocol = default
  client min protocol = SMB2_02
  server max protocol = SMB3
  server min protocol = SMB2_02

[TimeMachine]
  # Load in modules (order is critical!)
  vfs objects = catia fruit streams_xattr
  fruit:time machine = yes
  fruit:time machine max size = 1024G
  comment = Time Machine Backup
  path = /pool0/timemachine
  available = yes
  browseable = yes
  guest ok = no
  writable = yes

# COCKPIT ZFS MANAGER
# WARNING: DO NOT EDIT, AUTO-GENERATED CONFIGURATION
  include = /etc/cockpit/zfs/shares.conf
  include = /run/cockpit/zfs/shares.conf

Of particular note, the entries under the [global] section

# Fruit global config
  fruit:aapl = yes
  fruit:nfs_aces = no
  fruit:copyfile = no
  fruit:model = MacPro5,1

and these under the [TimeMachine] share

  # Load in modules (order is critical!)
  vfs objects = catia fruit streams_xattr
  fruit:time machine = yes
  fruit:time machine max size = 1024G

are what is required to get macOS to work properly with your SMB share. The entry fruit:time machine = yes is required to make an SMB share recognized as a backup target for Time Machine. With these options set in my smb.conf, after a service restart

systemctl restart smb nmb

Time Machine can now see the share as a backup target and was able to pick up where it left off with the AFP share (both are pointed to the same ZFS dataset on my backup NAS).

Then I decided to try and tackle the aesthetic parts of this. As I pointed out, by default, any SMB share is going to use the ugly Windows BSOD icon. I'm just not into that, and I want my Mac Pro to show up as a Mac Pro (call me crazy). I still don't think I have this 100% right, but here is how I configured my SMB avahi service (/etc/avahi/services/smb.service)

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name replace-wildcards="yes">%h</name>
  <service>
    <type>_smb._tcp</type>
    <port>445</port>
  </service>
  <service>
    <type>_device-info._tcp</type>
    <port>0</port>
    <txt-record>model=MacPro5,1</txt-record>
  </service>
  <service>
    <type>_adisk._tcp</type>
    <txt-record>dk0=adVN=timemachine,adVF=0x82</txt-record>
    <txt-record>sys=waMa=0,adVF=0x100</txt-record>
  </service>
</service-group>

and now if I mount the share using ctl+k and specifying the server FQDN and share name, it now shows up as a Mac Pro. It would be nice if Avahi actually worked the way it's supposed (zero touch configuration and all that) but whatever... at least it's sort of working now.

All in all, I'm super not happy about the change. I'm sure eventually I'll get all the bugs worked out of it and move on with my life and stop being salty about it, but the deprecation and eventual removal of AFP from macOS seems like a major step in the wrong direction to me.

RANT.EXE /OFF 😤