-1101 Error

[jayataltair]

I upgraded to 8.1.148 this week. I just did a copy of my primary boot drive and all went well. When I tried a backup of an NAS drive that I backed up last week without a problem, Retrospect returned an -1101 error. It claims it cant' find the directory. The volume is accessible and I have it mounted now.

I stopped and restarted Retrospect Engine. I ejected and remounted the NAS drive. No help. How can this be fixed?

 

Jay

[jayataltair]

As additional information, I was able to verify the NAS volume that has the -1101 error (unable to access)

[Mayoff]

Can you browse files from the Source screen?

[jayataltair]

No. It returns a message saying the source is not available.

 

The volume appears in the source screen with a green check mark next to it. The summary tab shows it was last backed up on 7/3/09.

 

Jay

[Mayoff]

If you remove that volume and add it again, what happens?

[jayataltair]

It tells me "This volume already logged in:. This is after I removed it from the source list. However, in the script area, it is removed from the source list.

 

When I made a new backup script, it was able to access the NAS drive and is now scanning it. I'll let you know when the backup is done.

 

Jayt

[jayataltair]

Thanks for your assistance. The NAS drive was scanned and backed up. I guess the path to the drive or that source was corrupted in the upgrade somehow. All appears well now and I have a new fix trick to try the next time.

 

Jay

[Tree]

I found this thread, as containing the most pertinent situation to my own particular frustration. I've had a bunch of daily and weekly scripts running along fine, but just last night they all started failing. Why? Because all the catalogs are kept on a Volume called "Backups" that is not a local drive but rather a mounted network share. Suddenly, this share, which has been being used for months, is unavailable.

 

I actually had this happen to me when I updated to 8.1.148 last month, and somehow figured out that the solution was to re-add the shared source; at that point, I could go to each Media Set and "Locate" its catalog, because the share would show up and let me choose it. Until I re-added the share, though, I had the same thing I'm seeing now, in that when I go to Locate a media set's catalog, my only option is my local hard drive, and if I scroll down to Volumes and click its disclosure triangle, it tumbles down to show me... nothing.

 

So, here I am, trying to get the shared Source "Backups" re-added, so I can go through and (one by one) Locate all the catalogs again, just to return Retrospect to running exactly as it has been for weeks. Except it cannot cannot CANNOT be done.

 

On Sources screen, I click Add, then Add Share, and type in the afp://etc. name and login credentials. Double check to make sure it's all accurate, then click the button, and wait for a nice long time while nothing but a spinning icon happens. Finally, I get a friendly red message "This volume is unavailable."

 

Okay, so let's try unmounting the volume from desktop, in case there's something screwy going on with the OS. And, let's shut down Retrospect Console, stop the engine. Now, remount the volumes to desktop, fire up engine, launch Console and try it again. "This volume is unavailable." Anything that was overlooked? Oh sure, let's do all that over again, only this time let's also kill the ethernet connection and then reestablish with a fresh DHCP license. Try to add the share again, "This volume is unavailable."

 

The volume in question resides on a machine with its own Retrospect Client; I have it successfully declared as a Favorite folder for use on scripts that back up that machine. There's no problem accessing the volume that way, i.e. via the client rather than as "[localmachine]/Volumes/Backups-1". However, I have no option to Locate the Media Sets as being on that client.

 

So I am utterly dead! And nothing, nothing NOTHING AT ALL changed from yesterday to today, it's just that Retrospect no longer thinks the volume it's been using for weeks is available to it. The computers in question haven't even been powered off in that time... they weren't even put to Sleep, aside from their displays!

 

I'm wringing my hands trying to come up with a way to Add a shared source, but I just can't make it happen. And the only reason I even need to do this is... I don't know, I don't have a good answer for why I should need to Add a source that I've been using for many weeks, just to get Media Sets to work that have been working every day right up to last night. It's like 2+2 suddenly started equalling 5, and I'm trying to convince the computer telling me so that, no, 2+2=4 and always has.

 

Is there anything at all that I can do, besides gripe?

 

EDIT:

