Jump to content

Networked Backup File Reading Problems (error -5000)


Recommended Posts

I am running Retrospect version 6.1.126 on a Macintosh G5 1.8 dual with 2.5 gb of RAM running OS 10.4.3. I am using an external firewire 800 hard drive for the backup files.

 

I am using the network backup feature to backup a Macintosh G4 733 with 1 gig of RAM running OS 10.4.3. The G4 has Retrospect Client 6.1.107 installed. The G4 has two internal hard drives. The G4's main hard drive is named Snoopy. The two machines are connected with an ethernet gigabit switch which is connected to a router.

 

The automatic backup runs and most of the backup is done successfully.

However, in the Retrospect log I get the following error.

 

1/19/2006 4:00:15 AM: Copying Snoopy…

While scanning volume Snoopy,

Volume root Snoopy/,

Scanning incomplete, error -127 (volume corrupt?).

Can't read file “.hotfiles.btree”, error -5000 (server: no privileges), path: “Snoopy/.hotfiles.btree”.

Can't read file “DirectoryService.plist”, error -5000 (server: no privileges), path: “Snoopy/Library/Preferences/DirectoryService/DirectoryService.plist”.

.......

Can't read file “vpnd”, error -5000 (server: no privileges), path: “Snoopy/usr/sbin/vpnd”.

 

(46 files total are listed with this same error)

 

I believe that this may be a permissions issue.

I have run Repair Permissions on the affected hard drive.

I have used the latest version of DiskWarrior to repair this drive.

I let the backup script automatically mount the remote drives. In other words when Retrospect starts the backup the remote drive is not mounted. (this fixit was suggested in one post I have read.)

In Activity Monitor on the G4 the process "pitond" shows that it is running under user "root".

 

With a different backup script I am able to use Retrospect on the G4 to back it up successfully to an attached external firewire hard drive. In other words I can back it up locally, not over the network.

 

What can I do to fix the problem of Retrospect not be able to read these files?

Link to comment
Share on other sites

Quote:

The G4 has Retrospect Client 6.1.107 installed

 


 

If the G4/Snoopy is running the Retrospect OS X Client software, there is no need to access its volumes via filesharing.

 

Change your Source to use the machine as it's listed under "Backup Clients" instead of the volume under "Local Desktop."

 

Dave

Link to comment
Share on other sites

I followed the sequence of actions in article 1144.

article 1144

Logging in as root and then configuring Retrospect to mount the other computer's volume automatically.

 

This made no difference.

I still have the same errors for unreadable files.

 

I welcome other suggestions.

 

Article 1144 outlines the steps required to backup data stored on an AFP (AppleShare) volume and the steps for saving a File Backup Set to an AFP volume for use as a destination. (Technically, I am saving the Backup Set and the Backup file to a local disk)

Link to comment
Share on other sites

See this link to read from the beginning of the thread

link to the beginning of this thread

 

I am now having a reoccurrence of remote backup not being able to access some files on another machine running Retrospect Client. I thought that changing my Source to use the machine as it's listed under "Backup Clients" instead of the volume under "Local Desktop." seemed to have fixed my problem with permissions.

 

However "error -5000 (server: no privileges)" errors have been starting to occur again. Strangely the number of these errors have been increasing with time. This backup runs each night at 4:00am.

 

Date and number of files showing a error -5000 (server: no privileges)

 

1/19/06 0 files, 1/20/06 1 file, 1/21/06 2 files,

1/22/06 2 files, 1/23/06 5 files, 1/24/06 10 files,

1/25/06 10 files

 

Any suggestions on what to do?

Link to comment
Share on other sites

After posting of the file error problems, I went and again use Dave's advice and again

Changed my Source to use the machine as it's listed under "Backup Clients" instead of the volume under "Local Desktop."

 

Lo and behold the backup on 1/26/06 had no errors. However I do not want to have to go in and change the Source everyday. The beauty of automatic backup is that you don't have to do anything every time a backup needs to occur. The need to weekly tweak the settings would be a drag.

 

So I'm curious what is going on. Suggestions?

Link to comment
Share on other sites

Quote:

Lo and behold the backup on 1/26/06 had no errors. However I do not want to have to go in and change the Source everyday. The beauty of automatic backup is that you don't have to do anything every time a backup needs to occur. The need to weekly tweak the settings would be a drag

 


I don't understand what the problem is with using clients as your backup sources in your automatic scripts. A script can be created with any combination of clients and local volumes as sources, and be scheduled to run forever without requiring any manual intervention or tweaking.

 

If the issue is that you're also backing the clients up via local desktop, the solution is to use specific local volumes as backup sources, rather than backing up the entire local desktop.

Link to comment
Share on other sites

Hi.

 

I don't quite understand why you would have to change the source every day. Are you using a script? Then set the script to:

1) Backup only your LOCAL drives (not your "Local Desktop", which includes mounted server volumes).

2) Backup the clint's LOCAL drives (which is the default for the clients).

 

Or am I missing something?

 

