error -1017 (insufficient permissions)

[urza311]

I've run into the error message mentioned into this subject line, and I have a theory as to why it happens, but am looking for confirmation.

 

I have one machine on my network that is primarily responsible for doing network backups of several stations. This station has been upgraded to Vista... but I do not think this is the source of the problem. Here's how my system was setup previously.

 

BACKUP SERVER

* Windows XP Pro

* Retrospect 7.6.111

* has licenses to backup up to 18 clients

* has internal tape drive

* runs backups on desktop clients between 12 AM and 3 AM

 

DESKTOP CLIENTS

* Windows XP Pro

* Retrospect Client 7.6.106

 

LAPTOP CLIENTS

* Retrospect 7.6.111

* duplicates user folder to target folder on backup server sometime between 11 AM and 2 PM (staggered so two laptops don't access the backup server simultaneously)

 

Here's the deal... I have three laptops that are all running Outlook 2003. Since these laptops leave at the end of the day, I can't run backups on them in the middle of the night (if I could, I'd use the Retrospect Client instead). If I try to use the server to remotely backup a laptop using the client software while Outlook is running, it can never get the Outlook .PST file because it's in use. So I bought full versions of Retrospect for these laptops, and they do their own backups to shared folders on the backup server.

 

The desktop clients, since they never leave the building, are easier to deal with. Retrospect backs them up as remotes in the wee hours, and people just leave their computers on with all applications closed down, so it can access the Outlook .PST file without a problem.

 

The laptops duplicate their user folder to shared folders on the backup server (these are stored on a second internal SATA drive). When the backup server backs up a desktop client, it does a duplication of the user folder on their station to an unshared folder on this same SATA drive.

 

At 3 AM, the backup server backs up all the local clone folders to an internal AIT drive. The reason I do duplicates with all the clients instead of backing them up to files is because the vast majority of data never changes. So if a given client has 3G of storage in their user directory, of which 1G is the Outlook .PST file and 2G is pictures, documents, etc., then the duplicate only ever really has to nab the .PST file and maybe an odd document or two here. Then the clones on the local drive have very little changed, so when the tape drive backup kicks in later in the evening, it doesn't have to backup 3G of data for this client, but rather just 1G or so. This way, I can get all stations backed up every night onto a single tape every week.

 

Regardless of whether it's a laptop running its own copy of Retrospect, or the backup server duplicating a remote client, all duplication scripts are set to make duplicates without any rights (don't duplicate Window system state, don't duplicate Windows file security, etc.) -- I don't want folder permissions to become a snag.

 

For the three laptops backing up to shares on the backup server, each of these shares is setup as an open share (no username or password required to access or write files in the folder). Again, I don't want to deal with any permission rights issues.

 

So, in both cases, I get a permission-less clone of a station's user directory on the internal hard drive of the backup server, and that folder gets backed up to tape at night.

 

THE PROBLEM

I'm only running into this -1017 error with my laptop stations, and my testing has shown me it *only* happens if the execution is automatic. If I go to that laptop, launch Retrospect and manually run the script, it works fine every time. I have a suspicion as to why this is happening with my new Vista-based backup server, and why it might happen to other people (I've seen some other notes about this problem in the forum).

 

Under my original XP-based backup server, Retrospect on the laptops was set to copy files to a UNC-based destination, such as:

 

\\majordomo\targetbb

 

I named my backup server Major Domo, so it shares on the network as "majordomo". Each laptop station has its own target folder, so in this case it is "targetbb" for a laptop user who's initials are BB.

 

However, I found I ran into problems pointing to a UNC-based path on Vista from an XP client... most of the time, it would be unable to find the share and eventually timeout. So I changed the target on the laptop to be:

 

\\192.168.1.166\targetbb

 

Major Domo has a fixed IP address on my network, so that will never change. I can connect to this path using the RUN command on the laptop, or use it as a target in Retrospect for it to back up to. Works fine, and with no hesitation... immediately pulls up the share every time.

 

If I run the script manually, here's a rundown of what I see in the execution window.

 

* preparing for Open File Backup

* scans local folder

* scans remote folder

* preparing to execute

* runs the copy

* runs the comparison

* execution completes successfully

 

If I set the script to run, then exit Retrospect and sit there to watch it go, here's what I see:

 

* preparing to execute

* some text messages that flash by so fast I can't read them

* backup fails even before it scans the local folder!

 

Here's the log entry for the successful manual backup and the unsuccessful scripted backup. MY THEORY IS THE BACKUP FAILS BECAUSE I'M USING AN IP ADDRESS AS THE TARGET INSTEAD OF A UNC PATH. The laptop stations had been running Retrospect 7.6.111 just fine prior to me upgrading the backup server to Vista, so the only thing that's changed for them is really the target path. Can anyone corroborate this or counter it?

 

 

+ Duplicate using mimic-BB at 8/6/2008 3:57 PM

To volume targetbb on 192.168.1.166...

 

- 8/6/2008 3:57:14 PM: Copying becky on Boes (C:)

8/6/2008 3:58:08 PM: Comparing targetbb on 192.168.1.166

8/6/2008 3:58:08 PM: Execution completed successfully

Completed: 1 files, 1 KB

Performance: 0.1 MB/minute (0.1 copy, 0.1 compare)

Duration: 00:00:54

Exit at 8/6/2008 3:58 PM

 

+ Retrospect version 7.6.111

Automatically launched at 8/6/2008 4:00 PM

 

+ Duplicate using mimic-BB at 8/6/2008 4:00 PM

Can't access volume targetbb on 192.168.1.166, error -1017 (insufficient permissions)

8/6/2008 4:00:41 PM: Execution incomplete

Exit at 8/6/2008 4:00 PM

 

+ Retrospect version 7.6.111

Launched at 8/6/2008 4:00 PM

 

[Mayoff]

See http://kb.dantz.com/article.asp?article=9637&p=2 for correct NAS configuration.

[urza311]

The share requires NO access rights, as I mentioned in my email. The script runs fine manually; it does not execute under automatic execution.

 

If it did not work manually AND automatically, then I'd say you're right and there was a NAS configuration situation here. But that is not the case. If it works one way, it should work the other.

[Mayoff]

When a scheduled backup runs, Retrospect uses a different process. It is totally expected for the backup to work with an immediate backup but fail with a script. It is failing with the script because the authentication is not configured correctly as outlined in the KB article. I am confident this is the problem.

 

I have never seen a NAS device that doesn't have some type of username/password. Even if it is a factory default login.

 

In a workgroup, you should still be able to configure the RBU account for login as the local user. In a domain, you configure the RBU for login with domain rights.

[rschreiber]

You might check this out: http://forums.dantz.com/showpost.php?post/110547/

[MRIS]

An excellent post there urza, try changing your laptops so that they run retrospect within the context of a user account, rather than local system.

additionally/alternatively try fake usernames/passwords for accessing the vista box's UNC null-shares.