Error 5000 (server: no privileges) when not logged in as root

[llee782]

I can't successfully duplicate a local directory to a directory on my Panther Server unless I run Retrospect while logged in as root. The error always appears with an Execution Incomplete notice: error -5000 (server: no privileges). If I run the same action while logged in as root, it works. Automatally mounting a volume on the server doesn't work either, whether I configure the volume access as root or as an admin user. Both client and server version of the OS is 10.3.7, but I couldn't do it in previous versions either. I have tried the procedure as instructed in article 1144 for configuring Retrospect for automatally mounting a volume but I still get "Sorry, server login failed, error -36". There's no problem with my access to the server, I can copy files with the Finder just fine. How can I get Retrospect to do it? Thanks.

[CallMeDave]

You've reported getting two different error messages, but there's no way to tell exactly what you're doing when each of them occurs.

 

The article you site discusses Backup Sets, not Duplicates, so it's information may be more confusing then helpful.

 

- Can you provide specific, step-by-step descriptions of what you're doing that generates each of the errors (it's the second one you quote that's new to me)?

 

- Is the Destination of your Duplicate the root level of your share point? Or, are you attempting to Define a folder as a Subvolume to use as your Destination? Have you tried it both ways?

 

The issues at play here are long standing ones related to realities in both Retrospect and Mac OS X. For example:

 

- Retrospect always runs with the User ID of 0 (root). This is necessary to allow Retrospect read/copy every file on a disk, and to maintain accurate permissions for storage and for Restores.

 

- Mac OS X is very particular about granting access to files on mounted volumes; only the user (all programs have an associated user who own them) who mounted a volume is allowed access to it.

 

- Mac OS X does not give any special consideration to the root user in regards to accessing mounted volumes. So if user "joe" mounts a volume by using the Finder's "Connect to server" dialog box, only programs running as "joe" will be allowed to read/write files on that volume. None of the following would be necessary if Apple allowed programs running as root to access volumes mounted by "joe." It's probably a smart security decision; I just don't understand why.

 

- Retrospect has two distinct directory browsing methods; one provided by Apple (what used to be called a Standard File Dialog box (SFPut and SFGet); I don't know what they're called under OS X), and the other built into the program. Different actions in Retrospect use either of these two methods.

 

A solution to one problem

 

Since Mac OS X won't allow Retrospect to read/write to volumes that Retrospect didn't mount, the solution is to take advantage of a feature that has been in Retrospect for years; the ability to store an AppleShare password in the program's preferences. Thus configured, volumes can be mounted without using the Finder at all, and AppleShare and OS X grant Retrospect read/write access to the volumes (at the same permission level that the login/password used have on the server).

 

When defining Sources for Backups, Retrospect uses its own file directory windows (called Volumes Selection or Volumes Database). You can see this window by visiting Configure->Volumes->Subvolume, or by selecting "Source" in an Immediate Backup window. You'll notice that there are no shortcuts to "Home" or "Desktop" from this window. If you want to backup files in your own Documents folder, you have to navigate through /Users/Me/Documents.

 

So to backup data stored on a remote volume, or to Restore any data to a remote volume, you have to have Retrospect mount the volume and you use Retrospect's own directory window to select your specific location.

 

But storing a Backup Set catalog file on a remote volume needs a different approach.

 

Some history

 

It was 4 years ago this week at Macworld Expo San Francisco that Dantz first showed Retrospect 5.0 Preview Release running on Mac OS X (was it 10.1.0? Or maybe 10.1.2...).

 

In that release as in now, creating a new Backup Set used the Apple provided "Save As..." dialog. Selecting Configure->Backup Sets->New->New would present a window that provided the user with Apple's shortcuts for "Home," "Documents," etc. And since Retrospect was running as root, selecting "Desktop" from the menu would navigate to /private/var/root/Desktop. So a normal user who created a new Backup Set this way would end up with a file that they would be unable to even see outside of Retrospect. Not a good thing.

 

