I seen this message for the past two days:

"Time Machine detected that your backups on “SynologyDS216.local” cannot be reliably restored."

"Time Machine must erase your existing backup history and start a new backup to correct this."

I can access the backup history just fine. The NAS (which have RAID 1) is fine as well.

When I look at the backups:

~ ᐅ tmutil listbackups | tail -n 5

We can see that it stopped doing backups exactly 2 days ago, so I decided to do a check:

tmutil verifychecksums /Volumes/Time\ Machine\ Backups/Backups.backupdb/Thomas-MBP

and an error that popped up is:

/Volumes/Time Machine Backups/Backups.backupdb/Thomas-MBP/2020-07-08-200220/Macintosh HD/System/Library/DirectoryServices/DefaultLocalDB/Default: error 257 enumerating path

The directory exists:

total 0
drwxr-xr-x@ 3 root  wheel   102B Aug 25  2019 .
drwxr-xr-x@ 5 root  wheel   170B Sep 29  2019 ..
drwx------+ 7 root  wheel   238B Aug 25  2019 Default

but the permissions are an issue. This file has extended attributes, so I look to see what's up:

/Volumes/Time Machine Backups/Backups.backupdb/Thomas-MBP/2020-07-08-200220/Macintosh HD/System/Library/DirectoryServices/DefaultLocalDB ᐅ sudo ls -le Default
total 0
drwx------@ 2 root  wheel   340 Aug 25  2019 aliases
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwx------@ 2 root  wheel   102 Aug 25  2019 computers
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwx------@ 2 root  wheel  4420 Aug 25  2019 groups
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwx------@ 2 root  wheel   102 Aug 25  2019 networks
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwx------@ 2 root  wheel  3468 Aug 25  2019 users
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown

When looking on the host machine:

/System/Library/DirectoryServices/DefaultLocalDB ᐅ ls -l

    total 0
    drwxr-xr-x  3 root  wheel    96B Jan  1  2020 .
    drwxr-xr-x  5 root  wheel   160B Jan  1  2020 ..
    drwx------  7 root  wheel   224B Jan  1  2020 Default

the permissions are not the same and the data can be accessed.

It looks like TimeMachine claims it can't use the backup due to some permission issues...

I tried to ask about it on the Apple forums but my post got removed because I'm running a beta version of the OS...

Has anyone seen this problem before?


“Has anyone seen this problem before?”

I have, and from what I have heard from reading forums over the years, it sounds like a very common problem with Time Machine: every once in awhile, it says “I need to delete your backup and start over.”

Or it says “I can’t backup because your backup device is full” (even though Time Machine is supposed to prune itself as needed).

Or something else comes up that causes Time Machine to choke.¹

Howard Oakley has cataloged a long list of issues with Time Machine, and even has some free apps to help work with Time Machine archives (unfortunately, nothing that can “repair” a “damaged” Time Machine backup, as far as I know).

In response to this I have developed the following attitude towards Time Machine:

  1. Never rely on Time Machine as your only backup.

  2. Use Time Machine to multiple locations (e.g. a Time Capsule or other remote Mac plus a local Mac) with the expectation that if one gets corrupted, you will still have the other one. Note that Point #1 still stands, even with Point #2

  3. In addition to Time Machine, also use at least one (preferably two) of:

¹ This is usually where someone will chime in and state that they have used Time Machine since it was first released and never had a problem with it. I do not doubt that there are some people who have had that experience, but I tend to consider them sort of like people who win the lottery: I am happy for them, but I would never expect to be one of them, and have decided to assume I never will be. YMMV.

  • 2
    The link you give for Howard Oakley gives a general page that includes an article on Covid-19 a better link would be useful – mmmmmm Oct 17 '20 at 21:30
  • 1
    How about Howard Oakley's Mac Troubleshooting Summary -- it has a "Time Machine problems" section (that's not directly linkable, unfortunately). – Gordon Davisson Oct 17 '20 at 23:24
  • I have updated the link to go to eclecticlight.co/tag/time-machine – TJ Luoma Oct 18 '20 at 5:24
  • I have three drives that failed this way and I’ve chosen to make them inactive, offline storage. I can get data off them, but I still use TM with two drives in rotation. I’m not “lottery lucky” but I don’t have a problem with how TM works. I think the people that are OK with it made peace with design limitations and have a process to detect errors and live with failures. – bmike Oct 18 '20 at 20:19

This happens for a simple reason. Network errors get flagged as hard drive errors, making NAS destinations too fragile for use. Don’t waste your time on any NAS that says they support Time Machine unless you can get them to actually support you when you get errors like this. When you call them, they will point their finger at Apple and Apple doesn’t support Time Machine to anything but a physical drive now.

Apple built in a failure detection mechanism and when you have too many minor errors, any drive is flagged as unreliable for adding new backup intervals and you are forced to make a decision.

  1. Keep the drive in read-only mode. The data there is fine for a restore, but no new backups can happen. Put it on the shelf in case you have to restore data from when it has data, but put a new drive in the rotation to do new backups.
  2. Erase the drive to start a clean slate. You lose the history, but you can then see if the drive passes the tests and can store new data safely and reliably.

If you must back up to NAS for reasons, also back up to an attached drive occasionally so when the NAS fails you, you can erase it and start fresh.

  • 1
    The backup goes to a RAID1 array and the disks pass the long SMART test without any problem. So the issue is not hardware, but rather how the data was written. The backup files represent a file system which opens properly as well, so the data is intact (= as it was written). What I don't understand is the extended attributes inside the backup's file system: it takes a request from TimeMachine to set those and they don't exist on the same folder in the OS; furthermore, that folder is a readonly folder in MacOS so I don't even understand why it is part of the backup. – Thomas Oct 18 '20 at 20:23
  • This happens often to me when the TM is on a NAS - the disks are fine. – mmmmmm Oct 18 '20 at 20:36
  • Yes @Thomas - it’s not that the drive it bad, the logical consistency is bad. Also, never back up time machine to a network volume, never in my experience. I’ll address that with an edit. I think you will have better experience if you ditch Time Machine or ditch the destination of NAS. Two can’t work well together. Read up on this site all the pain and woes backing up to time capsule and NAS. Synology makes great devices and I just don’t understand why they don’t rip out the TM option. – bmike Oct 18 '20 at 20:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .