Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Time Machine error
- Thread starter Jamacfer
- Start date
- Sort by reaction score
Yeah it goes for weeks without the issue, then suddenly it pops up a few times. Then it stops for a few weeks... it's really stupid and Apple doesn't care to fix it.
Not sure precisely when it started, but in the past month or two, my 2019 Intel MBP on 15.4 will no longer backup to my Time Capsule. I've erased the disk a few times and started a fresh backup (since I have multiple other backups), and each time it completes the first full backup without a hitch, but starts to fail on the following incrementals.
The error message I get is simply "Backup not completed. Time Machine could not backup to "my time capsule"", with no further information.
The error message I get is simply "Backup not completed. Time Machine could not backup to "my time capsule"", with no further information.
I don't think Apple will fix this issue in Sequoia. If they fix it, it'll be in the next major OS release. With their yearly release schedule, they don't have time to fix a lot of bugs and so non-critical bugs persist for months and even years until they get around to eliminating them.
I have two Time Capsules. They worked great in Sonoma and earlier, but Sequoia introduced this bug and Apple hasn't bothered to fix it.
Very odd that Apple these days do not believe that successful Time Machine backups are critical for a consumer. Of course one should expect them to really care about these things.
You would think, right? But they clearly don't given that they haven't bothered to fix it.
There isn’t any problem making Time Machine backups as long as you aren’t trying to do it to a piece of equipment that was discontinued 7 years and 6 operating systems ago.
This thread is about backups failing because files aren't available on the Mac being backed up. I'm backing up to current generation, attached, SSDs. I encounter the problem.
For quite a while I haven't had the problem since I'd excluded a problematic directory from the backups. The other day I had the problem again.
A simple log query reveals the locked files. I simply run "log show -last 8h | grep "Failed to acquire". It does take a very long time to finish, but it does show the files which are locked at the time of the backup. I pick "last 8 hours" since it happens overnight. But, a shorter time interval is possible if you look at the failure times in System Settings.
The latest incident involved a program that I almost never run. It's an iPad program that can run on my Mac. It's called "Eve" and it allows me to tweak some settings on my Eve Outdoor Camera. I ran it the other day and had the backup problem that night.
The log entries were all identical. Here's one line:
I added a bunch of line breaks to make that readable. You can see that at the beginning of the backup, Time Machine took a snapshot of the disk and was backing that up rather than the working disk.
If you know the format of the log command and its output you can see that the error lines have
process = backupd
sender = TimeMachine
subsystem = com.apple.TimeMachine
category:FileProtection
You could use those if you wanted to query your own logs more efficiently. It might speed up getting the results:
A simple log query reveals the locked files. I simply run "log show -last 8h | grep "Failed to acquire". It does take a very long time to finish, but it does show the files which are locked at the time of the backup. I pick "last 8 hours" since it happens overnight. But, a shorter time interval is possible if you look at the failure times in System Settings.
The latest incident involved a program that I almost never run. It's an iPad program that can run on my Mac. It's called "Eve" and it allows me to tweak some settings on my Eve Outdoor Camera. I ran it the other day and had the backup problem that night.
The log entries were all identical. Here's one line:
Code:
2025-04-30 06:09:17.645479-0700 0x2efc98 Error 0x0 578 0
backupd: (TimeMachine) [com.apple.TimeMachine:FileProtection]
Failed to acquire device lock assertion for
'/Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/m3/2025-04-30-060621
/Data/Users/xxx/Library/Containers/21694607-FEB9-4F63-BF7E-5EB0A9415704/Data/Library
/Saved Application State/com.elgato.eve~iosmac.savedState/data.data'
(assertion state: <dropped>), error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"I added a bunch of line breaks to make that readable. You can see that at the beginning of the backup, Time Machine took a snapshot of the disk and was backing that up rather than the working disk.
If you know the format of the log command and its output you can see that the error lines have
process = backupd
sender = TimeMachine
subsystem = com.apple.TimeMachine
category:FileProtection
You could use those if you wanted to query your own logs more efficiently. It might speed up getting the results:
Code:
log show -last 8h --predicate 'process=="backupd"' | grep "Failed to acquire"I was replying to a recent post about it not working correctly with Time Capsule. I use current backup drives for 3 Time Machine backups and all of them work correctly.
Is there a possibility that not all of the fellows who have experienced the error reported the bug to Apple through formal reporting? Apple does not read this forum.
The more we report bugs, the faster the fix.
Apple Product or Feedback page is where I send my feedback. https://www.apple.com/feedback/
Search for Feedback Assistant. Even if you aren't in the Appleseed program, you can still report it via Feedback Assistant. It'll attach a support file.
Every Mac has the Feedback Assistant installed, whether you're on the Beta Program or not. You can open it from the following folder-
/System/Library/CoreServices/Applications/Feedback Assistant.app
Yes, there are several handy programs there. When I start using a new Mac, one of the first things I do is drop a link from /System/Library/CoreServices/Applications/ into the /Applications folder for easy and visible access.
I'm struck by your comment "they don't have time to fix a lot of bugs". I agree with your sentiment, but the not having enough time is a fallacy. They're in control of the time they have. It's a function of how much they want to spend hiring enough people. At least they recognized they've made a mess of the current Settings UI's and are saying they're borrowing the approach developed for visionOS. Let's hope it's more than a different UI built on top of old plumbing in need of attention.
Thank you. I hadn't seen that book. But based on my quick read of the Wikipedia article, it has a lot of truth. One that is really difficult is introducing "new" people to an ongoing project reduces productivity. However, the case in point in this thread is fixing bugs rather than starting from scratch. Finding bugs takes a lot of skill and experience and it's more difficult if the code in question has been stable and reliable for long enough that there may not be people who are familiar with the code, or that the problem occurs from interaction between unexpected relationships between components.
Excellent point. Also, those separate components might be very well developed by different teams. A particular bug might be higher priority for one team and lower for another team. All parties have to coordinate on a final solution.
The current bug is probably challenging for Apple to solve quickly, or else it would already be done. On one hand, there's Time Machine, which cannot cope with the some files being locked. On the other, they have some file locking strategy that many components depend on. Certain files becoming inaccessible to certain processes after the user interface is locked could be due to some new security posture. They might have to think very carefully how to resolve it and how to coordinate the release of the solution across the involved components.