Time Machine error

[gilby101]

The extender has 5 ports, two are used by the TM disks and they each have their own power adapters. Interestingly I'd plugged in external portable speaker into a 3rd in order to charge it. It's drawing power from the extender and therefore the Studio USB port.)

Whenever there are issues with USB devices and an unpowered USB hub (extender) is in use, I blame the "extender" until proven otherwise. Use a powered USB hub and see if your problems stop - or connect devices directly to the Mac.

Also I don't think you have told us the brand and model of your extender.

 

[ThrowerGB]

Whenever there are issues with USB devices and an unpowered USB hub (extender) is in use, I blame the "extender" until proven otherwise. Use a powered USB hub and see if your problems stop - or connect devices directly to the Mac.

Also I don't think you have told us the brand and model of your extender.

Thanks, I've connected each drive directly to its own port on my Mac Studio. i.e., no hub involved now. The hub was unpowered Anker with 4 USB 3.0 ports. It plugged into a USB C port on the Mac Studio. Apple System Info says it's a USB3 Gen2 Hub connected to a USB 3.1 Bus. But again, it's not in the loop now.
The two drives are both Western Digital 10 TB Elements hard drives plugged into one (each) of the same USB C ports on the Mac with those ports noted in Apple System Info as connected to a USB 3.1 bus. Each of the drives draws its power from its own adapter plugged into a regular household electrical outlet. The drives have nominal speed of "Up to 6Gb/s"

 

[svenmany]

I think the hub/USB variability might be just a coincidence. The error mentioned in the opening post can be seen in the logs. The logs show that some files on the disk being backed up are not available. I guess the hub/USB could be a factor if those external problematic disks were being backed up by TM rather than being a backup destination.

 

[gank41]

I've been using Time Machine for my main backups since Time Machine's inception, and I've honestly never had any issues restoring from a backup. There have been the random bug or issue where some backups fail or aren't completed, but in the recent iCloud years, the most likely reason Time Machine backups fail is due to macOS not having all of the iCloud files downloaded, which isn't a "Time Machine" issue. And you can usually just start another manual Time Machine backup (or two 😉 ) to ensure you are fully backed up.

I do use Backblaze, too, but that's because I've been burned in the past and lost important stuff. Won't let that happen again lol

 

[jdw13]

Since early December, I have had no problems with my nightly TimeMachine backup scheduled by TimeMachineEditor because I removed password required to wake up but after updating to Sequoia 15.3.1 from 15.3, my backup failed last night.

2025-02-12 10:49:58.528 E backupd[278:91e68] [com.apple.TimeMachine:BackupDispatching] Backup failed: BACKUP_DELAYED_UNFINISHED_PROTECTED_FILES (104)
2025-02-12 10:49:58.560 E backupd[278:9282f] [com.apple.TimeMachine:General] com.apple.backupd.xpc: connection invalid
2025-02-12 10:49:58.686 E TMHelperAgent[75639:92a80] [com.apple.TimeMachine:General] com.apple.TMHelperAgent.DeliverNotification: connection invalid

However, after doing a fresh reboot a "Back Up Now" manually triggered from the TimeMachine menu bar completed with a full backup. However the log during the day still showed similar errors to those seen at night, such as:

2025-02-12 10:48:31.618 E backupd[278:91aa7] [com.apple.TimeMachine:TMDeviceRulesEngine] Failed to read sticky exclusion extended attribute for /System/Volumes/Data/private/var/folders/mv/77grpvl11yzffhg5316y9qjc0000gn/0/com.apple.nsurlsessiond/.../Uploads, error: 2 No such file or directory

but the backup completed.

If you do not see a message from me tomorrow, then the backup went overnight, as before and you know that a few fresh reboots may kick start back you back to being able to backup if you have your Mac someplace where it is safe to remove requiring password to wake-up.

 

[svenmany]

Since early December, I have had no problems with my nightly TimeMachine backup scheduled by TimeMachineEditor because I removed password required to wake up but after updating to Sequoia 15.3.1 from 15.3, my backup failed last night.

If you scan your log a bit earlier than the "BACKUP_DEL..." line, you'll probably see some lines saying "Failed to acquire device lock assertion for ..." This is the standard error that happens when the computer is locked and some files become unavailable. Those unavailable files prevent the backup for finishing.

