Re: [Duplicity-talk] File ownerships restored wrong

[Yves Goergen]

On 17.09.2010 11:35 CE(S)T, Yves Goergen wrote:
> After the system bootet again, the Exim service could not be started
> because /var/log/exim4 was now owned by Debian-exim (id 111) but instead by
> the "libuuid" user (id 100). I also see /var/log/ntpstats owned by
> postfix:fuse which I don't think is correct but I'm not sure about that.
> Other files owned by users with the ids 117 and 2001 were restored
> correctly.

I got it working again. The solution is to restore the files
/etc/{passwd,shadow,group} first before anything else and copy them into
the rescue system's /etc so that all users and groups from the
to-be-restored system are already known in the restoring system. Only
after those files have been installed in the rescue system, the restore
process may be started.

   duplicity restore --file-to-restore etc/passwd $SOURCE ~/passwd
   duplicity restore --file-to-restore etc/shadow $SOURCE ~/shadow
   duplicity restore --file-to-restore etc/group $SOURCE ~/group
   mv ~/{passwd,shadow,group} /etc/

   duplicity restore --force $SOURCE /mnt

You can verify that the new file is in effect by id'ing some known users
and looking at printed out uid and groups:

   id some-user

Overwriting those files in the rescue system shouldn't normally be a
problem because you're logged in as root anyway and the rescue system is
not permanent. If it is, those files should better be backed up theirselves.

Maybe it's worth adding this hint somewhere to the documentation, if
it's not already there...

-- 
Yves Goergen "LonelyPixel" <address@hidden>
Visit my web laboratory at http://beta.unclassified.de