One of the more distressing Time Machine errors is Error 11. This is a "sticky" error; once it occurs, Time Machine will hit it every time it runs. All you'll see in the standard Time Machine interface is that Time Machine keeps failing. You need to check the system logs to see the Error 11.
The underlying cause of Error 11 appears to be some other error that caused an earlier Time Machine run to terminate without cleaning up after itself. This leaves behind a partial file that indicates to Time Machine that another copy of Time Machine is already producing a backup, so it just stops.
Colin Charles worked out the basic problem and solution, but his description only seems to apply to locally-attached disks. For network-mounted disks, where you've got an additional level of sparsebundle in the way, things are a bit more complicated. Read on for the solution...
Here are the steps needed to recover from the problem:
- Stop Time Machine in the System Preferences panel.
- Mount the remote disk for read/write access.
- Open Terminal and run the following command: sudo -s. Enter your admin password when prompted. This will create a root shell for the remaining Terminal commands (even though not all commands need root privileges).
- Enter these commands:
$ cd /Volumes
$ ls
You should see your remote-mounted disk here. For simplicity, let's say it appears as Backup. - Type ls -ls Backup. You should see a .sparsebundle file with a name based on your machine's name and hex MAC address. I'm not sure exactly how these names are constructed, but for simplicity's sake, I'll pretend the name is mymachine.sparsebundle. Check that root has both read and write access to this file. If not, you probably mounted the disk with read-only access.
- Type hdiutil attach Backup/mymachine.sparsebundle/ -noverify -noautofsck -readwrite. This command, which must be typed on a single line substituting the name for your sparsebundle file, mounts the actual backup image. It will take a bit to finish. (Without the -noverify and -noautofsk options, it can take hours! The -readwrite option is probably the default.)
- Type ls -ls. There should now be an additional volume visible. Again, I'm not sure the name is always constructed the same way, but it will probably look like TM-backup-of-mymachine. Root should again have read/write access.
- Type fsaclctl -p TM-backup-of-mymachine/ -d. The backup directory has an access control list (ACL) that prevents any modifications. This command disables ACL enforcement on the file system. Note that if you leave off the -d, fsaclctl will tell you if enforcement is on or off.
- Type pushd TM-backup-of-mymachine/Backups.backupd, then type ls. You should see a file -- usually just one -- with a name based on your machine, though typically with upper and lower case. Let's assume MyMachine is the right directory here.
- Type cd MyMachine, then ls. You should see a number of files with names encoding a date and time. (These are actual backup subdirectories.) The last one should have a date and time followed by .inProgress as its name. This file is the cause of the problem.
- You can delete the .inProgress file (it's a directory, so you'll need to delete the contents, too), but what I did, just for safety, is to rename it by sticking an x- in front of its name. It turns out that Time Machine will clean up any mis-named files in this directory later. If you get an "Operation not permitted" error, you probably didn't execute the fsaclctl command properly.
- Type popd; this will get you back to the /Volumes directory. (If it doesn't, just cd there directly.)
- Type fsaclctl -p TM-backup-of-mymachine/ -e. This will re-enable ACL enforcement. (This step may not be needed -- I think the ACL setting isn't stored, but only applies until dismount. But it can't hurt.)
- Dismount the TM-backup-of-mymachine volume first, and then the Backup volume. It's easiest to do this in Finder -- for some reason, umount complains that the file system is busy. In the shell window, you can use ls to check that the two mount points are gone.

