---
title: Troubleshooting Time Machine Backup Issues on a Locked Mac
description: Time Machine backups on macOS can fail when the Mac is locked. In this post, I walk through how I diagnosed the issue using the log command and resolved it by rewriting the affected files.
date: 2025-04-19
url: https://aaron.cc/troubleshooting-time-machine-backup-issues-on-a-locked-mac/
---


I recently noticed that my Time Machine backups would fail when attaching the backup disk while my Mac (running macOS Sequoia 15.4.0) was locked. The following message would appear:

{{< img

  src="images/Time-Machine-Error-1.webp"
  alt="Time Machine couldn't complete the backup to \"Backup SSD\" Time Machine did not finish backing up because some files were unavailable. Backups will resume when your Mac is unlocked."
  caption="Message about unavailable files during Time Machine backup."
>}}

**So the backup failed because “some files were unavailable.”** Okay. At least, it would have been nice to know which files are affected. Also, letting the backup fail entirely just because of a few files (see below) clearly isn’t optimal.

After researching the error, [I found this handy command that will print the desired piece of information](https://www.stellarinfo.com/blog/fix-time-machine-waiting-to-complete-first-backup-issue-mac/):

```
$ log show --info --style compact --predicate '(subsystem == "com.apple.TimeMachine") && (eventMessage like[cd] "Failed * acquire device lock assertion*")' --last 24h
```

It gave me six entries that looked like this example (truncation by me):

```
2025-04-14 09:14:19.470 E  backupd[78056:149ff8] [com.apple.TimeMachine:FileProtection] Failed to acquire device lock assertion for '/Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/MacBook Pro/2025-04-14-091246/Data/Users/aaron/Documents/[…]/WhatsApp Image 2024-07-30 at 16.52.33.jpeg' (assertion state: <dropped>), error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"
```

Interesting. All of the affected files were images saved from WhatsApp. However, not all of my images saved from WhatsApp had this problem. There were even a few more in the same folder that did not suffer from this issue.

Unix file permissions and ownership were fine (`-rw-r--r--@ 1 aaron staff`), so I looked at the extended attributes:

```
$ xattr -l "/Users/aaron/Documents/[…]/WhatsApp Image 2024-07-30 at 16.52.33.jpeg"
com.apple.macl:
com.apple.quarantine: 0087;66a8fe82;WhatsApp;
```

The presence of `com.apple.quarantine` isn’t surprising since I downloaded the file from WhatsApp. This shouldn’t prevent the file from being backed up while the Mac is inactive though. `com.apple.macl` is a bit more involved. I haven’t fully wrapped my head around it, but I read that it is [related to System Integrity Protection (SIP) and was introduced with macOS Catalina](https://lapcatsoftware.com/articles/macl.html) and not really well-documented.

I tried to remove both extended attributes to see if it would fix the issue:

```
$ xattr -d com.apple.macl "/Users/aaron/Documents/[…]/WhatsApp Image 2024-07-30 at 16.52.33.jpeg"
```

The command succeeded, but when inspecting the extended attributes again, I noticed that `com.apple.macl` was back—presumably because of SIP.

Since only six files were affected, I stopped researching further at this point and went with a brute-force method: **simply rewriting the files**, which is a known method to get rid of the `com.apple.macl` attribute:

```
$ cp -X "/path/to/file" "/path/to/file.tmp" && mv "/path/to/file.tmp" "/path/to/file"
```

**The next backup succeeded, even though the Mac was locked.**

I put it in a script for future use (hopefully not required), or in case others face the same issue. It will preserve the creation and modification dates.

## Further Reading

- <https://www.stellarinfo.com/blog/fix-time-machine-waiting-to-complete-first-backup-issue-mac/>
- <https://blog.xpnsec.com/we-need-to-talk-about-macl/>