MacOS 26.4 has broken TimeMachine backups to NAS.

Confirmed this ServerMarkers workaround also fixed Time Machine → Synology authentication on macOS Sequoia.

I hit essentially the same issue on a 2019 27-inch iMac running macOS Sequoia backing up via SMB to a new Synology NAS. (Time Machine failure with a red ‘i‘ that, when clicked, indicates an authentication error)

Time Machine repeatedly failed during “Connecting to backup” with the message that there was a problem with the network username or password.

Before applying the workaround, I verified:

• Finder could mount the Time Machine SMB share using the dedicated NAS Time Machine account.
• Synology Resource Monitor showed the Mac connected to the Time Machine share via SMB3 under the correct dedicated username.
• tmutil destinationinfo showed the correct username embedded in the SMB destination URL.
• /Library/Keychains/System.keychain contained the correct Time Machine Network Password entry.
• I verified that the password stored in that System keychain entry was actually correct.
• backupd nevertheless logged: Authentication error (80)

and:

BACKUP_FAILED_AUTHENTICATION_ERROR (29)

I then inspected:

/private/var/root/Library/Group Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist

The plist existed, but my Synology hostname was missing.

I added the NAS hostname in lowercase using the PlistBuddy command posted above:

sudo /usr/libexec/PlistBuddy -c 'Add :your-nas-hostname.local bool true' '/private/var/root/Library/Group Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist'

Then I rebooted the Mac.

That fixed it immediately. Time Machine progressed past “Connecting to backup,” completed the entire initial backup overnight, and this morning I manually triggered another backup of roughly 1 GB of changes, which also completed successfully.

So in my case this was definitely not an incorrect NAS username/password or Synology share-permission issue. The ServerMarkers workaround resolved the backupd authentication error.

Obviously substitute your own NAS hostname, and I would recommend inspecting/backing up the plist before modifying it.

Hopefully this helps anyone hitting the same misleading authentication error on Sequoia.

Thank you to all on here, especially Broeseli, for the help. I would have spent *much* more time on this without finding this. Oh, and ChatGPT helped a ton!

Justin Creveling wrote:

for anyone using TrueNAS Scale: update to at least 25.04. after editing plists and removing destinations and verifying passwords and verifying encryption keys and verifying i can connect to the server in finder etc. etc. etc., the only thing that i needed to do was update truenas to 25.04 from 24.10.

what complicated things for me and had me chasing my tail was that i moved my backup sparsebundle to a different truenas server, so i was also chasing red herrings with the file and permissions etc., in the end i had everything fine and the issue was the smb handshake between the new macos version of smb and the truenas version.

There is a Samba bug in this realm, fixed with Samba 4.22.7, though maybe not fixed in 4.23.* per the following:

https://bugzilla.samba.org/show_bug.cgi?id=15926

"I believe this is only fixed in the 4.22.x branch; it's still an issue with the latest 4.23 releases, including 4.23.5."

I have a UNAS PRO 4 that stopped backing up. My solution is as follows:

I just resolved this by deleting my backup instance in Time Machine Settings and then trashing this plist: /Library/Preferences/com.apple.TimeMachine.plist

I saw references to a machine that I no longer own and migrated from last year in that plist. The system recreated a fresh, clean file, and I was able to continue to back up my system by creating a new backup in TM Settings.

Dmitry Porotnikov has a nice writeup of this bug here: Time Machine backup failure to Linux/Samba target - Missing kown [SIC] server marker.

It explains a bit about what's going on and has a script to add the server markers, with before and after dumps (which you can/should run by hand to understand what's going on) of the plist.

The plist file is text and not binary on the macOS 26.6.2 box I've checked, which makes editing it directly with an editor such as nano an option.

# the command used to display the file contents (you'll need to enter an admin password for sudo):
sudo cat /private/var/root/Library/Group\ Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>_migrationVersion</key>
	<integer>3</integer>
	<key>host1.local</key>
	<true/>
	<key>host2.local</key>
	<true/>
	<key>host3.local</key>
	<true/>
	<key>host4.local</key>
	<true/>
	<key>host5.local</key>
	<true/>
</dict>
</plist>
#
# the following command can be used to edit the file using the pico text editor.
# Editing controls are displayed directly within the pico text editor.
# You will probably be mostly using the arrow keys and delete key and then ^X (control-X).
sudo pico /private/var/root/Library/Group\ Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist

