Jump to content

1101 error when backing up to a file on peer network computer


Recommended Posts

Running 5.5 on local machine, I want to store my backup save set as a file on a remote machine in a peer to peer network. All machines are Windows 2000. File system on remote machine is shared with Everyone having full control. I am running Immediate Backup interactively on the local machine. I select the drive on the local machine to back up. I then select the location of the catalog to be on the remote machine in a shared folder (catalog is also the backup save set). It stores a short 2 KB file "Backup Set A.rbf" on the remote machine and then quits with "Error 1101 (file/directory not found)". I have no trouble creating and deleting oher kinds of files on the remote machine in the same folder, so the share seems OK. I have tried setting account / password various ways in the Retrospect Launcher service, but that makes no difference, and I would not expect it to, since this is an interactive job, not a Launch

 

What makes this even stranger is that I have tried exactly the same thing from another local machine on the same network, using the same backup machine and shard folders, and it works fine. I've checked network settings and can see no difference between machines. confused.gif

 

I have done chkdisk on all machines and found no errors. I have reinstalled Retrospect on the problem local machine twice. Administrator account is used for the install.

 

Is there another file, apart from the catalog, that it might be trying to create, and if so where would that be? The Retrospect user on the local machine has Administrator priveleges, so I don't understand how this could be a problem.

Link to comment
Share on other sites

Hi

 

Retrospect uses standard Windows filesharing to get to shared volumes so there has to be something about this particular user account or computer that is causing the problem. I would try it using the administrator account as a test. It may have something to do with the fact that there is no password on the remote volume. Set up another share that is password protected and configure Retrospect to log in automatically.

 

Nate

Link to comment
Share on other sites

Thanks, Nate. smile.gif

 

I was using administrator on the local machine and I had the remote share set up for total contol by everyone, so it should have worked. It did, in fact, work when coming in from another machine, but not this problem machine. I can't tell what makes the two local machines different.

 

The shares I created do not use passwords. I will try another share with passwords as you suggested. However, I do not know how to configure Retrospect 5.5 to log in to the remote machine with a particular username and password. Could you kindly explain that?

Link to comment
Share on other sites

Nate,

 

Thanks for the reply. Unfortunately, logging into a volume does not seem to work, at least on my computer as I understand it. Recall that I am running Retrospect Pro 5.5 on the local machine, and I am trying to push the backup to a file on the remote machine that has shared folders. There are two problems with logging in. First, I think 5.5 does not permit changing properties of volumes as you suggested. Second, when I identify the remote (network) volume and put it in the local Retrospect's volume database, it basically makes that volume available as a source for backups, not a destination. I do not want to backup the remote volume. I want to backup a local volume © and send the backup save set to a file in a shared folder on the remote volume. If I understand correctly, I should not have to log in to do that. This is beause the remote folder is shared. The remote machine is set up for share-level access, and logging in is not a possibility (or if it is, I cannot find out how to do it).

 

So, as usual, I am completely stumped. confused.gif Why can the OS on the local machine access the shared folder on the remote machine in all respects, but Retrospect cannot access it? Again it is made doubly confusing by the fact that that another local machine with a supposedly identical sharing access and peer-to-peer network configuration works with Retrospect in this fashion, and I cannot find any difference between the two local machines. Why should one work and the other not work?

 

This volume selection has not been a complete waste of time. It raises another possibility I had not considered. I might install Retrospect on the remote backup machine, define a volume there that resides on my current local machine, and have the backup machine pull the backup from my current local machine rather than push it, as I am now trying to do. One backup machine pulling from two other machines rather than two machines pushing to the backup machine. Does that make sense?

 

I have never used the client in all of this. Do I need to install the clients before I can have the backup machine pull files?

 

Even if the above works, I am still puzzled as to why I cannot use the pushing technique that I have been attempting. As I see it, the remote shared folder is just another place to put a file, and it should work. Is there something else that could be going wrong that has nothing to do with access to the remote shared folder? Like writing another file somewhere else? Could we be barking up the wrong tree?

Link to comment
Share on other sites

Hi,

 

I have seen this kind of thing before and it always boils down to Windows permissions either being corrupt or just setup differently. The client gives you full access to a machine including the ability to backup and restore the registry- file sharing can't do that.

 

All in all clients are the easiest way to go. I like your work around though- it is probably the best way to take care of this.

 

Thanks

Nate

Link to comment
Share on other sites

Hi,

You mention in your post that it is a "peer to peer" share. Have you tried mounting the share as a drive (in windows, using 'map network drive' in the explorer tools menu) on the 'push' computer prior to running retrospect. Windows can see files and work with them easily without the mapping however i have found retrospect can have trouble using destinations not mapped as a drive.

Glenn.

Link to comment
Share on other sites

Yes, thank you, I did try mapping it as a drive, and it made no difference. Retrospect always fails (1101), and Windows always works to create files on the remote drive. Another push computer with what i think is an identical configuration works with Retrospect without the drive mapping.

 

I should state again that Retrospect does create a small 2 KB file, "Backup Set A.rbf", on the remote drive before it fails with the 1101 error. This leads me to conjecture that it may not be the catalog / save-set file itself but something else that is hanging. Perhaps it is a log file or something. The 1101 error does not specify either the file name or the location of the file that is giving trouble. The error message is not very helpful. frown.gif

Link to comment
Share on other sites

Ok how about this...

 

As a test can you sucessfully save the backup file on any other shared volume on the network? That will at least help us narrow this down.

 

As a workaround you can install Retrospect on another machine and install Retrospect client on this machine that is causing problems. That way you can get a full backup and still store you backup file on the file share of your choosing.

 

That help?

 

Nate

Link to comment
Share on other sites

Thanks, Natew. Yes, that helps. Let's call the troublesome local computer A, the backup computer B, and another local computer C. I was able to save the backup set from A onto another shared volume on a differerent computer C. I cannot save the backup set from A to any volume on the backup computer, B. I can save a backup set to the backup computer B from the other local computer C. So it looks like computer A has the problem.

 

In addition, I observe that computer A maintains a list of folders visible at the top level in the "My Network Places" that computer A previously accessed by a share. I cannot delete those pseudo folders (shortcuts?), even if the folders and/or the shares no longer exist. I'll conjecture that this retention of old folders in the list is the cause of a confilct. Any ideas how I can make that retention behavior go away?

Link to comment
Share on other sites

Hi

 

I believe those old connections are stored in the nethood folder. That folder is unique to each user so you could try creating a new user account and going from there. You could also just delete them and see what happens.

 

You may also want to create a different login account on the destination machine and try connecting with that new login information.

 

Nate

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...