Moving Time Capsule backups to SMB on macOS 27

The Macs on my network used a 4th-generation AirPort Time Capsule as the destination for automatic Time Machine backups. After the upgrade to macOS 27.0, those backups stopped working. Apple’s support article states that AFP-based Time Capsule backups are not supported on macOS 27 or later. As rechecked on October 4, 2026, the article is dated September 14, 2026.

To keep using the device, I chose TimeCapsuleSMB. It is an unofficial tool that runs Samba 4 inside the device so that backups go over SMB3. On September 14, 2026, I confirmed that a first Time Machine backup finished from a Mac mini on macOS 27. Below, what I ran myself and what I only read in documentation are kept apart.

What went away is the AFP client

The stock server on a Time Capsule offers AFP and SMB1. The TimeCapsuleSMB README and an article from The Eclectic Light Company describe it this way. In macOS 27.0 the AFP client is gone, and mount_smbfs remains.

There was advance notice. The enterprise release notes for macOS Sequoia 15.5 announced that the AFP client would be removed in the future. The support article says backups to an AFP NAS are not recommended and are not supported on macOS 27 or later, and it applies the same condition to AirPort Extreme and Time Capsule. Earlier, the macOS Sequoia 15 release notes recorded a fix for a failure to create a new encrypted backup on a Time Capsule or AFP server.

A MacRumors article explains the cause with TLS 1.2, but that is a different matter. The minimum TLS requirement in the macOS 27 Golden Gate release notes covers some processes related to device management, automated device enrollment, installing configuration profiles and apps, and software update. Time Machine is not among them. The same release notes have no item about removing AFP either. So the conclusion that AFP is gone rests on the support article and on the fact that the files are missing in macOS 27.0.

This is the result of trying an AFP mount on macOS 27.0. I used an address that does not exist, and only the directory path is replaced with <dir>.

$ mount -t afp //example.invalid/share <dir>
mount: exec /Library/Filesystems/afp.fs/Contents/Resources/mount_afp for <dir>: No such file or directory
mount: <dir> failed with 72

The command ends before it even resolves the name, because the helper file is missing. /sbin/mount_afp does not exist, there is no AFP bundle in /System/Library/Filesystems, and the network file system plug-ins have no AFP entry. On the other hand, the setdestination section of man tmutil still mentions AFP and SMB shares. Wording in a manual page is not evidence that AFP works.

AirPort Utility changed as well. A fresh install of macOS 27 does not include it. After an upgrade the existing app can remain, but it is not guaranteed to work from 27 on. My Mac was updated from macOS 26.6.2, and AirPort Utility 6.3.9 was still there.

The available paths

The replacements Apple lists are an external storage device, a NAS that supports Time Machine, and a shared folder on another Mac.

A directly attached external drive: the configuration Apple commonly gives. A network outage does not matter, but a laptop backs up only while the drive is plugged in.
A NAS with SMB: several Macs can back up to one place. The device costs money.
A shared folder on another Mac: it uses a Mac that is already there. Apple recommends that both Macs run macOS 11 or later.
Staying on macOS 26: AFP keeps working for a while. It is hard to keep going once security updates end.
TimeCapsuleSMB: it keeps the device in use and leaves room to carry over old backups. The cost is accepting an unofficial tool running as root on the device.

I took the last path. I installed with the default settings first, then examined the binaries and the issues, and changed the settings and deployed again based on what I found. The security section below is what I learned after installing, but it belongs before installation, so I put it first.

What Time Machine needs from an SMB server

For Time Machine to use an SMB share as a backup destination, the server has to support Apple-specific features. In Samba, the vfs_fruit module does this.

This share definition comes from Samba’s public test configuration. Nothing in it is edited during installation. The excerpt only shows which options are needed.

[vfs_fruit_timemachine]
	vfs objects = fruit streams_xattr acl_xattr xattr_tdb
	fruit:time machine = yes

A share with fruit:time machine = yes is advertised over Bonjour as _adisk._tcp. The registration is in Samba’s Avahi registration code. vfs_fruit negotiates the AAPL extension of SMB2 and handles Finder metadata. The extension needs SMB2 or later, so the SMB1 of the stock server cannot meet the condition.

What TimeCapsuleSMB does on the device

The v2.2.9 I installed runs Samba 4.24.3 and accepts connections over SMB3. A separate mDNS helper advertises _smb._tcp and _adisk._tcp. By default only SMB2 and SMB3 are allowed, and turning on Allow Any SMB Protocol lifts that limit.

The installed files are split across two storage areas. /mnt/Flash is small but survives a reboot, so the boot script, the configuration, and the small mDNS helper go there. The large Samba binaries live in .samba4 on the hard disk. Every time the device starts, they are copied to the /mnt/Memory RAM disk and run from there. The Apple firmware spins down an idle hard disk, so they cannot run directly from the disk.

