Comment 3 for bug 415619

I discovered that the problem was that I was restoring files that I
had backed up as owned by a different username. A while back I
changed my username on my systems, and the UID was different also. My
UID is now 1000, but the files I was restoring were backed up as owned
by UID 1001. I ran the restore as root and it worked without error.

However, this seems like a big bug to me. I think Duplicity is
generally aimed at per-user backup, not for backing up entire systems,
so it makes more sense to me for Duplicity to restore permissions but
to set the owner to the user that's running the restore. It seems
quite possible, and even likely, that people might often restore to
different machines that have different UIDs (even if the userNAME is
the same, the UID could be different). Basically, if a user has
access to the Duplicity dataset and the keys needed to decrypt it, he
should be expected to restore the files to the UID of the restore
process.

On Mon, Apr 18, 2011 at 07:34, Kenneth Loafman <email address hidden> wrote:
> Are you running as root?  A normal user cannot chown files.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/415619
>
> Title:
>  incomplete chown() error msgs
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/duplicity/+bug/415619/+subscribe
>