However the log during the day still showed similar errors to those seen at night, such as:

The error you posted doesn't seem to be a similar error. Apple's logs are always filled with errors. I've always just assumed most were harmless. The file you referenced is in your temp folder. The contents of that folder are deleted after rebooting.

 

[EugW]

Damn. Happened again the other day, just once though this past week. My setup:

M4 Mac mini
USB 4 / Thunderbolt 4 hub #1 --> USB 4 / Thunderbolt NVMe Time Machine SSD.
USB 4 / Thunderbolt 4 hub #2 --> USB 4 / Thunderbolt NVMe data SSD (which is backed up to Time Machine).

BTW, in this setup, both drives are detected as Thunderbolt 3 drives. (When I plug them into the Mac mini directly, they are detected as USB 4 drives. Not sure why plugging them into the hubs changes their detection to Thunderbolt 3.)

 

[Mr. Luigi]

Since updating to Sequoia my Time Machine backups have been failing during night. Every time I wake up the display, I get the same error: "Time Machine did not finish backing up because some files were unavailable. Backups will resume when your Mac is unlocked." My Mac actually never sleeps; I only put the display to sleep. The next backup after waking the display always works.
Anyone is having the same problem?

I understand the vast majority of you will not like this solution. But time is money. And time spent with no positive results is stress. So I gave up the ship on Time Machine Backups and installed Carbon Copy Cloner 7 on my M4 Mac mini and no longer have to worry or spend time worrying about my hourly backups. They proceed flawlessly. I know many will not want to pay for a functionality that Apple should be providing as part of the purchase of its products. But for me, this is a much better way to manage my life than waiting for a solution from Apple that many never come. Full confession. I had bought a previous version of Carbon Copy Cloner years ago for a very specific purpose. So I did receive a discount from Carbon Copy Cloner to update to CCC7.

 

[jdw13]

I understand the vast majority of you will not like this solution. But time is money. And time spent with no positive results is stress. So I gave up the ship on Time Machine Backups and installed Carbon Copy Cloner 7 on my M4 Mac mini and no longer have to worry or spend time worrying about my hourly backups. They proceed flawlessly. I know many will not want to pay for a functionality that Apple should be providing as part of the purchase of its products. But for me, this is a much better way to manage my life than waiting for a solution from Apple that many never come. Full confession. I had bought a previous version of Carbon Copy Cloner years ago for a very specific purpose. So I did receive a discount from Carbon Copy Cloner to update to CCC7.

I agree that CCC is excellent and I have been using it for years with scheduled backups to various destinations every day. However, I also use TimeMachine because the restore interface is so convenient to drill down and get an earlier version of a single file. If nightly fails, I let it backup when I wake the machine. I, too, have reported this to Apple and agree this is not worth any more effort especially when Apple ignores our feedback.

 

[-hh]

I've been struggling with this TM error for awhile now ... and I think I might have found the cause & easy solution.

Since it seems that the problem was associated with the Mac being locked, I tried going to the MacOS System Settings to extend the time-until-lock on the Lock Screen. What I found that the "Require password after screen saver begins..." was set to "Immediate" - - plus it was greyed out, indicating that I couldn't change it.

Tracking the reason for why it was disabled, I found that this setting was disabled by the introduction (in macOS Sequoia 15 & iOS 18) of the MacOS "iPhone Mirroring" App, and its settings.

TL;DR - a solution to try ... it has been working for me for 5+ days so far:

• On your Mac, open System Settings; goto "Lock Screen", see if "Require password after screen saver begins..." is greyed out as described above. If so, then continue.
• On your Mac, launch the iPhone Mirroring App.
• Open "Settings" from its menu. For reference, see the included pic of this dialog box.
• Change from "Automatically Authenticate" to "Ask every time".
• Close the dialog box & Quit the iPhone Mirroring App.
• Go back to System Settings & check the Lock Screen settings - the "Require password after screen saver begins..." should no longer be greyed out. Try setting it to something other than "Immediate" for now.
• Done (maybe do a reboot now to be sure)

FYI, I don't know if changing the "Require password after screen saver begins..." is necessary, but I did it, so I'm including it as a conservative step: my thought was that if the Mac doesn't lock for a long time, that would give TM ample time to run unlocked. I chose 8 hours and the Time Machine errors have gone away.