Regards

Lennart

Link to comment
Share on other sites

I am using two automatic scripts. One is local and is working fine. The other script is remote and its source is set to the client's local drives. This remote script is the one that has had intermitent problems with accessing certain files. When the automatic script runs, sometimes certain files cannot be accessed "error -5000 (server: no privileges)" and backed up.

 

The error log shows me when this happens and it has been frustrating to have the script work perfectly one night and then not work the next night.

Link to comment
Share on other sites

I see. Thanks for the clarification.

 

-5000 is normaly issued when a user has exclusive access to a file when another user (in this case the Retrospect client) tries to read the file at the same time.

 

What kind of applications are the users of the server running? What kind of files are locked?

Link to comment
Share on other sites

Quote:

-5000 is normaly issued when a user has exclusive access to a file when another user (in this case the Retrospect client) tries to read the file at the same time.

 


 

Uh, where did you come up this this?

 

According to the chart found on www.appleerrorcodes.com, a -5000 error is "afpAccessDenied"

 

You are getting the error when you are attempting to access the file via AFP.

 

Your scripts are wrong; re-read Twickland's reply, then edit your script to make sure that your Source is being accessed via the Retrospect Client, and not any file sharing protocol.

 

Dave

Link to comment
Share on other sites

Quote:

Quote:

-5000 is normaly issued when a user has exclusive access to a file when another user (in this case the Retrospect client) tries to read the file at the same time.

 


 

Uh, where did you come up this this?

 

 


Sorry guys. My mistake.

 

"/* AFP Protocol Errors */

afpAccessDenied = -5000, /* Insufficient access privileges for operation */"

 

I agree that there is something wrong with the scripts. You can't get -5000 through the client, at least not for local disks on the client. If there are afp (=file server) volumes mounted on the client's desktop and the client is configured to backup that volume, you can get this error.

 

Thanks for correcting me.

Link to comment
Share on other sites

  • 2 months later...

Related but different question; I'll use this forum, since it already discusses error -5000 and article 1144.

 

I'm running Retrospect 6.1.126, with Device Access Version 1.0.107 and Driver Update Version 6.1.4.103, on an iBook G4 running OS X 10.4.5.

 

I want to back up my hard drive to a file on a remote volume.

 

The remote volume is a 250GB Freecom FSG-3 network hard drive. It runs a Linux server; I'm connecting to it using SMB. Because Retrospect tells me I can only save a 2GB file to it using the built-in OS X filesharing protocol, I'm mounting the remote volume using Thursby's DAVE 6.1.

 

I have full access to the remote volume through the Finder. I can read, write, and delete files and folders.

 

But when I try to create a new backup set on the remote volume, I get the error message "Couldn't create back up set Backup Set A, error -5000 (server: no privileges).

 

All I'm trying to do (I thought) is to save a file to the external volume. I can do it via the Finder. Why can't I do it via Retrospect?

 

I've batted at this for a while. After reading article 1144, I created a user named root on the network hard drive and gave it a password; I came back and told Retrospect the password (Configure:Volumes, then select the volume, then Command-J to configure it). No luck. I tried drag-copying an existing storage set to the remote volume, using the Finder, and then I opened the set. Still couldn't update it.

 

Does Retrospect need root access to a remote volume just to put a storage set on it? Does Retrospect need access to some ports that may be blocked? Does Retrospect not work with DAVE?

 

Frankly, I'm stumped. I got the network HD largely for backups. If Retrospect isn't going to work--and I've used Retrospect for more than a decade--I may need to find another solution.

 

Any help would be appreciated!

Link to comment
Share on other sites

Quote:

I want to back up my hard drive to a file on a remote volume.

 

The remote volume is a 250GB Freecom FSG-3 network hard drive. It runs a Linux server; I'm connecting to it using SMB. Because Retrospect tells me I can only save a 2GB file to it using the built-in OS X filesharing protocol, I'm mounting the remote volume using Thursby's DAVE 6.1.

 


From this doc: http://www.thursby.com/products/dave-v6-spd.pdf

"Supports files greater than 2 GB on HFS+ volumes"

 

Since your network hard drive hardly runs on a HFS+ volume, DAVE still has the 2GB file size limit.

 

Test: Create a single file (not folder) that is at least 3GB and try to copy it to the drive using the Finder.

Link to comment
Share on other sites

hi jumbo,

 

Quote:

After reading article 1144, I created a user named root on the network hard drive and gave it a password

 


 

but this is not what article 1144 says to do. you need to log in as root to the _local_ machine (the Mac) and then mount the drive.

Link to comment
Share on other sites

First: Thanks for the thoughtful help!

 

waltr, thanks for pointing out a plain goof in my reading. When I saw "backup computer" in the 1144 instructions, I wrongly interpreted it to mean the computer I was saving the backup on, not the one I was saving the backup from. Correcting that got me to the next step.

 

CallMeDave, to clarify re filesharing protocols: This is an SMB/CIFS connection. Sorry I was vague before.

 

