Time Capsule sparse image fails to mount (doesn’t exist?)

[Sonic Purity]

SD! 2.7.1, PowerBook5,6 (next-to-last 15" G4 PPC 1.67 GHz), OS 10.4.11

Trying to set up a network backup from this machine to our Time Capsule (whichever model was new/current as of January 2012). The machine is hooked up via Ethernet if it matters.

SD! shows that it has successfully created the sparse image and is ready to back up, so i start the backup. It fails in the second step of 1.:

“Failed to mount [name of my sparse image here]”

The SD! log shows:
Error | LOGGED EXCEPTION: FSGetVolumeInfo failed., reason: Unable to retrieve volume information, userInfo: (null)

Two iterations of that, actually.
Console log shows:

Sep 22 19:03:53 Doinkscratch-2 automount[143]: Cannot mount URL 'afp://S-S-TC.local.' for /Network/S-S TC (UI not allowed).
Sep 22 19:03:53 Doinkscratch-2 automount[143]: Attempt to mount /Network/S-S TC returned 1 (Operation not permitted)
2012-09-22 19:03:53.652 SuperDuper![1131] ***ERROR OCCURRED: ****FAILED****: result=256 errno=0 (Unknown error: 0)
2012-09-22 19:03:53.680 SuperDuper![1131] LOGGED EXCEPTION: FSGetVolumeInfo failed., reason: Unable to retrieve volume information, userInfo: (null)

2012-09-22 19:03:53.683 SuperDuper![1131] LOGGED EXCEPTION: FSGetVolumeInfo failed., reason: Unable to retrieve volume information, userInfo: (null)

When i look in Finder at the Time Capsule, i see two sparse bundles: one for the Time Machine backup for a different computer, and the other for the Time Machine backup for this computer, when booted off its alternate Leopard OS. I see no sign of the sparse image that SD! allegedly made and seemed to tell me that it made. The Time Machine backups are working just fine.

I’ve read the SD! manual and older forum posts on Time Capsule (not today, but in the last month or so). I have no idea why this is failing, and why i’m not seeing the image that SD! allegedly made (well…*had the OS make on its behalf).

Stumped,

))Sonic((

[dnanian]

Does your network drive have a password when you connect to the share? If so, make sure both the system AND user keychains have the credentials. You can do that with Keychain Assistant.

Hope that helps!

[Sonic Purity]

Does your network drive have a password when you connect to the share? If so, make sure both the system AND user keychains have the credentials. You can do that with Keychain Assistant.

Hope that helps!

Thanks. I do have a Time Capsule password. I tried your suggestion, but Tiger Keychain Assistant won’t cooperate:

* I cannot copy/paste the item between the login keychain and the System keychain: Keychain Access says the item is already there (but it is not visible under System, so i don’t think it actually is there).

* Export is grayed out, so i can’t even export and re-import the Time Capsule entry (the usual way people work around issues with the Tiger version of Keychain Access).

* Creating a new item in the System keychain does create the item, but it is assigned the category “Application password” rather than “AirPort base station password”. I am not at all confident that this item will work, not matching the one in the login keychain.

Also, remembering that this older version of Keychain Access (v. 3.3) has the following keychains:
login
System
X509Anchors

are you sure that System is the correct target? I’ve had to put S/MIME certificates into X509Anchors in the past to get them to work.

[dnanian]

Is the regular password for the share saved in Keychain? (Sorry about the misfire on Keychain - that's a recent issue with much later OS versions.)

[Sonic Purity]

Is the regular password for the share saved in Keychain? (Sorry about the misfire on Keychain - that's a recent issue with much later OS versions.)

Maybe? Here’s what i see:

* Looking at the Time Capsule item within Keychain Access (in the login keychain only), the password does exist there, apparently saved.

* Using Finder’s Network item in a Finder window and connecting to the Time Capsule from there, i have to type in the TC password (even though it appears in Keychain Access). Once i type the password in manually, there is no problem connecting to the Time Capsule and viewing its files in the usual Finder window.

Any further information i can pass along that would help?

Thanks.

[dnanian]

Maybe delete the Time Capsule entry in Keychain and see if you can get it to connect without typing the password? That password requirement is the problem...

[Sonic Purity]

Maybe delete the Time Capsule entry in Keychain and see if you can get it to connect without typing the password? That password requirement is the problem...

Apologies for disappearing for a few days… still doing some testing to see if there are further issues. I was waiting to provided a final report, but that may be many days out yet.

Thanks for the password requirement being the problem clue! It was the root of the problem. Instead of deleting the entry, i selected it (double click or single click to select then the I for info button) in Keychain Access, selected the Access Control tab, then added SuperDuper! to the “Always allow access by these applications” list. Once this change was made and saved in Keychain Access, i had no further problems with the sparse image mounting in SD! for backup.

All of what i’m doing is actually pre-testing for setting this up for a client. With this problem solved, i decided to test on a different Mac which is almost the identical model the client is using (G4 AGP, Tiger). Setting up on that system, i had no problem with SD! accessing the sparse image on the Time Capsule, and i did not need to manually do anything in Keychain Access. Part of the reason may be that i was re-using the pre-existing sparse image already on the Time Capsule from my first test, though i believe the true difference is that with the first test, i didn’t understand when the OS was asking for the Time Capsule password what it really wanted, since the authentication dialog also listed an OS X account name, which Time Capsule does not use. I believe that in the original test, i entered a user account password or something else incorrect, which somehow somewhere got stuck in the OS’s remembered settings and was preventing connection until i overrode it in Access Control. On the second test i knew what to fill in where, so the correct Time Capsule password got entered the first time, thus no need to override. That’s my theory, anyway.

Thanks for your help… all taken care of. I may or may not have further findings (possibly questions) on this process, which i’ll post in this thread or a new one as appropriate (for the benefit of others if i have no new questions).

[dnanian]

OK! Glad you're all set.