I'm now reducing the time setting for screen saver password.

I'm now down to just 1 hour, and my TM backups are still running fine overnight with zero errors. Today, I've reduced it to just 15 minutes. If that works too, I'll try going all the way back to "Immediate".

Overall, I think that the iPhone Mirroring App's automatic authentication is the root cause of this TM error.

 

[gank41]

I've been struggling with this TM error for awhile now ... and I think I might have found the cause & easy solution.

Since it seems that the problem was associated with the Mac being locked, I tried going to the MacOS System Settings to extend the time-until-lock on the Lock Screen. What I found that the "Require password after screen saver begins..." was set to "Immediate" - - plus it was greyed out, indicating that I couldn't change it.

Tracking the reason for why it was disabled, I found that this setting was disabled by the introduction (in macOS Sequoia 15 & iOS 18) of the MacOS "iPhone Mirroring" App, and its settings.

TL;DR - a solution to try ... it has been working for me for 5+ days so far:

• On your Mac, open System Settings; goto "Lock Screen", see if "Require password after screen saver begins..." is greyed out as described above. If so, then continue.
• On your Mac, launch the iPhone Mirroring App.
• Open "Settings" from its menu. For reference, see the included pic of this dialog box.
• Change from "Automatically Authenticate" to "Ask every time".
• Close the dialog box & Quit the iPhone Mirroring App.
• Go back to System Settings & check the Lock Screen settings - the "Require password after screen saver begins..." should no longer be greyed out. Try setting it to something other than "Immediate" for now.
• Done (maybe do a reboot now to be sure)

FYI, I don't know if changing the "Require password after screen saver begins..." is necessary, but I did it, so I'm including it as a conservative step: my thought was that if the Mac doesn't lock for a long time, that would give TM ample time to run unlocked. I chose 8 hours and the Time Machine errors have gone away.

I'm now reducing the time setting for screen saver password.

I'm now down to just 1 hour, and my TM backups are still running fine overnight with zero errors. Today, I've reduced it to just 15 minutes. If that works too, I'll try going all the way back to "Immediate".

Overall, I think that the iPhone Mirroring App's automatic authentication is the root cause of this TM error.

This is a great find, but I would hate to have to disable that setting in iPhone mirroring. I use iPhone mirroring all the time, and it’s almost just easier for me and my case to just manually kick off a Time Machine back up. I hope that if you file a report you include all of this information because it does actually sound like it could be the root of this issue. I’ve been away from my computer computers for a little bit, but I’m going to try this when I get back home. I know that my lock screen settings are also set to immediate as well, and it’s grayed out. So I’m probably suffering the same issue you are.

 

[kirbyrun]

I've been struggling with this TM error for awhile now ... and I think I might have found the cause & easy solution.

Since it seems that the problem was associated with the Mac being locked, I tried going to the MacOS System Settings to extend the time-until-lock on the Lock Screen. What I found that the "Require password after screen saver begins..." was set to "Immediate" - - plus it was greyed out, indicating that I couldn't change it.

Tracking the reason for why it was disabled, I found that this setting was disabled by the introduction (in macOS Sequoia 15 & iOS 18) of the MacOS "iPhone Mirroring" App, and its settings.

TL;DR - a solution to try ... it has been working for me for 5+ days so far:

• On your Mac, open System Settings; goto "Lock Screen", see if "Require password after screen saver begins..." is greyed out as described above. If so, then continue.
• On your Mac, launch the iPhone Mirroring App.
• Open "Settings" from its menu. For reference, see the included pic of this dialog box.
• Change from "Automatically Authenticate" to "Ask every time".
• Close the dialog box & Quit the iPhone Mirroring App.
• Go back to System Settings & check the Lock Screen settings - the "Require password after screen saver begins..." should no longer be greyed out. Try setting it to something other than "Immediate" for now.
• Done (maybe do a reboot now to be sure)

FYI, I don't know if changing the "Require password after screen saver begins..." is necessary, but I did it, so I'm including it as a conservative step: my thought was that if the Mac doesn't lock for a long time, that would give TM ample time to run unlocked. I chose 8 hours and the Time Machine errors have gone away.

I'm now reducing the time setting for screen saver password.

I'm now down to just 1 hour, and my TM backups are still running fine overnight with zero errors. Today, I've reduced it to just 15 minutes. If that works too, I'll try going all the way back to "Immediate".

