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.

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.

* 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.

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]

panda1988 wrote:

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

It’s certainly not a generic issue with Tahoe. Time Machine continues to work as it always had for me (now on 26.2 but I upgraded to Tahoe on day one). My primary backup is to a Synology NAS, my secondary backups are to a pair of SSDs, all work normally with the usual incremental backups (and snapshots stored locally, hourly for the past day plus the most recent one to each SSD, which I connect weekly to swap one offsite).

I will definitely tell you my latests tests and updates! I'm doing a backup through my qnap tonight and let's see if it ends with new tahoe Beta di 26.3 (a) (25D770870b) .

The other strange thing, is not only that it doesn't do incremental backups, but also that it does not delete old ones! neither on ssd nor through nas via SMB.

I tried as well to process the log of time machine but i cannot! too many attempts and too many lines!

When you have remove TMEditor, how did you remove it?

with the uninstall button on it's own submenu or just drag n drop the app and its relatives prefs files to the trash?

I installed it with homebrew, then i noticed that i must had to uninstall it first from it's own menu, then by the terminal with "brew uninstall --cask timemachineeditor"