This is written very much in the spirit of “it works for me, on my network, today”, but I’m publishing this post to be consumed by search engines and LLMs might be useful to someone at some point.

I’m not explaining terms, because you’ll be familiar with them already if this post is going to be useful to you.

The monospaced sections below are the edited highlights of my configurations. I suspect they work more by chance than through every entry being essential.

You can configure a Samba server, running from a Linux system ( Debian bookworm in my case ), so that a macOS system will put your Time Machine backups on its shares. This is how I’ve done it, it took me far too long.

Running two Samba servers off the same system

This should work, and is the ideal solution. If you’re running a Samba server already and now want to backup Time Machine to it, it’s unlikely that you’ll be able to use your existing server. In that situation I’d expect that the easiest solution is to run a second Samba server from the same system, but configured especially to be macOS friendly, and with different shares configured.

This is a summary of what options you should use in your second smb.conf file, if only to give you options to look up:

netbios name = <something different to your main server>

interfaces = <IP address or interface name>
bind interfaces only = yes
socket address = <IP address of the interface for this server>

pid directory = <avoid using the default for the configuration of either samba server>
lock directory = <avoid using the default for the configuration of either samba server>
private directory = <avoid using the default for the configuration of either samba server>
state directory = <avoid using the default for the configuration of either samba server>
cache directory = <avoid using the default for the configuration of either samba server>

fruit:aapl = yes
fruit:advertise_fullsync = true
fruit:metadata = stream
fruit:veto_appledouble = no
fruit:nfs_aces = no
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes

See this page for overall advice.

Also note, modify your original smb.conf file with most of these options too, to ensure that the two smbd’s are using a completely separate set of files.

I tried this, and just couldn’t get it to work. Troubleshooting was a bit kludgey, but I ended up running ss -tupln | grep smb to get the PIDs of the two smbd processes, and then comparing the output of ls -l /proc/<PID>/ifd/* to see what files and resources they were using, and whether any of them were shared.

You’ll need to set up a second systemd file to call a second smb.conf file to run your second Samba instance.

Also Avahi will need configuring, try this website for ideas on how to make that work.

Of course the second Samba server will be on the same network, including IP network, as the first - which for me seemed to lead to all sorts of problems. I had two Samba servers, with two different IP addresses, on two different physical interfaces - and still, when queried on either IP, they would still answer with the configuration of whichever server I started last.

Linux’s Arp flux issue might be the cause here… I ended up trying to restrict certain MAC addresses to certain switch ports and all sorts, which was both unsuccessful, and trying too hard.

These sysctl options listed below should stop that happening, but they didn’t work for me; and even though I like to fix a problem beyond sensible boundaries of effort, once you’re fighting this far down the TCP/IP stack, it’s probably time to stop.

# sysctl -w net.ipv4.conf.all.arp_ignore=1
# sysctl -w net.ipv4.conf.all.arp_announce=2

Configuring a dedicated samba server

So, running a separate Samba server on a separate virtual system, this appears to work for me. I’ve included the edited highlights of my working configuration below.

I’m pretty sure I need to work through these options and check them, but if you’re working on this kind of problem I would assume that you’ll do the same. But what’s listed here, and also what’s omitted, should get you close to a solution. Do note that some of the “fruit:” options in Samba have changed relatively recently, compared to online guides, or what LLMs might tell you.

Also keep in mind tail -F /var/log/samba/log* to watch for specific errors. And that, in my limited experience, the output of testparm -s is pretty useless, you’re better off running the configured service and watching the logs.

smb.conf:

[global]
host msdfs = no
mdns name = mdns
multicast dns register = yes
name resolve order = bcast host lmhosts wins
Whole set of options to make the time machine share work
fruit:aapl = yes
fruit:advertise_fullsync = true
fruit:metadata = stream
fruit:veto_appledouble = no
fruit:nfs_aces = no
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes
map to guest = Bad Password
guest account = <account with permission to write to the share on the server>
guest ok = yes

[share-name]
   path = <directory you're sharing, double check its permissions>
   public = yes
   browseable = yes
   writeable = yes
   fruit:time machine = yes
   vfs objects = catia fruit streams_xattr 
   create mask = 0600
   directory mask = 0700
   force group = <local user with access to path>
   force user = <local user with access to path>
   valid users = <local user with access to path>

avahi-daemon.conf

[server]
host-name=<same as netbios name>
domain-name=local
use-ipv4=yes
use-ipv6=no

[wide-area]
enable-wide-area=yes

[publish]
publish-addresses=yes
publish-hinfo=no
publish-workstation=no
publish-domain=yes

timemachine.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>
<host-name><your netbios name goes here>.local</host-name>
<txt-record>model=RackMac</txt-record>
</service>
<service>
<type>_adisk._tcp</type>
<txt-record>dk0=adVN=smbTimeMachine,adVF=0x82</txt-record>
<txt-record>sys=adVF=0x100</txt-record>
</service>
</service-group>

From reading around the issue, it does seem that sometimes Samba’s configuration options just change, rendering old working configurations incorrect. Be mindful of that if you get this working, and then it mysteriously breaks.