Apple would have us believe that macOS just works. If you don’t get notified of problems, everything’s just fine, isn’t it. In truth, macOS Sierra is very poor at warning us of problems, and the tools which Apple provides with it are also incapable of checking properly.

My example is a bug which has caused Time Machine’s automatic backups to fail to complete, but which was only revealed by my free tool T2M2. And it’s a problem which could affect anyone using both Time Machine and iCloud Drive.

This advanced Mac user first ran into Sierra’s scheduling and dispatching bug, which caused their automatic Time Machine backups to fail. That was only detected and diagnosed using T2M2, as, although Apple has known about this serious bug for over six months, macOS doesn’t warn users when automatic backups stop working properly: we’re expected to check for ourselves.

Having found a workaround which addressed that, the user started keeping a watch on their backups using T2M2, which seems a wise move. Not long afterwards, they noticed that automatic backups were failing again, this time because they never completed, in turn because of an apparently fatal error. The report provided by T2M2 was bizarre:
Started 1 auto backups, and 3 manual backups; no backup has been completed successfully in the period,
currently still making an auto backup
last manual backup started 12.0 minutes ago,
backed up a total of 32226 files, range 7495 to 9130 in each backup,
total data for each backup was 1.39 GB, 1.38 GB, 1.44 GB, 1.57 GB.
Created 0 new backups, and deleted 0 old backups,
8 errors reported:

So one automatic backup had been started but not completed successfully, even though it had backed up over 1 GB of data, and three manual backups had gone the same way.

The error messages quoted were of two types, repeated four times, once for each attempt to back up:
Error: (-48) SrcErr:NO Copying /Users/[username]/Library/Mobile Documents/com~apple~Pages/Documents/[filename] to /Volumes/[volumename]/Backups.backupdb/[destination]
Error: (-8062) SrcErr:NO Copying /Users/[username]/Library/Mobile Documents/com~apple~Pages/Documents/[filename] to /Volumes/[volumename]/Backups.backupdb/[destination]
(I have edited some content as shown in []).

A quick check on OSStatus.com shows that an error code of -48 is dupFNErr, meaning “duplicate filename and version”, but -8062 doesn’t appear to be a known error code.

So the error which was breaking these attempts to back up was the result of a source file having the same name as a file which had already been backed up on that occasion – something which should be impossible in HFS+, which does not permit two files in the same folder to have the same name and version. However, in this case the file causing the problem is not stored locally on an HFS+ volume, but in the user’s iCloud Drive, which is reported as ~/Library/Mobile Documents/.

I have no idea as to whether that particular file has a problem, but there is nothing that the user or I can do to fix issues like this in iCloud Drive. The best workaround, then, is for them to add iCloud Drive to their Time Machine exclusion list, using the Time Machine pane.

Having fixed the problem and restored normal automatic backups, the next puzzle is how this error could have arisen. iCloud Drive maintains its own file system, which is normally presented to the user as being fully compatible with both macOS and iOS. This has always been a bit of a problem, because iOS has used a case-sensitive file system, and macOS almost invariably uses a case-insensitive file system. When tested using beta-releases of APFS on Sierra, iCloud Drive acted to preserve compatibility with both macOS and iOS, and did not allow co-existence of filenames which differed only in case, much as HFS+ does.

One possible explanation of this problem is that the files causing the errors have been written to iCloud Drive from iOS running case-sensitive APFS, and that iCloud Drive has not enforced compatibility with HFS+ naming. This would then mean that Time Machine’s backup would try to write two files with case-insensitive names which were deemed to be identical. If that is the case, then further problems should be expected when trying to make backups of iCloud Drive files.

It is unfortunately very difficult, if not impossible, to investigate this any further, as iCloud Drive is a closed system with no diagnostic tools available to the user.

Some obvious conclusions:

• Don’t trust Time Machine or anything else that ‘just works’ to tell you when it is not working.
• Don’t think that Apple’s diagnostic tools are all you need.
• Don’t think that, just because Sierra made log access much harder, you don’t need to check your log.
• Using Time Machine to back up iCloud Drive can prevent backups from completing successfully.
• There may be incompatibilities in file naming between iCloud Drive and macOS.
• T2M2 and Consolation. They’re free from Downloads above.