Time Machine doing full backups on macOS Tahoe

From a quick review of the log, this doesn’t look like “Time Machine choosing to do full backups” so much as “Time Machine can’t reliably *see or update* the existing backup set on the network target, so it behaves like it has to start over (or never completes enough state to remain incremental).”

The biggest red flags are the Permission denied / Operation not permitted when reading volume capabilities for the mounted Time Machine share, plus “Resource busy” when writing com.apple.TimeMachine.MachineID.plist inside the sparsebundle. If Time Machine can’t read the destination’s capabilities consistently and can’t update its identity/plist files, it can’t cleanly maintain the incremental chain.

The other repeating error, tmutil … fs_snapshot_list failed: Operation not supported, strongly suggests the Mac isn’t able to enumerate local filesystem snapshots for the source volume at that moment (or the source isn’t presented as snapshot-capable). Modern Time Machine relies heavily on APFS snapshots to produce fast incrementals. If snapshot operations aren’t available/working, backups can become much larger and “full-like,” and if the network destination is also flaky/permission-blocked, you’ll see repeated resets.

The BACKUP_IN_PROGRESS_REQUEST_DROPPED (46) is consistent with a backup getting wedged and new requests being ignored/dropped.

Ok, with all that said, the most likely causes are:

• NAS / SMB share permissions or capability reporting are broken/inconsistent: (Permission denied, Operation not permitted, can’t read capabilities, can’t get remount key).
• Sparsebundle is being held open/locked: (Resource busy). Often caused by NAS-side indexing/AV, another Mac trying to back up to the same bundle, stale SMB handles, or a prior mount not cleanly detached.
• Source snapshot support is failing: (fs_snapshot_list … Operation not supported). These can lead to huge deltas and fragile incrementals.
• Mount path / share identity instability. If the share mounts differently each time (Bonjour name changes, different subpath under /Volumes/.timemachine/...), Time Machine can treat it as a “new” destination.

Finally, here are some steps you can take to hopefully resolve this:

• Confirm the destination is stable and writable:
  • On the Mac: open Time Machine settings and verify it’s always pointing to the same network disk/share.
  • Using the Finder, connect to the share manually, create/delete a test folder (confirms real write access).
  • On the NAS: ensure the Time Machine user has full read/write on the Time Machine share and the share is explicitly configured for Time Machine over SMB.
• Eliminate Resource busy / locking:
  • Ensure only one Mac is using that specific sparsebundle (each Mac should have its own bundle).
  • Temporarily disable NAS-side indexing/antivirus on the Time Machine share (if enabled).
  • Eject the Time Machine volume, reboot the NAS (or at least restart SMB), then reboot the Mac and try again.
• Check whether Time Machine is actually re-creating the backup set:
  • On the Mac (Terminal):
    • tmutil listbackups (if it returns nothing / resets each run, it’s not maintaining the chain)
    • tmutil destinationinfo (confirms what destination TM thinks it’s using)
• Fix the snapshot issue on the Mac:
  • Confirm the source volume is APFS and not an unusual setup.
  • Make sure there’s adequate free space on the Mac (snapshots can fail when space is tight).
  • If third-party security software is installed, temporarily disable it and retest (some tools interfere with backupd access patterns).

When Time Machine keeps doing full backups, it’s usually because it believes each backup is going to a “new” destination. This can happen if macOS can’t reliably recognize the backup disk, the volume identity keeps changing, snapshots are corrupted, or the backup history database is damaged. Network shares can trigger this, but since it also happens on a local APFS drive, it points more toward a Time Machine state or snapshot issue on the Mac itself.

To resolve this, I’d suggest a clean reset of Time Machine’s local state and snapshots, as follows:

1. First, turn off Time Machine.
2. Then open Terminal and run tmutil listlocalsnapshots / << This will provide you with a list of all current snapshots on your Mac. You should see something like: com.apple.TimeMachine.2026-01-05-100421.local
3. Then remove them using tmutil deletelocalsnapshots <date>.
4. After that, delete the Time Machine preference file (/Library/Preferences/com.apple.TimeMachine.plist).
5. Reboot the Mac, re-enable Time Machine, and select the backup disk again.

Alternately, for steps 2 & 3, you can use the Disk Utility instead. From the Disk Utility select the "Data" volume. A list of APFS snapshots should appear at the bottom of the utility. If they don't, from the Utility's menubar, select View > Show APFS Snapshots. You can then select each snapshot and delete them.

If the issue persists, try disabling Spotlight indexing on the backup disk, make sure the drive isn’t being mounted under different names, and confirm the disk has at least 2–3× your data size so Time Machine can rotate snapshots properly. Finally, we can look into the Mac's system logs to see what Time Machine is (or not) doing to cause this.

I don't know, but I may have some good news.

After filling up the new 2.8-TB external HD TM partition (to replace the definitely non-working file-shared TM volume on the drive shared by the iMac) in less than a day with multiple full backups of my MacBook Pro, I stumbled across another Reddit thread about people having trouble with their NASes and Time Machine with Tahoe, although with 26.1.

It suggested removing some extended attributes on a Mac OS X system directory that I'd never looked at before and didn't realize had a "Volumes" subdirectory as well: /System/Volumes/Data/ I saw some errors from Time Machine about "Volumes/Data", but either I didn't notice the preceding "/System/" or it wasn't there. I used to have a partition called "Data" and I thought it was some hangover from that. Apparently not!

```

sudo xattr -d com.apple.backupd.BackupMachineAddress /System/Volumes/Data

sudo xattr -d com.apple.backupd.ComputerName /System/Volumes/Data

sudo xattr -d com.apple.backupd.HostUUID /System/Volumes/Data

sudo xattr -d com.apple.backupd.ModelID /System/Volumes/Data

sudo xattr -d com.apple.timemachine.private.structure.metadata /System/Volumes/Data

```

1. I removed those attributes (using the above commands from Terminal -- you'll need to be on an admin account and authenticate in Terminal).
2. Removed the external drive partition as a Time Machine destination via Control Panel -> General -> Time Machine.
3. Erased my full external HD TM partition.
4. Re-added the external drive as a Time Machine destination (another reformat);
5. Did a full initial backup.
6. Initiated a backup again when it finished and it did a delta!
7. Went out for a walk, came back, and it had done another delta.

I was able to retrieve a changed file from the Time Machine backup correctly, so that looks very promising.

I'm going to try the Apple file-shared TM volume again as a backup destination and see if that now also works. I have to copy my backed up 1.8-TB sparse image from the NAS back onto that partition first. I'm pretty hopeful that will now work. The procedure will be somewhat similar to what I described above. For you on your QNAP, you can follow the Reddit instructions for the Synology:

>>>

Removing the following metadata attributes in macOS helped me:

sudo xattr -d com.apple.backupd.BackupMachineAddress /System/Volumes/Data

sudo xattr -d com.apple.backupd.ComputerName /System/Volumes/Data

sudo xattr -d com.apple.backupd.HostUUID /System/Volumes/Data

sudo xattr -d com.apple.backupd.ModelID /System/Volumes/Data

sudo xattr -d com.apple.timemachine.private.structure.metadata /System/Volumes/Data

Then reboot the Mac and reattach Synology Time Machine backup network storage.

>>>

That thread also had a pointer to an extensive blog post on solving Tahoe-related TM issues that I hadn't come across previously: https://macos-tahoe.com/blog/macos-tahoe-time-machine-complete-troubleshooting-guide-2025/

Don't do any of this if you don't feel comfortable doing it. The names of those extended attributes are all clearly related to Apple's backup process. However, I'm not claiming to be an expert and I don't know what side effects there might be on an existing Time Machine backup set, if any. On the plus side, it's easy to undo: use `sudo xattr -w` instead of `sudo xattr -d` (+ the rest of each line) but undoing damage to your TM image may not be so easy.

I'll report back on using my existing TM image after I've finished restoring it from the NAS and tried backing up a delta to it.

Sorry, that didn't help. The next step would be to review the Mac's system logs to find out what Time Machine is doing (or not doing).

You can get a log extract by using the following command in the Terminal:

• log show --predicate 'subsystem == "com.apple.TimeMachine"' --last 1h > ~/Desktop/timemachine.log
• Depending on when you last ran the backup, you can change the "--last" qualifier as needed.

This will create a log file, named: timemachine.log on your Mac's Desktop. I would suggest that you review this log, and if you need any assistance with that, you can use the forum editor's "Additional Text" tool to copy it to, and then, post it.

This might help. I found this on a Reddit post yesterday. Following these steps resolved my constant Time Machine full backup issues:

Summary of the actions that fixed the issue

I was facing an issue where Time Machine performed a full backup every time, instead of incremental backups, even after completely recreating the setup on my Synology NAS (new folder, new user, new sparsebundle, etc.).

The solution was:

1. Remove Time Machine-related extended attributes from macOS

(macOS was keeping an outdated internal identity that no longer matched the new backup)

Commands used:

sudo xattr -d com.apple.backupd.BackupMachineAddress /System/Volumes/Data
sudo xattr -d com.apple.backupd.ComputerName /System/Volumes/Data
sudo xattr -d com.apple.backupd.HostUUID /System/Volumes/Data
sudo xattr -d com.apple.backupd.ModelID /System/Volumes/Data
sudo xattr -d com.apple.timemachine.private.structure.metadata /System/Volumes/Data

2. Delete all local APFS snapshots

tmutil listlocalsnapshots /
sudo tmutil deletelocalsnapshots <ID>

3. Reboot macOS

This forces Time Machine to recreate a clean internal identity.

4. Reconnect the SMB share cleanly

Then re-add it as a fresh Time Machine destination.

5. Run the first full backup

→ then trigger a second backup

→ which finally appeared as incremental, as expected.

thanks for Reddit user DimebagCFH666 for the tip!.

* But I have Bitdefender antivirus activated on the mac. Next will be to restart the whole process with the antivirus turned off maybe

Uninstall it. "Bitdefender" and things like it can only cause problems.

It is not sufficient to disable or "turn off" those things. They must be uninstalled and all remnants of their previous existence expunged from the affected Mac. Whether it is the direct cause of the concern at hand remains to be determined, but Rule 1 of Macs is don't install junk.

Let me throw another wrench into the works. I'm also having this issue since December 29th, but I'm not using a third-party NAS. I'm having trouble with a directly connected HD and an Apple file shared volume.

My Systems:

• 16" M3 Pro MacBook Pro w. 36 GB RAM, running Mac OS X Tahoe 26.2;
• 27" 3.8 GHz 10-core Intel iMac w. 72 GB RAM, running Mac OS X Sequoia 15.7.3;

Original Backup Configuration:

• 5-TB Western Digital (WD) HD attached via Thunderbolt port on the iMac.
• 2 volumes on the WD drive, both created December 11, 2024.
  • APFS (case-sensitive, encrypted) volume for locally backing up the iMac;
  • APFS (case-sensitive, encrypted) with a 1.8-TB sparse image bundle for backing up the MacBook Pro by configuring that WD volume to be a file share and for Time Machine.

What Happened:

I've pieced this together a bit after the fact:

• December 22, 2025: I updated the MacBookPro from Tahoe 26.1 to Tahoe 26.2.
• December 28, 2025: @~15:30. I updated the iMac to Sequoia 15.7.3, released December 12th 2025, from 15.7.2 (installed November 6, 2025).

Time Machine worked for both machines without a problem until December 28th, 2025:

• Dec 22: 2 backup folders for the MBP;
• Dec 27: 2 backup folders for the MBP;
• Dec 28: 2 backup folders for the MBP;
• Dec 29: 1 backup folder for the MBP;

The gaps are because the laptop wasn't in use and was sleeping for several days while I was away. When I came back and went to do some work last weekend, I noticed that TM was claiming my MacBookPro backup only went to some time on December 29th.

I manually initiated a backup and it took forever and failed, but without a useful error message. I thought it was a network problem or the drive had gone to sleep on the Mac, so I tried it again. No dice. Then I checked the logs and they were full of tons of file permission errors (Error 13), like "26-01-08 20:49:03.023 TimeMach attrVolumeWithMountPoint 'file:///Volumes/.timemachine/EinMacII._smb._tcp.local./B3567E28-6196-497D-9763-E106228CD787/MBPTM/' failed, error: Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied". I couldn't access that directory as myself from Terminal, so I su'ed to root, which worked, and I could see there was stuff in there. I know now that it was successfully making local backups, but was unable, after mounting the TM volume, able to do something to it.

Well after the fact, I can see that the December 29th folder on the TM sparse bundle image was *not* normal. It had two entries for the MBP internal drive: "Macintosh HD - Data" and "Macintosh HD - Data 1". I had noticed that in my "/Volumes/" directory, too, and thought it was odd. I thought it had somehow gotten confused. Both had the same modification date/time. Both had stuff in them, but the second one had far, far less stuff. The first had 17 directories at its top level and the second only had 5. The most recent modification date seemed to be December 28th around 05:30.

Thereafter followed days of trying to get it to work. I tried all of the following things:

• running Disk Utility's Repair Disk on the WD container and then the volume.
• running Disk Utility's Repair Disk on the TM sparse image (which took ages!).
• removing the entry for the backup destination from TM's preferences on the MBP and then re-adding it, telling it to continue using the existing backup there, which it found with no problem.
• rebooting the iMac.
• turning file sharing off and on, and checking the permissions for it, which looked OK, and included giving full access to connected users.
• giving read/write/execute access to everyone for the TM volume, but I didn't apply that, I think, to the sparse image or all its enclosed items. I was just trying to get TM to be able to access the actual drive volume (MBPTM) without a permissions error.
• renaming my iMac to remove the spaces and straight single quote, in case that was suddenly causing problems;
• cleared out all the local images on the MBP internal drive, wondering if something was corrupt in there.
• removed the extra, empty "Macintosh HD" entry from "/Volumes" on the MBP and rebooted the MBP.
• ran Onyx's various maintenance scripts on the MBP.
• moved the various TM-related files/folders from /Volumes on the MBP to somewhere else, dropped the TM destination, rebooted, and re-added the TM destination.

Continued in next post.

kop-95 wrote:

Unfortunately it did not help...

I've made all the 5 steps, rebooted, and restarted a new backup on a new 2 TB share (having 640-650 GB of data it is lightly more than 3x the need). First backup, full, OK. Second backup... full again.

I'm really lost.

I would reformat the drive and compare your results...

Erase and reformat a storage device in Disk Utility on Mac

Erase and reformat a storage device in Disk Utility on Mac - Apple Support

Continued from previous…

Result:

Nothing seemed to work, so I backed up the MBP TM sparse image to my NAS, so I could tell TM to create a new TM backup on that WD volume. At the same time, I found an older Western Digital 5-TB external drive, reformatted it, and created a new 2.8-TB APFS (Case-sensitive, Encrypted) volume on it to use as a (hopefully temporary) local TM backup destination for my MBP.

Here's where things get more interesting… I was able to add a new TM backup destination for that spare drive plugged directly into the MBP and it did a full backup. And then it did it again… and again… and again… Every time TM starts a backup, it's telling me that it's copying over 500 GB of data. The internal MBP drive is 1-TB and only 594 GB are used. But I've now used 2.27 TB of the 2.8 TB drive in the last day. Meanwhile, the log files are full of the earlier permissions errors while trying to access the newly created TM volume (which didn't get a sparse image this time) on the iMac.

Summary:

• Apple File Shared TM backup destination, even brand new, cannot be accessed by TM to backup without throwing Error 13 permission errors, although TM could format it for a new TM volume remotely with no problem.
• New local TM volume is allegedly backing up, but it's doing full backups every time. No idea what it's doing during "cleanup" or why it's copying the entire drive every time.

• Problems with the remote share started after an OS update to Sequoia 15.7.3 on the iMac. The iMac's TM continues to work fine AFAIK.
• There are issues both locally and with remote-mounted TM shares on the MacBookPro running Tahoe 26.2, upgraded December 22, but the remote TM share seemed to be working fine after that until the iMac operating system update on the 28th.
• Local iMac TM on external drive using Sequoia 15.7.3 is working fine, able to make backup deltas hourly.

Research:

When I started searching for this problem on the web, I found a number of references in December to people having similar permission problems with TM suddenly BUT they were all using 3rd-party NAS systems, like Synology or Unraid. One of those threads suggested the problem was a bug in Samba 4.23.3 and that downgrading the Unraid would fix the problem. That did not fix the problem for the poster. I think it's a red herring because MacOS isn't going to be using SMB 4.x as a client or a server, although a Reddit user was told it might be a similar issue in the last month or so.

Other people are reporting similar problems on reddit (and this one) particularly in respect to doing full backups over and over again. The latter thread had a reply from someone having problems with a Synology remote share and an external drive, which is somewhat similar to me.

I'm out of bright ideas, but maybe something I've said will spark additional lines of investigation for someone else.

Eclectic Mac Company author notes that APFS was given a minor update in Tahoe 26.2. That's the kernel extension that deals with Apple file systems, which is the type of file system we're having problems with for our Time Machine backups.

Checking my System Report information (System Info -> Software -> Extensions -> apfs) on my Intel iMac (updated to Sequoia 15.7.3 Dec 28th) and my M3 MacBook Pro (updated to Tahoe 26.2 on Dec 22nd), they were both showing as last modified (by Apple) November 22nd, 2025. I wonder if that's where the problem lies? Not that we can fix it on our own if it is. I don't think we can downgrade that kind of a kernel extension.

I am really sorry. it is a suffered decision but i need to be sure my backups works. so i decided to format and reinstall completely my mac and start over, fresh. i cannot wait a fix. and since i have also problems with my network configuration (vpn's of clients), printers not printing anymore and impossible to add, dangling apps... i must start fresh all over. (hoping that it will fix backup too...)

i'll use the latest not beta release of tahoe 26.2.

If you want to advance your troubleshooting efforts extract TM's logs according to Tesserax's instructions.

I follow this topic cause I have the exact same behaviour / problem.

Trying to fix the issue I did your same steps many times... and now i'm trying to make first backup after reset of both the SSD drive and my qnap's HBS3 folder which for years had been my main and only solution for TimeMachine's backups.

I wonder to know if you have ever used https://tclementdev.com/timemachineeditor/ this app because it might be the issue. I've seen it's not updated since 2022... I uninstalled it but no fix unfortunately.

As you, at first I thought it was the problem of non ASCII characters and QNAP so I added as destination an SSD... nothing changed.

IMHO all the problems started since tahoe 26.1... And it is related to the APFS filesystem and it's way to store snapshots...

Though, I deleted all the snapshots of my Mac SSD and started backup... No changes.

I've found this topic and I'm glad for not being the only one because I was planning to Wipe all My mac, reinstall the OS and start over... now I won't do it...

Let's keep in touch in order to fix this issue!

[Edited by Moderator]