During installation, the app first turns on SSH on the device and sends the files through it. Data that was already on the disk is not touched. The uninstall feature removes the files on the hard disk and the loader in /mnt/Flash. Deleting the installed files and restoring the boot hook are two different jobs, which is worth knowing. The command that returns the firmware to stock is flash --restore.

The binaries differ by generation. The 5th generation is NetBSD 6, and generations 1 to 4 are NetBSD 4. My 4th-generation device got the build for NetBSD 4.0 little-endian.

Security conditions to know before installing

The first thing to know about is the heartbeat. The nbns-advertiser in v2.2.9 contains a heartbeat feature. It downloads heartbeat4le and a signature file over HTTP, verifies them, and runs the result. The address found in the strings of the binary is http://timecapsulesmb.jamesyc.com/downloads/bin/heartbeat4le. The source of this feature is not in the v2.2.9 tag.

Issue 299 reports that this feature runs every 12 hours with root privileges and sends device information. The maintainer answered that it is telemetry, that it can be turned off with a setting, and that the structure was changed in v3.0.0. On September 14, 2026, when I installed it, v3.0.0 had not been released. Looking at the release list again on October 4, 2026, v3.0.0 was published on September 15 (UTC), and the latest release is v3.2.0. I have not installed the v3 line, so the installation and telemetry details in this post are based on v2.2.9. Signature verification keeps an arbitrary file from being run, but what gets run depends on the maintainer’s server and signing key.

I also checked how far the telemetry setting reaches. The app and the CLI write TELEMETRY=false to .bootstrap on the Mac, and that stops the usage events sent from the Mac. But in the deployed code and binary strings of v2.2.9, this value is not passed into the device’s configuration. Which setting issue 299 refers to is not clear.

The way to stop the heartbeat on the device is to turn NBNS off. nbns-advertiser is always placed in .samba4 on the hard disk, but it is copied to the RAM disk and run only when NBNS_ENABLED=1. In the app, turning off Enable NBNS and running Install/Update again deploys NBNS_ENABLED=0. In the CLI it is deploy --no-nbns. The basis for this conclusion is the boot code and the strings in the binary. I did not verify with packets that the network requests actually stopped.

With NBNS off, NetBIOS name responses stop, so the device can drop out of discovery on Windows. Macs find it through Bonjour and do not strictly need NBNS, and my device worked normally after the redeploy.

The remaining conditions are these.

Bind SMB to LAN Only is off by default. When it is off, the server can bind to every interface including WAN, and when it is on, it is limited to the LAN. If the device also acts as the router, turning it on is the safe choice.
SMB authentication accepts any user name and uses the device password of the Time Capsule. Guests are blocked, and an authenticated user is mapped to root.
The README says to use it only on the LAN and not to open ports to the internet. The FAQ says it can be used on a home network and should be avoided in security-sensitive environments.
The first launch of the app needs the Gatekeeper warning to be allowed by hand. Issue 284 includes a case where the maintainer provided an unpublished build through an external share link. Getting the app from an official release is the better choice.

The steps I followed with the app

I installed with the app, not the CLI. The steps were as follows.

Download the app from the GitHub releases. After unpacking and opening it, Gatekeeper blocks it, and it runs only after it is allowed by hand.
Give the app the local network permission. It is under “Privacy & Security” in System Settings, and the app has to be quit and reopened after the permission is given.
In Add Device, pick the device, enter the device password, and save it with Save Device. The app then turns on SSH, and I waited for that to finish.
Change three settings: Mac telemetry off, Enable NBNS off, and Bind SMB to LAN Only on.
Press Install/Update. The NBNS and LAN settings go to the device at this step.
For generations 1 to 4, write the boot hook.
Run Checkup after 5 to 10 minutes.

On the 4th-generation device, the deploy took about 6 minutes. The checks that the device rebooted and that the runtime was activated succeeded, and Checkup showed 0 failures and 0 warnings.

The README also describes what to do on failure. If the SSH step is stuck, restart the app and register the device again, or reboot the device itself. If the deploy step is stuck, delete the device entry saved in the app, register it again, and run the deploy once more. In some cases one deploy does not transfer every file, and it has to be repeated several times.

The boot hook on generations 1 to 4

The NetBSD 4 firmware on generations 1 to 4 cannot keep a boot hook. Without a patch, tcapsule activate has to be run after every reboot. In the app, the Persistent NetBSD4 Boot Hook menu runs Back Up and Inspect, Plan Patch, and Write Patch in that order.

The firmware on my device is 7.8.1. Both banks were backed up to the Mac, and an image built from 7.8.1 in Apple’s catalog was written only to the primary bank. The secondary bank is still the original. The check that reads the bank back after writing and compares it also passed. The reboot command is not available in patch mode, so I unplugged the power cord and plugged it back in, and after that Samba started without activate.

