[Disclaimer: there are some very powerful commands mentioned casually here.  BE CAREFUL, I assume no liability for you recursively deleting or removing all permissions from your data.  Or for that matter, anything else as a result of a lack of caution or expertise!]

This was an interesting one.  Had a machine that kept having issues during Time Machine (TM) backups.  It completed the first backup successfully and then stalled on one of the next few backups.  In this particular case it’s multiple terabytes over a fairly slow connection so the first backup takes days.

Then it sits “preparing” for as long as you’d care to watch it.  First time this happened I monitored TM activity using Console.app and a backupd search string, nothing was really happening.  So then I stopped TM and tried to cleanup the .inProgress folder so TM could start over.  I was trying to force its recovery after (not completely covered) basic methods didn’t work.

This .inProgress folder completely refused to be deleted.  Nothing worked: started with rm -R and when it complained thought it was the usual system immutable flag.  That the file was locked.  Tried chflags -R nouchg and had no luck.  Tried some advanced variations of that, still nothing.

(Side note: this is my second round with this exact issue, the first time through I made sure the data was backed up elsewhere and formatted the drive, just for the sake of time efficiency.  Since the issue is back I have to address it head on.)

“ls -lahe” revealed files with ACLs set to deny access to everyone.  So I used chmod -RN to recursively remove all permissions.  I kept getting “chmod: Failed to clear ACL on file” and “Operation not permitted” despite being root.

So.  Hmmm.  I can’t remove ACLs prohibiting deletion on files which also have system immutable flags set, meaning I can’t change ACLs via any method.  I should mention that yes, I did check directory structure integrity way earlier in the process.  Taking a step back I realized this was a TM-created issue, so maybe tmutil can come to the rescue again.

Sure enough: Use tmutil listbackups just for verifications and then use tmutil delete snapshot_path [use actual path here sans brackets, e.g. /Volumes/ExternalBackup6TB/Backups.backupdb/ComputerName/2016-09-12-000400.inProgress/]

This returned the error “snapshot_path: No such file or directory (error 2)” AND YET in a separate session escalated appropriately “fs_usage | grep tmutil” showed the truth, that tmutil was furiously cleaning up all those untouchable files.  I later verified that the .inProgress folder had actually been removed.

Problem solved!  Hope this helps someone.  I love to hear when it does (tmutil@ this domain name) but if you’re too busy, no worries!