Is there any indication that Apple is trying to fix this bug? If the backup is getting corrupted, only Time Machine is writing to the backup disk; it's used for nothing else. Apple seems to have abandoned their excellent error message rules since I worked there in the '90s (and contributed to Apple's near death experience): Say what went wrong, why it went wrong, and what to do to fix it. In this case the API is giving an error code not passed back to us (translated to English in this case). There's not much that can go wrong when creating a folder, e.g., disk full, out of memory, bad name, wrong permissions, etc. Time Machine is supposed to take care of all this for us. BTW, Disk Utility finds nothing wrong with the disk being backed up.
In most cases where a simple repair disk doesn't help, it's either disk full or a hardware problem. If the disk is chock full (doesn't have room to create the backup folder), TM normally crashes instead of sending that message.
Look in the system.log or kernel.log at the time of the problem. There may be an I/O or similar message.
Log says error 22 setxattr. Neither disk is anywhere near full. Disk Util runs fine, says there was no problem with either disk, and then Time Machine works fine for a few hours to a few days, then the same error occurs, I run Disk Util, etc..... So what does 22 setxattr really mean? Sure, some extended attribute of some file or folder can't be set, but in English? :-) Thanks for the help, but isn't there the remote possibility that Apply has a bug?
Ron Voss wrote:
Log says error 22 setxattr.
We need the whole message (actually, all the messages from that backup). Use the widget in #A1 of Time Machine - Troubleshooting.
Thanks for the help, but isn't there the remote possibility that Apply has a bug?
If there were a general bug, there would be thousands of posts.
3/9/12 8:54:19.284 PM com.apple.backupd: Starting standard backup
3/9/12 8:54:19.331 PM com.apple.backupd: Backing up to: /Volumes/TM Backup/Backups.backupdb
3/9/12 8:54:19.423 PM com.apple.backupd: 2012-03-09 20:54:19.421 FindSystemFiles[89456:f07] Looking for system packages
3/9/12 8:54:19.663 PM com.apple.backupd: 2012-03-09 20:54:19.662 FindSystemFiles[89456:f07] Using system path cache v`57'.
3/9/12 8:54:19.943 PM com.apple.backupd: Error: (22) setxattr for key:com.apple.backupd.HostUUID path:/Volumes/TM Backup/Backups.backupdb/RonViMac3h size:37
3/9/12 8:54:19.952 PM com.apple.backupd: Error: (22) setxattr for key:com.apple.backupd.HostUUID path:/Volumes/TM Backup/Backups.backupdb/RonViMac3h size:37
3/9/12 8:54:21.766 PM com.apple.usbmuxd: _SendAttachNotification (thread 0x7fff75990960): sending attach for device 78:a3:e4:35:b5:d2@fe80::7aa3:e4ff:fe35:b5d2._apple-mobdev._tcp.local.: _GetAddrInfoReplyReceivedCallback matched.
3/9/12 8:54:22.581 PM usbmuxd: _AMDeviceConnectByAddressAndPort (thread 0x101981000): IPv4
3/9/12 8:54:29.964 PM com.apple.backupd: Backup failed with error: 2
3/9/12 8:54:34.965 PM com.apple.usbmuxd: _SendDetachNotification (thread 0x7fff75990960): sending detach for device 78:a3:e4:35:b5:d2@fe80::7aa3:e4ff:fe35:b5d2._apple-mobdev._tcp.local.: _BrowseReplyReceivedCallback got bonjour removal.
Ron Voss wrote:
3/9/12 8:50:28.215 PM com.apple.backupd: Error: (22) setxattr for key:com.apple.backupd.HostUUID path:/Volumes/TM Backup/Backups.backupdb/RonViMac3h size:37
Drat. That's usually some sort of drive problem. Or, more likely, a sleep/wake timing problem.
Try setting System Prefs > Energy Saver > Put the hard disk(s) to sleep... to OFF.
See if there's a firmware update for the drive.
See if there's a way to modify/defeat the spin-down timing.
Got another drive, even to test with?
See the following threads:
Message was edited by: Pondini
Thanks, it does seem it could be related to spin-down. As one thread said, Time Machine worked fine with 10.6.8 and started failing immediately with 10.7 with this drive (a wonderfully quiet and tiny Verbatim 2TB), hence my belief that Apple broke something. I found no drivers at all on the Verbatim site. I'll look for a spin-down preventer; hard disk sleep is already off. Thanks again.
All of this information is well and good, but while I get the same error:
Error: (22) setxattr for key:com.apple.backupd.HostUUID path:
a restart of the computer always fixes it. The sleep issue may be a factor, but I've had the same drive/computer/OS combination now for more than a few weeks, and this problem only started hapenning in the past week. I don't know anything that has changed within the past weekor two to explain the mysterious behavior.
Thanks for any thoughts.
It seems like this failure is somewhat random; TM works and then it doesn't. A week after adding the crontab entry I've had no more failures like that. If you mean disk spin down instead of computer sleep I'd be really curious if this crontab line would fix your case as well (and you wouldn't have to restart!).