On Tue, Jan 31, 2006 at 04:48:31PM +0100, Geert Uytterhoeven wrote: > On Tue, 31 Jan 2006, Jon LaBadie wrote: > > On Tue, Jan 31, 2006 at 10:56:13AM +0100, Geert Uytterhoeven wrote: > > > I saw a similar thing when the disk of my backup server died last month. > > > The machine ran Debian testing, and I used an Ubuntu Live CD (the Knoppix > > > I had > > > lying around didn't support SATA) to do the restore. > > > > > > After the restore, some services didn't work because some configuration > > > files > > > were owned by the wrong user. > > > > > > I ended up comparing the uids and gids in /etc/passwd and /etc/group on > > > the > > > restored image and on the Ubuntu Live CD, and for all differences, > > > manually > > > verifying all uids and gids of all restored files and directories. > > > Fortunately > > > this took much less time than expected :-) > > > > > > I noticed one very strange thing though: uids and gids were not changed > > > in a > > > consistent way: some files had the incorrect uid or gid from Ubuntu, while > > > other related files that should have the same uid/gid had the one from the > > > original system. So sometimes uids/gids were remapped during restore, but > > > not > > > always... > > > > My understanding, subject to correction, is that by default guntar > > restores by trying to match text names (user and group) between the > > archive and the recovery system. If a match is found, then the > > restore is to the numeric uid/gid of the recovery system, thus > > matching the names, but not the necessarily the numeric ids in the > > archive. If matching text names are not found, then the archive's > > numeric ids are used. > > Exactly my understanding as well. > > > So you could easily get a real hodge-podge of names and numeric ids > > by recovering to a different system. > > > > Archived System Recovery System Result of Recovery > > name id # name id # name id # > > > > AAA 111 AAA 111 AAA 111 > > BBB 222 BBB 234 BBB 234 > > CCC 333 (no CCC) (no 333) (none) 333 > > DDD 444 (no DDD) (EEE is 444) EEE 444 > > > > Note, 3 of the 4 cases result in a recovery that doesn't match the > > originally archived system. May or may not be what was wanted. > > But as soon as /etc/passwd and /etc/group have been restored from backup as > well and you boot from the restored medium, CCC and DDD become correct again, > right? > > But this is not what I saw. Some files that should be owned by user BBB had > uid 222, while others had 234. It was not consistent. > > > If the --numeric-owner option was used, only the second case would > > change, the recovered result using an id of "222" rather than "234" > > with a text name of either "none" or whatever name matchs id "222". > > Which is what you want (assumed you backup OS files, instead of doing a clean > reinstall of the OS)... >
In such a case, a temporary workaround during restore could be to wrap gnutar: # mv /bin/tar /bin/tar.real # echo 'exec /bin/tar --numeric-owner "$@"' > /bin/tar # chmod +x /bin/tar -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road (609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)