Retrospect 5.0.205 was released when OS X was updated to 10.1.5, and in that release the behavior noted above had changed. Now the Save As dialog box invoked to create a new Backup Set behaved as if it were the current logged in user; selecting "Documents" from the menu would navigate to /Users/Me/Documents. That same behavior exists in the program today.

 

So in order to keep the program from saving files that couldn't be later found by the user, Retrospect changes the Save As dialog box from the UID (user ID) of Retrospect to the UID of the logged in user.

 

This works great when you're saving your new Backup Set to a local volume. But we have a different problem if we want to save our Backup Set catalog file to a remote volume.

 

Since a remote volume has to be mounted by Retrospect in order for the program to be allowed to write to it, when the Apple "Save As..." dialog changes to the UID of the current user we again have two different users attempting to access a volume! The process that worked when using the Retrospect directory browsing window now fails when using the Apple provided window (who's behavior was modified in order to protect users from having to deal with the hidden root directories).

 

In this case, the only way to make it work is to be sure that there is only one user involved; logging into OS X as root means that there are not two different user ID's to deal with. When the Apple "Save As..." dialog is evoked to save a new Backup Set, the effective UID that it changes to is the same as the UID that was used to mount any the target remote volume. So Retrospect is free to navigate through folders (again, as long as the user account being used has access to those folders) and save its catalog file.

 

From that point on, Retrospect can mount the remote volume and access the catalog files stored on it, since there is no need to use the "Save As..." dialog box to do it.

 

 

Phew.

 

I really don't know how Duplicates are affected by these factors. Duplicates use the Retrospect directory browser for both Source and Destination. I would have thought that having Retrospect mount a remote volume for either one would suffice. The trick about logging into the OS X Finder as root shouldn't be necessary, since the Apple "Save As..." dialog isn't invoked for an Immediate Duplicate. Knowing the exact steps you're taking might help track down the problem.

 

Dave

[llee782]

Thanks for the reply.

 

 

 

OK, I'm going to try to include here my attempted method for creating an exact copy of a folder on my local drive on an Apple File server. The local computer is running 10.3.7 Retrospect 6 (latest version both app and driver update as of today) and the server is running 10.3.7.

 

1. I mounted the server volume.

 

2. I launched Retrospect 6, clicked the configure segment tab then clicked the Volumes button, then selected the volume in the list in the Volumes Database window.

 

3. I selected Configure from the Volumes menu, entered the password I had used to mount the volume in the Finder, and clicked OK. Repeated this step to be sure, and as expected was met with the dialog "Automatic login in effect...". I clicked No Change.

 

4. I clicked Subvolume in the Volumes Database window, navigated to and selected the folder that would be the target of the duplication and clicked Define.

 

5. With the new volume selected, I clicked Browse and was able to browse the volume contents, so I then closed the Volumes Database window and ejected the volume dragging its icon on the desktop to the trash.

 

6. I clicked the Immediate segment tab, clicked the Duplicate button, selected the source volume from the list of subvolumes I had already created for my local drive and clicked OK.

 

7. In the Destination Selection window I selected Replace Corresponding Files from the pop-up menu then selected the newly created network subvolume (now grayed out because the volume is not currently mounted) and clicked OK.

 

 

 

Here is the point where the "Sorry, server login fialed, error -36 (i/o error, bad media?)" dialog appears. It lists the IP address of the server, the volume name and the user name with which I had mounted the volume originally in the Finder. It kindly offers the suggestion that I try manually connecting to it.

 

 

 

8. I manually connect to the volume in question as suggested by the "Sorry, server login failed..." dialog box, click OK in that dialog box after the volume is mounted, cllick OK in the Destination Selection window and attempt to run the duplicate by clicking the Duplicate button in the Immediate Duplicate window. The confirmation dialog box appears and I click OK. The Scanning... status window appears and I assume that the duplication is proceeding normally. When the duplication process has finished, the Immediate Duplicate window displays the message "Execution Incomplete", so I examine the log and in it appears several entries that are pretty much the same such as "trouble writing folder "x" Error 5000 (server: no privileges)". Upon examining the destination folder on the mounted network volume, I can confirm that indeed no files have been copied.

 

 

 

But I can log in as root on my local machine, launch Retrospect and run the same duplication process using the same source and destination choices and although some of the same types of error messages appear, the bulk of the operation completes successfully.

 

 

 

Another fact that would lead me to believe that the flaw lies with Retrospect is that I just tried the same procedure with La Cie's SilverKeeper and it completed the task without failure.

 

 

 

Please explain this behavior in Retrospect.

 

 

 

Thanks.

 

 

 

Regards,

 

Laine

[CallMeDave]

While I don't have the time right now to attempt to reproduce what you've done (and with the excellent steps you've provided, I know I'll be doing the same things you're doing) I would suggest that step 8 was a problem.

 

With the volume unmounted, go back to the Volumes Database and select the grey volume name. Then clck on "Subvolume" or "Browse." This will cause Retrospect to mount the volume, and assure that the program and the volume share the same UID. Then attempt your Duplicate.

 

Something to try...

 

Dave

[llee782]

Thanks, but that's where the method fails. Retrospect gives me the error -36 at this point no matter what I do. I've tried entering the password for the volume again and again. I have no trouble mounting the volume from the Finder or from SilverKeeper.

[CallMeDave]

Check step #1 above, and make _sure_ that you are mounting the volume via AFP and not SMB. To be sure, fully qualify the URL by entering:

 

afp://10.10.10.0 in the Connect to Server dialog (where, of course, 10.10.10.0 is the IP address of your actual server). See if that changes the subsequent steps.

 

Dave

[llee782]

It's afp. The url appears in the recent server list just as you specify. Can't mount with Retrospect 6. Again, SilverKeeper mounts and writes just fine, so does the Finder, so that would seem to indicate that the problem lies with Retrospect. I've already tried reinstalling.

[CallMeDave]

Quote:

---

Retrospect gives me the error -36 at this point no matter what I do

 

---

 

Here is a step-by-step that I just did between two OS X 10.3 machines; please compare it exactly to what happens for you:

 

1- Finder's Connect to Server, using AFP, connect to remote OS X machine and mount a volume

2- Retrospect->Configure->Volumes.

3- Select the remote volume from the Volumes Database window; note its server icon

4- Click on "Subvolume" button; note the Dantz file navigation window opens; click Cancel

5- Volumes Menu select "Configure." Note correct server, volume and user information. Enter correct password for the listed user and click OK.

6- Volumes Menu select "Put Away." Note the volume turns grey in the Volumes Database window (and unmounts from the Finder)

7- Select the grey remote volume

8- Click on "Subvolume" button

 

What happens after step 8?

 

Dave

[llee782]

error -36

 

The only difference I can see between my method and yours is that you used Retrospect to put away instead of dragging the icon to the trash in the Finder.

 

What possibility is there that Retrospect is corrupting the password that I'm trying to use it to store? The only thing I can think of to try that I haven't is to remove every item that Retrospect writes on my system and reinstalling, throwing away all previous backup set preferences and everything. I am reluctand to do that without any encouragement that it might do some good.

 

Thanks.

[llee782]

The problem appears to be the password that Retrospect is sending. It's not sending the right word. The administrator of the Apple File Server in question showed me the contents of the afp log on the server, and the entries displayed when I tried to log in using the Finder with an intentionally bad password were identical to those displayed when Retrospect tried to connect ("login myusername" -1.0.0 ... "logout myusername" -5023.0.0). A successful login yields "login myusername" 0.0.0 (then at logout: "logout myusername" 0.0.0). Any idea what could be causing it?

[llee782]

There must have been something about my password that Retrospect didn't like.

 

 

 

I changed it on the server and stopped getting error -36.

 

 

 

I forgot to mention I changed it in Retrospect, too. New password on server and new password in Retrospect. I didn't have any bad characters in that password, I promise. Just numbers and letters of upper and lower case.

 

 

 

Anyway, that seems to have solved it. Thanks.