incomplete chown() error msgs

Bug #415619 reported by az on 2009-08-18
This bug affects 13 people
Affects Status Importance Assigned to Milestone

Bug Description

this is a forward/copy of debian 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.

Related branches

az (az-debian) on 2009-08-18
description: updated
Changed in duplicity:
importance: Undecided → Medium
Changed in duplicity:
status: New → In Progress
Changed in duplicity:
assignee: nobody → Kenneth Loafman (kenneth-loafman)
milestone: none → 0.6.06
Changed in duplicity:
milestone: 0.6.06 → none
Adam Porter (alphapapa) wrote :

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.

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

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

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.
> Title:
>  incomplete chown() error msgs
> To unsubscribe from this bug, go to:

Changed in duplicity:
assignee: Kenneth Loafman (kenneth-loafman) → nobody
status: In Progress → Confirmed
Randy Fay (randyfay) wrote :

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).

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers