incomplete chown() error msgs

[az]

this is a forward/copy of debian bug #541788 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541788):
---
Package: duplicity
Version: 0.5.16-1~bpo50+1
Severity: normal

While running a test restore, duplicity reported these errors:

Error '[Errno 1] Operation not permitted: 'git/export'' processing export
Error '[Errno 1] Operation not permitted: 'git/hover.git/git-daemon-export-ok''
processing hover.git/git-daemon-export-ok
Error '[Errno 1] Operation not permitted: 'git/irssi.git/git-daemon-export-ok''
processing irssi.git/git-daemon-export-ok
Error '[Errno 1] Operation not permitted: 'git'' processing .

The files in question are owned by root on the source machine, the duplicity
restore test was run on another machine using a non-root account.

I am guessing that the the reported failed operation is chown() as the files
still belong to the user running the restore.

Duplicity should log which operation failed, including all details, e.g.
"setting owner to root:root" or similar.
---

[Adam Porter (alphapapa)]

This is an important bug. I am encountering it now trying to restore important files that were mysteriously truncated, and I don't know why the restore is failing. All I get is the "Error '[Errno 1] Operation not permitted" error. It does all the downloading of all the incremental sets and then fails with no explanation when it tries to write the restored files to disk.

[Kenneth Loafman (kenneth-loafman)]

Are you running as root? A normal user cannot chown files.

[Adam Porter (alphapapa)]

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
>

[Randy Fay (randyfay)]

Note that this failure (errno 1) is emitted, but it does *not* mean that the file was not restored. I was tricked rather badly by this, trying it over and over, when it had actually succeeded every time (but failed to set the user id on the file).

[Alexander van der Berg (1uf-alexander-sd4)]

Thanks randyfay for your comment. I restored a file a many times already unaware it succeeded and would have continued many times if I had not read your comment.