Lennart Thelander, rather than a long explanation about DAVE and the 2GB limit, I'll tell you what Retrospect told me. Before DAVE:

 

- 3/27/2006 4:06:10 PM: Copying Music on Jumbo Traveler…

Can't add that much data to backup set.

The limit is 2.0 G.

3/27/2006 4:06:12 PM: Execution incomplete.

Remaining: 1674 files, 5.2 GB

Completed: 0 files, zero KB

 

After DAVE:

 

- 3/31/2006 8:43:46 AM: Copying Music on Jumbo Traveler…

3/31/2006 8:44:02 AM: Execution stopped by operator.

Remaining: 1415 files, 5.2 GB

Completed: 5 files, 18.3 MB

 

I stopped this backup, but as you can see, without DAVE, Retrospect didn't want to write more than 2GB into a backup set on an SMB/CIFS mounted volume. I need to be able to write a file that large, but I also need Retrospect to believe it's possible.

 

I'll let you know if I finish copying a file larger than 2GB. Right now I'm working with frustratingly small chunks of time, so I haven't been able to sit and watch that much data transfer. But you ask a fair question. I believe the answer is that yes, I can write a file that large. I'll check.

 

Having said all that, I'm closer to where I want to be, but still not there.

 

When I enable root and launch Retrospect, I seem to be able to make a full backup to my remote volume. This opens up a possible workaround.

 

However, when I go back to my regular login, I'm still not running. I've tried two ways:

 

1) Unmount volume and quit Retrospect in root, then switch back to normal login. Re-mount volume. Launch Retrospect and proceed with backup. Result:

 

- 3/31/2006 8:45:23 AM: Copying Music on Jumbo Traveler…

Can't save catalog, error -5000 (server: no privileges).

3/31/2006 8:45:26 AM: Execution incomplete.

Remaining: 1418 files, 5.2 GB

 

2) Unmount volume and quit Retrospect in root, then switch back to normal login. Launch Retrospect and proceed with backup, allowing Retrospect to auto-mount volume. Here I get a more complicated result, which doesn't show up in the Retrospect log.

a) First Retrospect gives me my username for the remote volume and asks for the password. I give it the password. (Note that when logged in as root, I already told Retrospect the password as part of the 1144 instructions. Also, the window asking me for my password has a DAVE icon in it.)

B) Then Retrospect tells me it can't mount the volume (server login failed, error -128). It says "Please try manually connecting to it," which from method 1 above I know does not work.

c) Then DAVE flashes a window to tell me it can't mount the volume, because it's already mounted.

d) When I check the Finder, I see the remote volume is mounted, with a -1 after its name (as if it had been mounted a second time and the driver appended -1 to distinguish it from the first mount).

e) Retrospect now wants to know where the catalog file is; I point it at the correct file on the (renamed) remote volume.

f) Then a new twist: Retrospect tells me the catalog has been corrupted (-24205: chunk file damaged during save). It appears that Retrospect is doing something to the file, although it believes it has no access. Further attempts to open the file show that it is in fact corrupted.

 

I notice that the 1144 instructions specify that when Retrospect mounts the volume, I should not be able to see it in the Finder.

 

So now I at least have a workaround: It appears I can make successful backups from the root login. And I have a problem that's slightly more interesting, since it now involves file corruption.

 

But I'm still perplexed by Retrospect's behavior in my usual login. The program isn't working the way it's supposed to. It's not working the way other people describe it. The whole time (with or without DAVE), I have full read/write access to my remote volume in the Finder. I'm still interested in further thoughts on why Retrospect is behaving the way it does. A few specifics:

 

1) Are other users able to successfully make >2GB backups on remote SMB/CIFS volumes, using Retrospect and OS X out of the box, without DAVE or other third-party connection solutions?

2) Has anyone successfully used Retrospect to make backups on a remote volume with DAVE?

3) Maybe arcane, but does anyone know why Retrospect needs root access to log on to the remote volume? (I should note that I'm not running automatic backups, so I don't require the automount feature.) If I understand the mechanism at play, it makes it easier to figure out what's jamming it.

 

Other thoughts may also be helpful. Thanks again for the assistance so far!

Link to comment
Share on other sites

Quote:

But I'm still perplexed by Retrospect's behavior in my usual login. The program isn't working the way it's supposed to

 


 

It sounds to me as if it is.

 

Retrospect's auto-mount functionality is only supported for AFP connections. This is born out by the fact that DAVE/SMB doesn't store the password the remote volume wants to see.

 

The entire "Configure Server" steps are a hold over from Retrospect on Mac OS 6/7/8/9, and have never been updated to reflect the networking imporovements in OS X.

 

Your original post asked the right questions in regards to why this is an issue. It's all about Retrospect running as the root user, but the remote Destination volume having been mounted by a user other then root (the Aqua Finder user). That's why it works when you log into the Finder as root; both the mounted volume and the program that's asking for access to the contents of that volume have the same UID.

 

Dave

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...