You'll need to remove both the <key>[your local stuff here]</key> line and the following <true/> line.

The PListBuddy command will be something akin to the following, though I've minimally tested this, but wouldn't suggest it:

sudo /usr/libexec/PListBuddy -c 'Delete :your-nas-hostname.local bool true' /private/var/root/Library/Group\ Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist'

for anyone using TrueNAS Scale: update to at least 25.04. after editing plists and removing destinations and verifying passwords and verifying encryption keys and verifying i can connect to the server in finder etc. etc. etc., the only thing that i needed to do was update truenas to 25.04 from 24.10.

what complicated things for me and had me chasing my tail was that i moved my backup sparsebundle to a different truenas server, so i was also chasing red herrings with the file and permissions etc., in the end i had everything fine and the issue was the smb handshake between the new macos version of smb and the truenas version.

Hi!

Try this, you have to replace nas.localdomain with your local NAS name like synology.local or nas.local....:

sudo /usr/libexec/PlistBuddy -c 'Add :nas.localdomain bool true' '/private/var/root/Library/Group Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist'

After this, backups should run again...

Try my given Advice!

It will work!

You have to replace nas.localdomain with your local NAS name like synology.local or nas.local in the following command. All in small letters!

Run it in Terminal.

sudo /usr/libexec/PlistBuddy -c 'Add :nas.localdomain bool true' '/private/var/root/Library/Group Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist'

Broeseli, it needs to be

nas.local

otherwise it will not work!

Best,

Magnus

Mbosse wrote:

With what command would I remove a server from the serverMarkers.plist e.g. in case I change the Synology? Thanks!

The command was provided above — plistBuddy — though that tool is only installed with Xcode or with the command-line tools. To load the command line tools:

xcode-select --install

The command (which needs localization) is:

sudo /usr/libexec/PlistBuddy -c 'Add :your-nas-hostname.local bool true' '/private/var/root/Library/Group Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist'

I’m not in a position to check this plist and this command right now, but will look at this plist later today.

Make a copy of the plist before making changes.

Are y'all reporting this seeing any mDNS / Bonjour host names with (2) or (3) or other numeric suffixes?

For instance:

MrHoffman iMac (2).local

If you're seeing that, this could quite possibly be a network error or loop, and not a Time Machine error.

I have the same issue with backups on a Synology NAS. It was working fine in 26.3 and stopped working altogether, in 26.4.

• I checked and the connection is properly establishing in SMB3.
• I made sure there wasn't any non ASCI character anywhere (drive name, username, etc).
• Running this command while trying to backup:

log stream --level debug --predicate 'subsystem == "com.apple.TimeMachine"' --style compact &> ~/Desktop/tm_debug.log

confirms an authentication error but only as the Mac is attempting to back data up (everything is fine to add the destination, or if I attempt to connect through the Finder).

• I changed the username and password to make sure I didn't have any special character (no space, no $% or &).
• I wiped out the system and login keychains (which wasn't fun) to rule out any keychain corruption, password or certificate issue.
• I wiped out all Network-related preferences from /Library/Preferences
• I reset all SMB related configuration files.
• I reset my list of known hosts (which shouldn't affect SMB all that much, but just in case…)
• I attempted to connect to the drive either through Bonjour or directly by IP.
• I connected straight to the NAS by direct ethernet connection, bypassing my switch and router.

Nothing did it! It just keeps on failing to authenticate through Time Machine backups.

@Broeseli it did work (I ran the command and rebooted).

If I summarize and simplify what I read on other sites, the 26.4 update triggered a pre-existing bug in older versions of samba.

backupd, the Time Machine process runs as root, and could not see the credentials stored in the keychain. As a workaround, this command adds the server to the ServerMarker list to restores proper authentication.

I reported the issue to Synology though. They only run Samba 4.15.13 as of today and my understanding is that it's only addressed in a much older version

Nicholas Sayer wrote:

Now, I am really, really, REALLY, REALLY, sure that both the password to connect to the NAS and the password to unlock the (encrypted) volume are correct. I have deleted and recreated the TM connection in the TM control panel approximately 39,241 times and it doesn't help. And this same thing happens on 5 different macs connecting to two different Synology NASs all running the latest DSM.

Have you verified it by successfully mounting the volume on your Mac? Can you access the TM backups using the TM browser, or does that fail, too?

DSM configured as recommended by Synology? They modified that kbase article with some Tahoe-specific changes.