Writing to flash carries risk. The v2.2.9 FAQ warns that losing power during the write can leave the device unusable. The v2.2.9 README says tcapsule flash --restore returns the chosen bank to stock, but I did not test a restore. According to the README and the FAQ, the 5th generation needs no boot hook, starts Samba automatically after a reboot, and reboots once during the deploy. I did not test the 5th generation either.

Installing with the CLI

I did not run the CLI. The order in the README, with the option that turns NBNS off added, looks like this.

./tcapsule bootstrap
.venv/bin/tcapsule configure
.venv/bin/tcapsule deploy --no-nbns
.venv/bin/tcapsule doctor

bootstrap creates a Python virtual environment inside the repository, and configure writes the address and password to a configuration file. deploy --no-nbns deploys with NBNS off, and doctor checks the state. On generations 1 to 4, after deploy, flash makes a backup and flash --patch writes the boot hook.

The documented requirements are macOS 14 or later, Python 3.9 or later, Homebrew, and smbclient. If the target is a NetBSD 4 device, sshpass is needed as well.

Reusing existing backups

This section summarizes the FAQ on main. The baseline is commit 34c075f on September 14, 2026, and I did not move a backup myself. Installation does not delete the disk or an existing .sparsebundle.

First check that the SMB connection works.
Put the .sparsebundle at the root of the SMB share. With standard internal-disk settings, this is the ShareRoot folder. A bundle inside a per-user folder is moved to the same place.
Set the Time Machine destination to the SMB share again.
When Time Machine offers to continue with the earlier backup, accept it.

If the earlier bundle is not found or cannot be reused, Time Machine may create a new bundle. When macOS still cannot find the existing backup after the move, the remedy the FAQ gives is a reboot. With the backup not mounted, reboot the Time Capsule first and then the Mac.

What I verified

This is the environment I verified. The Mac used for installation runs macOS 27.0, and the Mac that backed up is a Mac mini on macOS 27. The device is a 4th-generation AirPort Time Capsule with firmware 7.8.1 and NetBSD 4.0. The app is 2.2.9, Samba is 4.24.3, and the date is September 14, 2026. On the Mac mini I set the SMB share as the backup destination, and the first Time Machine backup finished.

A few commands help when checking the state. This one finds devices that advertise an SMB service over Bonjour.

dns-sd -B _smb._tcp local.

This one finds devices that advertise a Time Machine backup service. The two commands are run separately, and since the output keeps going, each is stopped with Control-C.

dns-sd -B _adisk._tcp local.

This one lists the backup destinations registered on the Mac.

tmutil destinationinfo

The first command shows the SMB device name, and the second shows the device name of the backup disk. Seeing the advertisement does not mean that authentication and writing work. According to the documentation, doctor checks the Samba processes, port 445, the Bonjour advertisement, the authenticated share list, and file operations inside the share.

What to watch while it stays in use

Keeping the app or the CLI folder after installation is the better choice. Running Checkup, deploying again, activate, and uninstalling all need that tool. The FAQ explains that the CLI folder can be deleted, but that it has to be kept or downloaded again to run maintenance commands. To move to a new version, do not uninstall first. Deploy once more on top of the existing installation. After that, check that the NBNS setting, the LAN setting, and the telemetry structure are unchanged, and finish with Checkup. Generations 1 to 4 without the boot hook need activate after a reboot.

Changes on the OS side matter too. The FAQ records a regression of Time Machine network backups in macOS 26.4.x and 15.7.5 through 15.7.7. After an OS update, it is worth confirming that the first backup finishes.

There are also cases in the issues. Issue 294 is about SMB stalling during a backup. It reports that wired connections or a newer external access point were more stable than the built-in Wi-Fi, but the cause is not settled. In issue 271, the maintainer judged the cause to be instability in Samba and the network. Issue 177 is a case where the device was factory reset during the first deploy. The data on the disk remains, but the network has to be set up again with AirPort Utility, and on macOS 27 that app is not guaranteed to work. For that reason, write down the device’s settings before installing.

I also read the main branch, which was still unreleased when I installed. In commit 34c075f from September 14, 2026 and the native helper README, the heartbeat is split out into a telemetry helper, which downloads and runs a signed debug executable when the server tells it to. This is code before release, and I did not confirm how it behaves, so the release notes and the FAQ should be read again before updating.

This setup puts an unofficial project on a device that Apple no longer supports. Important backups are better kept in one more place, on an external drive or an SMB NAS.

What I did not verify myself is the CLI installation, the restore to stock firmware, and the move of existing backups. I did not test a 5th-generation device, an AirPort Extreme, or an external disk attached to the device either. I did not test accessing files over the stock SMB1 on macOS 27 either. This post is about the Time Machine problem. I did not confirm with a packet capture that the heartbeat stopped either.