Jump to content

Restoring - permissions issues


Recommended Posts

When restoring a backed-up file to its original source, the group which the file belongs to is different for the restored file than for the original. (The permissions assigned to [group] are the same, what's changing is *which* group.)

 

When restoring a backed-up file to the computer retrospect server is running on, permissions do not allow the user who performed the restore operation to open one of the folders which the file is nested in; and once permissions are changed on the folder, permissions for the file itself show it belongs to another user. (The user selected seems to be the first user created on that computer, or maybe the first alphabetically, regardless of which user is logged in.) No group is specified (there ought to be group permissions), and others have no access to the file (which is fine).

 

Expected/desired behaviour would be: when Retrospect restores a file to its original source, permissions should be identical to those of the original file at the time it was backed up. When Retrospect restores a file to the computer which it is running on, the user who performed the install should have read/write access, and the file's group & others permissions should be the defaults used by the system for the creation of a new file. (I really don't know how restoring to a third computer should be handled; I've never needed to do that in practice.)

Link to comment
Share on other sites

When restoring a backed-up file to its original source, the group which the file belongs to is different for the restored file than for the original. (The permissions assigned to [group] are the same, what's changing is *which* group.)

 

Please provide the precise and exact steps you took in both the backup and restore operations.

 

>When restoring a backed-up file to the computer retrospect server is running on

 

There are three components to Retrospect 8, and none of them are referred to as "server."

- Retrospect Engine

- Retrospect management Console

- Retrospect Client

 

permissions do not allow the user who performed the restore operation to open one of the folders which the file is nested in; and once permissions are changed on the folder, permissions for the file itself show it belongs to another user. (The user selected seems to be the first user created on that computer, or maybe the first alphabetically, regardless of which user is logged in.) No group is specified (there ought to be group permissions), and others have no access to the file (which is fine).

 

Again, without specific steps it's impossible to either recognize a problem, identify user error, or comment on expected behavior.

 

I will say that "the user who performed the restore operation" has little meaning with this software; the Engine copies files to Media, while a user can utilize the management Console to configure the Engine to perform certain actions. The Engine and the Console can be different machines on the network.

 

> permissions for the file itself show it belongs to another user

 

What tools are you using to identify POSIX ownership and permissions? POSIX permissions are numerical, while most OS X utilities will map those numbers to the names on the machine on which the file resides. So a file owned by user 501 on a machine in the basement (where user 501 is named Bob) that is brought up (with a method that maintains permissions), to the penthouse and inspected on a machine where user 501 is named Xavier will show Xavier as the owner. Good tools will have a mode to display numbers instead of mapped names.

 

> No group is specified

 

This would concern me, if I knew the exact steps you took.

 

> Expected/desired behaviour would be:

 

By you; others might expect/desire something different.

 

> when Retrospect restores a file to its original source, permissions should be identical

> to those of the original file at the time it was backed up.

 

Agreed.

 

Again, knowing the exact steps you took where you saw a different result are needed here.

 

> When Retrospect restores a file to the computer which it is running on,

 

What is "it" in this context?

How would Retrospect be aware of what "it" is?

 

> the user who performed the install

 

Now you're joking, yes? The user who installed the Retrospect software should maintain some special relationship with files it backs up?

 

> should have read/write access, and the file's group & others permissions should be the

> defaults used by the system for the creation of a new file.

 

Back when Retrospect 5.0 and 5.1 and 6.0 and 6.1 were released, one of my ongoing requests/suggestions was to provide user control over the permissions of restored files. In Retrospect "Classic" (the versions referenced above) there were two conditions; complete POSIX integrity (by number) or the default mask of the user running Retrospect, which was possible as back then Retrospect was a GUI application that normally ran within Window Server (and therefore _had_ a user running it).

 

As I understand it, Retrospect 8 always maintains POSIX and ACL integrity on all Restore operations, no ifs, ands or buts. It doesn't appear likely that you're going to get what you expect or desire here; neither will I.

Link to comment
Share on other sites

We need some more details on this:

 

1. Source: OS, client version (if applicable), source folder/file permissions

(do an "ls -l" on the source folder.

2. restore destination: OS, restored folder/files permission (do an "ls -l" on the destination folder.

3. retrospect engine and console version

Link to comment
Share on other sites

Please provide the precise and exact steps you took in both the backup and restore operations.

 

I decided the best way to be sure of being exact and not missing anything was to run through the process fresh.

 

First, on the computer running Retrospect Client, I opened the Terminal and entered the following two commands:

 

cd Documents

touch testfile

 

Then, on the computer running Retrospect Engine and Console (I have them both on the same machine ("Server"); sorry about the earlier confusion) I opened Retrospect and clicked on the "Backup" button in the upper left corner. I selected the testfile on the client computer and performed the backup. (To be clear: I backed up only that one file.) The operation was completed successfully, with one file backed up according to both the summary and the log.

 

Next, I clicked the "Restore" button in the upper left corner of the window. I chose "Restore selected files and folders" and pressed the "Continue" button. I selected the testfile from the just-completed backup, and hit Continue. For the restore destination, I picked the client computer, and checked the "Restore to a new folder" checkbox. Continue, Start Now. The restore operation completes successfully.

 

You pointed out the difference between user/group numbers and names... the Get Info window built into the Finder doesn't show numbers, so I used the Terminal "ls -ln" command to check permissions of the original and restored file.

 

The original file:

-rw-rw-r-- 1 501 501 0 Jul 1 10:27 testfile

 

The restored file:

-rwxrwxr-x 1 501 80 0 Jul 1 10:27 testfile

 

(Interesting: this reveals something else I hadn't noticed before, namely the change of execute privileges.)

 

The steps I use for restoring to the Server computer instead of to the Client computer are the same as above, except that I select the Server computer as the restore destination.

 

The restored file (on the server):

-rw-rw-r-- 1 501 501 0 Jul 1 10:27 testfile

 

So it's restoring to the server (*not* the machine on which the file originated) with the correct permissions and users/groups. The Finder displays "(unknown)" group because group 501 is not defined on that computer, and the user to whom the file belongs is the first user defined when that computer was set up.

 

 

I will say that "the user who performed the restore operation" has little meaning with this software; the Engine copies files to Media, while a user can utilize the management Console to configure the Engine to perform certain actions. The Engine and the Console can be different machines on the network.

 

At the time the restore operation is being run, the ps command can tell the computer on which Console is running which user owns the Retrospect process, which must be the user responsible for the restore. So there's no good reason why Retrospect Console should be unaware of who is running it. But of course that won't help if the target of the restore operation is not the computer on which Console is running.

 

I maintain that if a file is being restored to a computer other than that from which it came, it would be useful for Retrospect to set the owner of the restored file to the user currently logged into that (target) machine (if any) and to set the group to that user's default group. (Perhaps the Retrospect Client could use the id command to get that information, and then use chmod/chgrp/chown to apply correct permissions?) It is simply not useful to, having restored a file, be unable to access it (or even unable to see it, absent access to its enclosing folder). Worse still: were I restoring the file to a different (than the source) client computer, I would have to then go to the target client computer and use administrative privileges to set the correct permissions for the just-restored file(s). That's quite a pain.

Link to comment
Share on other sites

The server computer: Retrospect 8.1 (build 148). Console and engine are on the same computer, a mini (2GHz core 2 duo with 4GB RAM) running OS 10.5.7

 

The client computer: Retrospect Client 6.3.019. It's a Dual 1.8GHz G5 running 10.4.11.

 

The basic operation is: the server backs up a file from the client, and then restores that file to a new folder on the (same) client. The permissions of the origninal and restored file are different. See specific details, including ls-ln results, in my reply to Dave's comment (above).

Link to comment
Share on other sites

We need some more details on this:

 

1. Source: OS, client version (if applicable), source folder/file permissions

(do an "ls -l" on the source folder.

2. restore destination: OS, restored folder/files permission (do an "ls -l" on the destination folder.

Actually, even more details are needed. In particular, whether any ACL settings are in effect, and "anothersmurf" is only showing the permissions on the file, not the enclosing directory (folder).

 

Useful information would be an "ls -aloe" on the file and on the directory (".") so that ACLs can be seen, if present.

 

I'm not going to get into a feature debate regarding what Retrospect should do when a user/group ID doesn't match on the destination, but I think that you deserve what you get in such a situation because that's the way Unix works. Personally, I think that a centralized Open Directory / LDAP should be used for multiple computers so that the numbers are consistent across an installation with multiple computers.

 

Russ

Link to comment
Share on other sites

ACLs aren't at play here. I did double-check with ls-aloe, as you suggested. (I think ACLs weren't used by default in 10.4, but I could be wrong about that.)

 

Enclosing directory (Documents) permissions on the client computer...

 

Original:

drwx------ 501 501

 

Restored:

drwxrwxr-x 501 80

Link to comment
Share on other sites

(I think ACLs weren't used by default in 10.4, but I could be wrong about that.)

ACLs were on by default in 10.4 Server and off by default in 10.4 non-Server. They are on by default in all versions of 10.5.

 

I just wanted to be sure that no permissions / ACL propagation issues were in play.

 

Russ

Link to comment
Share on other sites

I chose "Restore selected files and folders" and pressed the "Continue" button.

I would be curious if you might get a different result selecting "Restore an entire source volume or favorite folder to a previous point in time" in this assistant screen (with the understanding that "the destination onto which you would like your files restored" will loose any files already present),

 

The two different permission modes in Retrospect "Classic" were found in its similar operations ("Restore files and folders" and "Restore an entire disk")' in the absence of documentation, perhaps Retrospect 8 handles Restore operations differently between these two modes, too (I thought I tried this out in the Beta and found no difference, but I could be remembering wrong and I no longer have a clean test bed (or the time) to conduct thorough tests).

 

At the time the restore operation is being run, the ps command can tell the computer on which Console is running which user owns the Retrospect process, which must be the user responsible for the restore

The computer on which the management Console runs has only a transient effect on the Retrospect Engine; once the configurations are done, once the Script is Scheduled, the Console does not need to be running. The Retrospect Engine runs as a root process on the machine doing the backups; the UID of whomever might have done the scheduling (that day? the day before? the year before?) isn't relevant.

 

if a file is being restored to a computer other than that from which it came,

 

For true? How are you going to track that? Serial numbers? CPU identification numbers?

 

it would be useful for Retrospect to set the owner of the restored file to the user currently logged into that (target) machine (if any) and to set the group to that user's default group.

Have you thought that through? All files?

 

Lab Computer A has a full backup. Lab Computer A has catastrophic disk failure. A new computer is installed, and it's drive is targeted as a destination for a full volume restore. You sure you want all those files to share a common permission matrix? That would certainly pose a challenge for actually booting the machine!

 

If we're not going to get full or configurable control, then there has to be a "mode" where all attributes are maintained, even if that created situations where the permissions of the restored files don't match up with a particular user who'd like more/easier access to the files as written.

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...