Overall, I think that the iPhone Mirroring App's automatic authentication is the root cause of this TM error.

Sorry to report that I tried this back when the TM issue first reared its head. It didn't work for me.

 

[-hh]

Sorry to report that I tried this back when the TM issue first reared its head. It didn't work for me.

Yeah, I'm sad to report that what was working okay for me ... has stopped working okay. After I posted, I changed the lock time all the way down to 15 minutes.

So I'll be setting it back to 8 hours tonight and give it another whirl.

Sorry everyone; thought that I'd found it. Even so, if 8hrs holds, then it is a "less bad" solution than having to stay at the machine until it completes.

 

[YatBob]

This is a great find, but I would hate to have to disable that setting in iPhone mirroring. I use iPhone mirroring all the time, and it’s almost just easier for me and my case to just manually kick off a Time Machine back up. I hope that if you file a report you include all of this information because it does actually sound like it could be the root of this issue. I’ve been away from my computer computers for a little bit, but I’m going to try this when I get back home. I know that my lock screen settings are also set to immediate as well, and it’s grayed out. So I’m probably suffering the same issue you are.

Did not work for me either

 

[kagharaht]

So far no error since updating to 15.3.1. Both iMac M3 and MBA M2 15". Both are set to never sleep but does turn off display and lock after 10 min.

 

[EugW]

Interesting. It happened to me last night. However, when I tried to access my documents folder on my internal drive, it was greyed out. I could not access the files there from the Finder.

The weird part is I could run my applications just fine. So I logged on and logged back in, and the files were fully accessible again. I wonder if this some weird Finder bug or something similar. When this happens, Time Machine loses the ability to access the files too..

 

[YatBob]

I've been struggling with this TM error for awhile now ... and I think I might have found the cause & easy solution.

Since it seems that the problem was associated with the Mac being locked, I tried going to the MacOS System Settings to extend the time-until-lock on the Lock Screen. What I found that the "Require password after screen saver begins..." was set to "Immediate" - - plus it was greyed out, indicating that I couldn't change it.

Tracking the reason for why it was disabled, I found that this setting was disabled by the introduction (in macOS Sequoia 15 & iOS 18) of the MacOS "iPhone Mirroring" App, and its settings.

TL;DR - a solution to try ... it has been working for me for 5+ days so far:

• On your Mac, open System Settings; goto "Lock Screen", see if "Require password after screen saver begins..." is greyed out as described above. If so, then continue.
• On your Mac, launch the iPhone Mirroring App.
• Open "Settings" from its menu. For reference, see the included pic of this dialog box.
• Change from "Automatically Authenticate" to "Ask every time".
• Close the dialog box & Quit the iPhone Mirroring App.
• Go back to System Settings & check the Lock Screen settings - the "Require password after screen saver begins..." should no longer be greyed out. Try setting it to something other than "Immediate" for now.
• Done (maybe do a reboot now to be sure)

FYI, I don't know if changing the "Require password after screen saver begins..." is necessary, but I did it, so I'm including it as a conservative step: my thought was that if the Mac doesn't lock for a long time, that would give TM ample time to run unlocked. I chose 8 hours and the Time Machine errors have gone away.

I'm now reducing the time setting for screen saver password.

I'm now down to just 1 hour, and my TM backups are still running fine overnight with zero errors. Today, I've reduced it to just 15 minutes. If that works too, I'll try going all the way back to "Immediate".

Overall, I think that the iPhone Mirroring App's automatic authentication is the root cause of this TM error.

I tried this procedure and it did not work, went back to the settings before this recommended procedure has has been working

This is a great find, but I would hate to have to disable that setting in iPhone mirroring. I use iPhone mirroring all the time, and it’s almost just easier for me and my case to just manually kick off a Time Machine back up. I hope that if you file a report you include all of this information because it does actually sound like it could be the root of this issue. I’ve been away from my computer computers for a little bit, but I’m going to try this when I get back home. I know that my lock screen settings are also set to immediate as well, and it’s grayed out. So I’m probably suffering the same issue you are.

Sorry for the double post

 

[kagharaht]

Still getting the same error. Mac OS 15.3.1. Just got it today on the iMac M3. The MBA M2 15" was also getting it. At least it's not corrupting the TM backup or the Mac itself. Hard to believe no one at Apple Mac OS team is aware of this.

 

