restoring FC1 to *new* partition from tar archive
Jeff Vian
jvian10 at charter.net
Mon May 10 02:25:49 UTC 2004
Luciano Miguel Ferreira Rocha wrote:
>On Sun, May 09, 2004 at 08:21:43AM -0500, Jeff Vian wrote:
>
>
>>I think you are confusing /restore/ with /use/.
>>It can be /restored/ using any system. The ownership is numeric and does
>>not change on a differnent system.
>>
>>
>
>No, I'm not confusing it, and no, the ownership isn't numeric. At least,
>in my experience. I've created backups of redhat and fedora installs, in
>single user mode, and restore them under live cds (knoppix or self-made).
>If I didn't use the option I described, some files would end with
>different numeric ids than they should. In particular, the knoppix cd has
>different values for cups and other system accounts, and when restoring
>the files would use those values.
>
>
Ownership is stored on the system as numeris and is part of the inode data..
When displayed by ls or similar utilities it uses the values in the
passwd and group files to provide names for the user to see in the
listing. The chown command also translates the text user name to his UID
befroe assigining it to the file. The find command has an option to
search for files with the numeric UID or name.
To check this you can simply do a chown on a file and assign it a
numeric owner and group id that has no matching user/group id in the
passwd file. then do an ls -l on that file and you will see the owner
and group listed with the /numeric/ userid and group you assigned. In
the example below I did just the opposite: I took an existing user
account and changed his numeric UID in /etc/passwd.
The assigned numeric userid for a file restore from a tar file does not
change, However, the displayed (and effective) owner may change if
there is a user on the system with the same uid and a different user name.
I also have tested this when removing user accounts, without removing
the home directory. The owner column in the display from the ls -l
output becomes numeric as soon as the matching user entry in passwd is
removed.
Below is an example.
----------This was done with the userid in /etc/passwd-----------------
# ls -al
total 40
drwx------ 3 dennis dennis 4096 Dec 5 2002 .
drwxr-xr-x 11 root root 4096 Feb 24 17:15 ..
-rw-r--r-- 1 dennis dennis 24 Dec 5 2002 .bash_logout
-rw-r--r-- 1 dennis dennis 191 Dec 5 2002 .bash_profile
-rw-r--r-- 1 dennis dennis 124 Dec 5 2002 .bashrc
-rw-r--r-- 1 dennis dennis 5531 Dec 5 2002 .canna
-rw-r--r-- 1 dennis dennis 854 Dec 5 2002 .emacs
-rw-r--r-- 1 dennis dennis 120 Dec 5 2002 .gtkrc
drwxr-xr-x 3 dennis dennis 4096 Dec 5 2002 .kde
----------this is what is displayed after I changed the numerid UID for
this user in passwd ----------
Note, there is now no user with UID of 501, and no changes were made
except in passwd..
# ls -al
total 40
drwx------ 3 501 dennis 4096 Dec 5 2002 .
drwxr-xr-x 11 root root 4096 Feb 24 17:15 ..
-rw-r--r-- 1 501 dennis 24 Dec 5 2002 .bash_logout
-rw-r--r-- 1 501 dennis 191 Dec 5 2002 .bash_profile
-rw-r--r-- 1 501 dennis 124 Dec 5 2002 .bashrc
-rw-r--r-- 1 501 dennis 5531 Dec 5 2002 .canna
-rw-r--r-- 1 501 dennis 854 Dec 5 2002 .emacs
-rw-r--r-- 1 501 dennis 120 Dec 5 2002 .gtkrc
drwxr-xr-x 3 501 dennis 4096 Dec 5 2002 .kde
>When booting the restored system, those files would have invalid
>owners/group.
>
>
The invalid owner/group is a result of the mismatch between the UID and
GID on the originating system and on the destination system.
>
>
>>The user ids are a problem if /used/ on a system where the group and
>>passwd files define different userids for the owners.
>>
>>
>
>Not as such. As tar uncompresses using user and group names (in _my_
>experience), the extracted files will be usable by the users on that
>system.
>
>
tar writes the raw data. It does not have any idea of the names
associated with the numeric UID on the file.
The link between the numeric values on the file and the names they are
associated with is provided by the system and use of /etc/group and
/etc/passwd.
>Of course, if you consider the "use" of such backup as above, then it
>still is a problem.
>
>Regards,
>Luciano Rocha
>
>
>
I had to get this straight definitively when I merged user accounts from
2 different ISPs that had many overlapping UID and GID numbers, with the
names mismatched between the sites. It took a lot of planning and
creation of custom perl scripts to merge the accounts..
>
>
More information about the fedora-list
mailing list