No access on rebuild data?

[gerry1308]

Hi!

I use Retrospect 8.

The server is installed on a G5 PPC with OSX 10.4.11

The RemoteClient i run on a MacPro with OSX 10.6.4

 

When i rebuild data, i do not have any access on this files.

No write or read access. Why is this so?

It looks like:

 

Yes, i always can give new rights for access, but this is not normal, isn´t it?

 

What can i do?

[rhwalker]

I use Retrospect 8.

Precisely which version and build? (8.x.x) Earlier builds / versions had many more bugs than the present version. Let's be sure that we aren't chasing problems that have been solved by updates.

 

(1) exactly what do you mean by "When I rebuild data"? Exactly what steps are you performing to do this?

 

(2) on which of the relevant computers (engine (server)? client?) is this "Get Info" box showing the access problems? Is it on a volume local to that computer, a network share, etc.?

 

(3) Are your UIDs / GIDs handled system-wide by Open Directory, WGM, etc.? or are they instead done on a machine-by-machine basis with local UID / GID sets?

 

(4) are ACLs possibly in play here, rather than POSIX permissions? could you provide a "ls -aloe" listing of the problematic folder, as well as a "mdls" of the problematic folder?

 

Sorry, I can't read German, but I think I can figure out what the various fields are by comparison with the English Get Info box.

 

Russ

[gerry1308]

Hi!

 

It´s Retrospect Version 8.2.0 (399)

1.) I open the Retrospect Client on a 10.6.4 MacPro.

Go to "Rebuild", i say "search for Files" (the last Point in the menu). Then i choose my Mediaset.

Then Retrospect ask me for a Volume where i want to have my rebuild data. I choose the local disk on the G5 (OSX 10.4.11) where the Retrospect server is installed. (localhost)

 

2.) The Get Info Box is directly from the G5 (Retrospect Server)

3.) UID/GID are only local on the machine

4.) There are no ACLs in play here.

I have all rights on this machine. But not to the folder which Retrospect applys for the rebuilded files.

But one thing i found out:

When i choose the original WinServer in the network (there are the files which i backup with retrospect), for the place where retrospect should save the rebuilded files, then there is no problem with it. I can full handle this files.

 

best

gerry

[rhwalker]

It´s Retrospect Version 8.2.0 (399)

Ok.

 

1.) I open the Retrospect [color:red]Client[/color] on a 10.6.4 MacPro.

Go to "Rebuild", i say "search for Files" (the last Point in the menu). Then i choose my Mediaset.

Then Retrospect ask me for a Volume where i want to have my rebuild data. I choose the local disk on the G5 (OSX 10.4.11) where the Retrospect server is installed. (localhost)

Sure you aren't talking about opening the Retrospect [color:red]console[/color] program rather than the Retrospect client program?

 

Perhaps it would help if you attached a screen shot to confirm. You might have to do the magic dance here:

Forum attachment rules change

 

Note that the forum admin contact email given in that post is a couple of years old, and now is obsolete (after the sale of Retrospect to Roxio). To contact the forum admin, use the "Contact Forum Admin" entry in the "Help" button drop down in the navigation bar at the top of this forum's window.

 

2.) The Get Info Box is directly from the G5 (Retrospect Server)

3.) UID/GID are only local on the machine

Ok, then I believe that explains your issue, and you are probably seeing the expected behavior.

 

Explanation:

 

Because you have not set up enterprise-wide UID/GID, they aren't going to be the same on each computer. Unix POSIX permissions are done on a UID/GID basis.

 

Your restore is being done on the Retrospect "engine" computer.

 

When Retrospect does the restore, it is supposed to restore the UID/GID metadata existing when it backed up the file(s) and folder(s). Retrospect engine is able to write anything it wants (with whatever permissions it wants) because it is running setuid root.

 

I suspect that the restore to the Windows box is done in a manner (by permissions there) that give you access, but the restore to the Retrospect engine box doesn't give you the needed permissions (hence the "no right" (Keine Rechte) message).

 

If the G5 is running Mac OS X Server 10.4.11, then there ARE ACLs in play.

 

Again, it would be instructive to see the results of an "ls -aloe" listing of the problematic folder, as well as a "mdls" of the problematic folder.

 

Russ

[gerry1308]

Hi Russ!

 

Thank you for answering.

Yes i mean the Retrospect Client. Screenshot here:

Screenshot

What is the Retro Console?

 

Yes, i have the same suspicion as you. Retrospect restore the files with the permissons from the windows machine. That could be an assertion.

Here the ls -aloe Screenshot

Here the mdls screenshot

 

thanks

gerry

[rhwalker]

Yes i mean the Retrospect Client. Screenshot here:

Screenshot

Sorry, that's the Retrospect console that allows you to manage/control the Retrospect engine. That's why I wanted to see a screen shot.

 

What is the Retro Console?

The program for which you provided a screen shot. It's the GUI for the Retrospect engine. The Retrospect engine is the program that does the real work; the console is just the GUI, and they chat over the network.

 

I suggest you take a moment to read the documentation and understand the different components of the program and what each does. See, for example, page 5 of the

Retrospect 8 What's New and Getting Started Guide

 

While the program might better handle your situation where you have (different) local UIDs and GIDs for each machine, I think that you are stuck using your workaround until you establish a correct and consistent enterprise-wide permissions model (Open Directory, etc.). In your case, where you have a Windows machine in the mix, you would need to do the so-called "Magic Triangle" setup so that Windows machines (using Active Directory) and Macs (using Open Directory) see the same permissions model, UIDs, GIDs, etc.

 

We don't see this and never have because all of our computers (server, LAN computers, etc.) run off of a common Open Directory server.

 

Russ