[osplo]

Any luck with 15.4 Beta?

 

[MNGR]

Any luck with 15.4 Beta?

The last update for Sequoia before Mar 11 fixed the issue for me

 

[southerndoc]

Any luck with 15.4 Beta?

I didn't have any issues with 15.3. My MacBook Air M1 started having the issue again last week. Then I realized I just upgraded to 15.4 with it. My Mac Studio (still on 15.3) is not having the issue.

15.4 may have reintroduced the issue again.

 

[svenmany]

I'm running Sequoia 15.3.2 and the problem still exists. I suspect Apple isn't addressing the Time Machine issue at all. The variability probably relates to the particular underlying processes which are getting in the way. It really will depend on which processes a user is running and the timing of their activities with respect to Time Machine backups. Perhaps, Sequoia introduces a new API or changes to the behavior of some API that some processes are using. Whether the problem appears to be solved for an individual user after an OS update could be just random.

For quite a while I've had two Time Machine exclusions in place and haven't had a single error:

• ~/Library/Biome
• ~/Library/Daemon Containers/B2272... (very long hex identifier)

I excluded those because there were errors in the logs that showed those as blocking the backups. For kicks, I eliminated those exclusions yesterday. This morning I woke to find the usual Time Machine errors. The logs showed the same Daemon Containers error, but not the Biome one.

In the Daemon Containers directory I found files named milo.*. This thread discusses other locking issues with milo.* files.

https://forums.macrumors.com/threads/does-this-file-exist-for-you-milod-service.2430197/

In that thread, the same daemon was preventing Arq backups from working. Even Carbon Copy reported that it couldn't back up a milo related file.

And there's this:

Is Milod Service on macOS a Hidden Threat, Stealthy Malware or Essential Component? - PUPUWEB

The Milod service on Mac has been causing confusion and concern among users. You might have noticed it running in the background and wondered, "Is this a

pupuweb.com

I will put my milod exclusion back.

I wonder if Apple hasn't yet solved this because it's a hard problem. There might be a very good reason not to allow the reading of certain files while some process has gained exclusive access. There might be a very good reason that Time Machine refuses to record a successful backup if it couldn't back up everything. The problem might be trying to reconcile two competing requirements.

 

[kagharaht]

Still happening with Mac OS 15.3.2. The "Time Machine did not finish backing up because some files were unavailable. Backups will resume when your Mac is unlocked."

iMac M3 and MBA M2 15". At least the next version of Mac OS will have new Emoji stuff. Apple at the top of their game here.

 

[ignatius345]

Whenever there are issues with USB devices and an unpowered USB hub (extender) is in use, I blame the "extender" until proven otherwise. Use a powered USB hub and see if your problems stop - or connect devices directly to the Mac.

Also I don't think you have told us the brand and model of your extender.

I've seen the same error on my MacBook Air with the drive plugged directly in and the computer connected to AC power. Not saying unpowered hubs can't be an issue, but in this case I believe it's something else.

Out of curiousity, I wonder how many who are getting this error are using HDDs for backup. I know I am, and I wonder if that's a factor?

At least the next version of Mac OS will have new Emoji stuff. Apple at the top of their game here.

I can't say for certain, but I have a hunch that the graphic designers who keep the OSes up to date with the latest emoji from Unicode Consortium are not the same people who work on Time Machine. I could be wrong. Maybe they're the same extremely versatile team.

 

[gilby101]

For quite a while I've had two Time Machine exclusions in place and haven't had a single error:

• ~/Library/Biome
• ~/Library/Daemon Containers/B2272... (very long hex identifier)

I excluded those because there were errors in the logs that showed those as blocking the backups. For kicks, I eliminated those exclusions yesterday. This morning I woke to find the usual Time Machine errors. The logs showed the same Daemon Containers error, but not the Biome one.

On my iMac, ~/Library/Biome is excluded by default. It is in the "stickyExclusionPaths" in the .exclusions.plist file in the root of each backup snapshot.

This is with a recent macOS clean install with 15.3.1. But the exclusion is also present in older TM snapshots since mid-December (15.2?). Before that there are lots of specific folders inside ~/Library/Biome which were excluded.

Seems that Apple decided to exclude the whole folder.