Time Machine not backing up to network

Time Machine is getting as far as creating the .incomplete sparsebundle but can’t finish the rename/commit step because the Samba share is either blocking the metadata/ACL/xattr operations TM requires or the underlying filesystem/permissions don’t actually support the POSIX semantics macOS expects.

Quick checklist to debug and fix: run testparm -s (you already did) and inspect /var/log/samba for permission errors, confirm vfs objects = catia fruit streams_xattr is active on the timemachine share (not just global), and that fruit:time machine = yes is set there; verify the backing filesystem on the Pi actually supports extended attributes and POSIX rename/flush (NTFS/exFAT via FUSE often fails for TM) and that /mnt/lotsadisk/backups is owned/mapped to the force user you set; from the Mac, try creating/renaming/deleting files in the share with Finder and with smbclient to reproduce the permission error, remove any partial *.incomplete sparsebundles, then remove and re-add the destination in Time Machine prefs, if problems persist, enable verbose Samba logging and post the Samba error lines or consider using a True APFS/SMB Time Machine target (a NAS with validated TM support) or attach the drive directly to the Mac

Right, APFS isn’t used on the NAS itself, but macOS does expect the backend filesystem to support all the xattrs and POSIX rename semantics that Time Machine relies on. That’s why drives formatted as exFAT or NTFS behind Samba often break TM, even if SMB is configured correctly. The issue in the OP’s logs is the sparsebundle failing the final rename step, which almost always comes down to the underlying filesystem or Samba’s xattr handling, not Time Machine itself. Using a native Linux FS like ext4/btrfs/ZFS with fruit + streams_xattr usually fixes it.

I still managed to start the Time Machine backup without permission errors; the problem is probably related to the fact that

“Samba 4.22 has removed the posix rename feature from the vfs_fruit module. According to the Samba Wiki, this feature is essential for Time Machine support.”

https://wiki.samba.org/index.php/Samba_4.22_Features_added/changed#fruit:posix_rename

So I reinstalled my Raspberry Pi but downgraded to Debian 12 Bookworm instead of Trixie, and installed OpenMediaVault for a simpler setup — and the issue is gone.

It's worth checking your Samba version on your NAS/Pi/Whatever network device. Hit - "dpkg -l |grep -i samba" to see the package version.

My backups started to fail a few days ago and I've dived down a bit of a rabbithole. What I've eventually found -

In Samba 4.22.x they removed the fruit:posix_rename flag. This was allowing a directory to be renamed while files inside it were still open, something Time Machine seems to need.

https://wiki.samba.org/index.php/Samba_4.22_Features_added/changed

Which means that samba 4.22.x *cannot* work as a Time Machine target.

They fixed it in 4.23.3 -

https://wiki.samba.org/index.php/Samba_4.23_Features_added/changed

But it may require config changes to get going again (I'm unsure at this point, I haven't yet managed to install 4.23.3 on my ubuntu server)

Minor update - I couldn't find an ubuntu pre-built samba 4.23.3, so I manually downgraded to samba 4.21 and everything is happy again.

Since I have been using a Raspberry Pi for TM for only a couple of months I have only a few comments. Perhaps you may be able to find something relevant.

You wrote that your smb.conf is pretty stock but there are potentially significant differences from mine. The RPi I am using started its life with the latest RPi image (whatever it was a month or two ago) and has had very few modifications. It's been up and running nonstop for a little over a month with zero modifications, nor do I intend to make any. I might not even update it, unless I can find a compelling justification. No failures to back up or restore (yet).

• In fact the only modification as such was for Time Machine. The others are for a print server and arguably are not modifications at all... implementing a print server involved nothing more than installing a printer and then sharing it. No changes to SMB or any other sharing service were involved. So we might as well disregard that fact. Everything is as "out of the box" as a Raspberry Pi can be.

The relevant section for `[Global]`:

Under [global] mine has nothing. Just comments.

for the Time Machine share:

[BackupB]
        comment = Backups
        path = /mnt/backups/BackupB
        valid users = timemachine
        read only = no
        vfs objects = catia fruit streams_xattr
        fruit:time machine = yes
john@RPi00:~ $ 

That's it.

Some changes are intentional. For example I do not want TM backups to be browsable. It's my selfish opinion that people get themselves into far too much trouble by doing that. It used to be "look but don't touch" but now I am advocating a position in which TM backup files are for TM's exclusive use (which has always been the case) and the user is not permitted to even see them (which would be new, and Apple might not agree with me. People will complain either way). The only authorized user is the user timemachine.

I can copy, rename, and delete files from both the Time Machine share and other shares without issue.

That is believe we will remain in disagreement. In my opinion a TM share should be for its exclusive use — the user timemachine in this case. The RPi user can't screw things up no matter how much he or she tries, nor can you log in under timemachine with its credentials. If I can find a way to make it even more tamperproof, I will.

Personally I think this is consistent with my goal of keeping things simple.

Now... having said that, your difficulties might be entirely unrelated to smb.conf or anything else. Start with the basic step of removing that TM backup destination from your Mac's TM settings, and adding it again. That will have no effect on any existing backups.

I did not inspect your Mac's logs to any extent... I believe all that will accomplish is to confirm what you already know: TM can't back up.

Let me know what you think; I'll provide any RPi configuration files that you suspect may be relevant.

iamshivam wrote:

… actually supports extended attributes and POSIX rename/flush (NTFS/exFAT via FUSE often fails for TM) … consider using a True APFS/SMB Time Machine target (a NAS with validated TM support) or attach the drive directly to the Mac

APFS is not involved with any NAS server, other than with a Mac being used as a NAS server.

To avoid related confusion, nor is AFP involved, as of macOS 26.

And NTFS is unlikely outside of a Windows NAS.

ExFAT is also a comparatively poor choice for a NAS a volume structure for Time Machine, too.

One of the preferred native file systems for the platform would be much more typical.

For those preferring pre-configured servers for their chosen local hardware, TrueNAS or ZimaOS are available among other options.

For those that want less effort and want dedicated hardware akin to Time Capsule, Ubiquiti UNAS 2 two-bay NAS is US$299, plus the cost of one or two Ubiquiti HDDs, or adding your own HDDs disks. (Review)

For debugging purposes post the result of

testparm -s

It should be fairly short.

From the manpages,

testparm - check an smb.conf configuration file for internal correctness

Thanks. My RPi installation is elsewhere so I won't be able to review it for a couple of days. In the meantime try the simple step of removing that TM destination from its Settings, and adding it again.

Also, bear in mind the differences I pointed out... my RPi NAS is a lot simpler. It's a stock Pi with the added necessities, no more. I also humbly suggest not letting yourself be led astray, and I believe the problem will turn out to be simple. Concentrate on what's essential. No APFS, none of that nonsense. It's irrelevant.

For those that want less effort and want dedicated hardware akin to Time Capsule, Ubiquiti UNAS 2 two-bay NAS is US$299, ...

... which is about $200 more than a Raspberry Pi, well equipped with a nice case and robust power supply.

If you're a real cheapskate it can be done for much less.

Effort? Very little. I may create a User Tip but there won't be much to it.

I’m getting exactly the same error. I bought a new hard drive and decided to reinstall the whole NAS system on the Pi.

I used the same guide I followed when I set up the system a month ago, and back then it worked.

My SSD is formatted as ext4, and I manually checked that xattrs are working.

On my Mac, if I simply add/rename/delete a file on the network drive, everything works, but when I start a backup through Time Machine, I get a permission error.

The Samba configuration is almost identical (except for the folder path and the user).

👍

Please let us know what "tuning and tweaks" you have in mind. Although I am reluctant to change anything about Time Machine, preferring to keep it simple and reliable, there may be some beneficial, harmless actions worth considering.