Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the '10.5: Repair Time Machine after logic board changes' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.5: Repair Time Machine after logic board changes
Authored by: palahala on Dec 15, '08 02:05:56PM

A long story for the sake of Google et al:

  • On my MacBook, which uses its built-in AirPort to connect to an AirPort Express (which is then wired to a Mac Mini, to which a USB disk named "TM" is attached for Time Machine) actually the MAC-address of the ethernet port is used (though not active!), not the Mac address of the built-in AirPort (which is active). In fact, it's easy to tell: temporary rename all the dot-files and you'll see that Time Machine creates a new one for the MAC-address it's using (and on my Mac, the timestamp of that file is always June 15 2008).

  • I removed the password while my MacBook was in repair, and when sudo prompts for the password then hitting Enter (for an empty password) seems to cancel the sudo command without any error...? Setting a password again solved that issue. So, always validate that the new MAC-address was set: after "sudo xattr -w com.apple.backupd ..." always run "xattr -p com.apple.backupd ..." again!

My MacBook was in repair for quite some time and meanwhile I had restored the Time Machine backup to the Mac Mini. On that Mini, I used to have a guest user with the very same name of my MacBook user, just for the backup. This made the restore to the Mini a bit cumbersome (restoring a user account which already existed as a limited account...), but I managed. However, when the MacBook returned home it only had read access to the opened sparsebundle (now that I am writing this: maybe that is because that Mac Mini user now also has an empty password -- can't verify that now). This caused some problems after taking the steps from the above hint:

  • When manually mounting the remote disk using the new credentials then after "Network mountpoint /Volumes/TM not owned by backupd... remounting" I would get "[SnapshotUtilities remountVolumeRef] url could not be resolved via BonJour", "Failed to remount network volume", "BackupCore -- _CSBackupServerProxyCopyDestinationMountPoint returned: 19" and "Backup failed with error: 19".

  • Manually mounting using the new credentials, and then setting up Time Machine to use that volume for the backup, would make no changes.

  • When not manually mounting the disk, then choosing "Backup now" would give me "FSMatchAliasBulk returend -5032 while resolving alias to backup target".

  • In all cases Time Machine itself would not show any history (it would only show Today).

So, I backed up the sparsebundle and then opened the sparsebundle myself, and changed the access rights for "staff" or even "everyone" to "read/write". Running those changes took over 24 hours to complete, and did not solve the issue.

But the solution was simple... To tell Time Machine to use other credentials one needs to clear the network passwords in Keychain -- but until today I did not know that in Keychain's menu View there's an option "Show Keychains", which is required to allow for selecting "System" (it defaults to "login") when searching for the old passwords to change (or simply delete to be prompted for new credentials)...

After that Time Machine showed the full history again, and running "Backup now" got me "Event store UUIDs don't match for volume: Macintosh HD" (which I don't understand) followed by "Node requires deep traversal:/ reason:kFSEDBEventFlagMustScanSubDirs|kFSEDBEventFlagReasonEventDBUntrustable".

Seems to work fine now!



[ Reply to This | # ]