GRIPING PHASE COMPLETED. Solution possibly found... the "afp://Server_name/share" requires the long name as discovered by doing Get Info on the mounted volume. I.e. mount the volume to desktop, Get Info, and copy its address as disclosed there. There's a bunch of "afpovertcp" stuff following the Server_name that has to be included.

 

So that can get me far enough that I can Locate all the media sets again. But still, why should I have to do this? GRIPING RESUMED.

Edited July 24, 2009 by Guest

[CallMeDave]

I found this thread, as containing the most pertinent situation to my own particular frustration

 

That's odd, as this particular thread has very little information in it, and what information it does contain does not seem to match your report (you don't mention getting a "This volume already logged in" error as the original poster did).

 

I'd say a better thread is this one, that you yourself started about two weeks ago:

 

http://forums.dantz.com/showtopic.php?tid/31101

 

 

As you report above:

"...the catalogs are kept on a Volume called "Backups"..."

 

Yet later you reference the path to the volume as:

 

""[localmachine]/Volumes/Backups-1"

 

Other threads have clearly stated that there's some interaction with OS X mounted volume naming activity, where numbers are appended to volume names.

 

So while you claim that nothing has changed, you don't use the necessary tools to see what's really going on.

 

I don't have a good answer for why I should need to Add a source that I've been using for many weeks

 

If the path where Retrospect expects to see the volume is no longer valid (say its "/Volumes/Backups-1" instead of "/Volumes/Backups") then Retrospect won't be able to see the volume (since it's path is no longer valid). And since the OS can cause a modification of the mounted name of a volume, Retrospect can get stuck.

 

Use the "mount" command in Terminal to see what volume names are really mounted on your machine (in this context, "mounted" has nothing really to do specifically with the Finder or what you see on your Desktop).

 

Dave

[Tree]

That's odd, as this particular thread has very little information in it, and what information it does contain does not seem to match your report (you don't mention getting a "This volume already logged in" error as the original poster did).

 

I'd say a better thread is this one, that you yourself started about two weeks ago:

 

http://forums.dantz.com/showtopic.php?tid/31101

 

I initially thought that I was facing the same issue I did when I started that thread, and so was trying to take the same steps (i.e. re-add the source, thus producing the "already logged in" message). However, when I was unable to do so, I went hunting and found the suggestions in this thread, which call for removal prior to re-adding. I removed, I tried to re-add, couldn't do it. Now I've got a broken setup - I've got no source, rather than an "unavailable" one, which might mean screwed up scripts, etc. I would have loved to be at the "already logged in" message, as I'd already once dealt with things from that point forward. I edited my post once I did get back to that point, to just reiterate a gripe about having to go forward at all; if the source is already logged in then why am I having to locate the catalogs?

 

As you report above:

"...the catalogs are kept on a Volume called "Backups"..."

 

Yet later you reference the path to the volume as:

 

""[localmachine]/Volumes/Backups-1"

 

The volume is in fact named "Backups". Retrospect insists on accessing at as "Backups-1" due to the way the OS handles multiple applications mounting a volume; I get that. My point is that I'd prefer to access the volume via the Retrospect Client that resides on the remote machine, rather than having to mount the volume locally (local to the Engine I assume) in order store catalogs there. Maybe there's some valid reason why Retrospect prefers to store catalogs on a locally available (mounted) volume and not to trust communication with a remote client for that purpose. But it seems to me that the way the OS can screw things up for Retrospect by appending those numbers to volume names means that a mounted volume is less reliable than the Client; at least Retrospect is in total control of what the Client does, right?

 

Your response towards the end points me in a direction, as to why scripts that ran fine one night might fail the next - the volume that contains the scripts might have been assigned a new name by the OS for some odd reason, i.e. that it isn't Retrospect's doing. I don't care about assigning blame, I'd rather know the solution to prevent it happening again, and I just hope that this is an issue being looked into for future bug fixes.

 

[CallMeDave]

I'd prefer to access the volume via the Retrospect Client that resides on the remote machine ... in order store catalogs there.

 

Well, you can't.

 

Retrospect needs to store it's catalog files either on the machine where the Engine is running (best case) or on an available network attached storage device (possibly the best case too, depending on the setup). Retrospect has never been able to read/write from a Catalog file via the client communication protocol.