Error setting permissions: Operation not permitted when trying to backup to NTFS

[Julian Sikorski]

DUPLICITY: INFO 1
DUPLICITY: . Writing /media/realcrypt1/backup/duplicity-full.20130717T193222Z.vol1.difftar.gz

DUPLICITY: WARNING 1
DUPLICITY: . Attempt 1 failed: GError: Error setting permissions: Operation not permitted

DUPLICITY: DEBUG 1
DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
DUPLICITY: . File "/usr/lib64/python2.7/site-packages/duplicity/backend.py", line 316, in iterate
DUPLICITY: . return fn(*args, **kwargs)
DUPLICITY: . File "/usr/lib64/python2.7/site-packages/duplicity/backends/giobackend.py", line 137, in copy_file
DUPLICITY: . target.get_parse_name())
DUPLICITY: . File "/usr/lib64/python2.7/site-packages/duplicity/backends/giobackend.py", line 112, in handle_error
DUPLICITY: . raise e
DUPLICITY: . GError: Error setting permissions: Operation not permitted
DUPLICITY: .

The above happens when trying to backup to a truecrypt-encrypted NTFS external drive. It used to work in Fedora 18, in Fedora 19 it does not anymore. The following package versions are involved:

deja-dup-26.0-1.fc19.x86_64
duplicity-0.6.21-1.fc19.x86_64
python-2.7.5-3.fc19.x86_64

[LaunchpadAccount (unfo)]

I have the same error under Ubuntu 13.04 when trying to write to a NAS310 FTP server. It is formatted as ext4, though.

DUPLICITY: INFO 1
DUPLICITY: . Writing ftp://admin@192.168.1.4/backup/duplicity-full.20130730T115103Z.vol1.difftar.gz

DUPLICITY: WARNING 1
DUPLICITY: . Attempt 1 failed: GError: Operation unsupported

DUPLICITY: DEBUG 1
DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 316, in iterate
DUPLICITY: . return fn(*args, **kwargs)
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", line 137, in copy_file
DUPLICITY: . target.get_parse_name())
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", line 112, in handle_error
DUPLICITY: . raise e
DUPLICITY: . GError: Operation unsupported
DUPLICITY: .

It has worked for a few days and then it mysteriously quit making automatic back-ups, giving me an "operation unsupported" error.

deja-dup 26.0
duplicity 0.6.21
Python 2.7.4
3.8.0-26-generic #38-Ubuntu

[Julian Sikorski (belegdol)]

I tried this with duplicity-0.6.22 and deja-dup-28.0. I also tried duplicity-0.6.20. None of them work. This is the cleaned-up command line:

$ /usr/bin/duplicity --exclude=/media/realcrypt1/backup --exclude=/home/julas/Pobrane --exclude=/home/julas/.local/share/Trash --exclude=/sys --exclude=/run --exclude=/proc --exclude=/home/julas/.cache/deja-dup/tmp --exclude=/var/tmp --exclude=/tmp --exclude=/home/julas/.thumbnails --exclude=/home/julas/.gvfs --exclude=/home/julas/.adobe/Flash_Player/AssetCache --exclude=/home/julas/.cache/deja-dup --exclude=/home/julas/.cache --exclude=** --gio --volsize=50 / file:///media/realcrypt1/backup --no-encryption --verbosity=9 --gpg-options=--no-use-agent --archive-dir=/home/julas/.cache/deja-dup --tempdir=/home/julas/.cache/deja-dup/tmp

Is there any more information I could provide to help fix this issue?

[Kenneth Loafman (kenneth-loafman)]

Have you tried doing this as root? Perhaps there's a permissions issue?

On Sun, Nov 10, 2013 at 5:57 AM, Julian Sikorski <email address hidden> wrote:

> I tried this with duplicity-0.6.22 and deja-dup-28.0. I also tried
> duplicity-0.6.20. None of them work. This is the cleaned-up command
> line:
>
> $ /usr/bin/duplicity --exclude=/media/realcrypt1/backup
> --exclude=/home/julas/Pobrane --exclude=/home/julas/.local/share/Trash
> --exclude=/sys --exclude=/run --exclude=/proc
> --exclude=/home/julas/.cache/deja-dup/tmp --exclude=/var/tmp
> --exclude=/tmp --exclude=/home/julas/.thumbnails
> --exclude=/home/julas/.gvfs
> --exclude=/home/julas/.adobe/Flash_Player/AssetCache
> --exclude=/home/julas/.cache/deja-dup --exclude=/home/julas/.cache
> --exclude=** --gio --volsize=50 / file:///media/realcrypt1/backup --no-
> encryption --verbosity=9 --gpg-options=--no-use-agent --archive-
> dir=/home/julas/.cache/deja-dup --tempdir=/home/julas/.cache/deja-
> dup/tmp
>
> Is there any more information I could provide to help fix this issue?
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/1202363
>
> Title:
> Error setting permissions: Operation not permitted when trying to
> backup to NTFS
>
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> New
>
> Bug description:
> DUPLICITY: INFO 1
> DUPLICITY: . Writing
> /media/realcrypt1/backup/duplicity-full.20130717T193222Z.vol1.difftar.gz
>
> DUPLICITY: WARNING 1
> DUPLICITY: . Attempt 1 failed: GError: Error setting permissions:
> Operation not permitted
>
> DUPLICITY: DEBUG 1
> DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
> DUPLICITY: . File
> "/usr/lib64/python2.7/site-packages/duplicity/backend.py", line 316, in
> iterate
> DUPLICITY: . return fn(*args, **kwargs)
> DUPLICITY: . File
> "/usr/lib64/python2.7/site-packages/duplicity/backends/giobackend.py", line
> 137, in copy_file
> DUPLICITY: . target.get_parse_name())
> DUPLICITY: . File
> "/usr/lib64/python2.7/site-packages/duplicity/backends/giobackend.py", line
> 112, in handle_error
> DUPLICITY: . raise e
> DUPLICITY: . GError: Error setting permissions: Operation not permitted
> DUPLICITY: .
>
> The above happens when trying to backup to a truecrypt-encrypted NTFS
> external drive. It used to work in Fedora 18, in Fedora 19 it does not
> anymore. The following package versions are involved:
>
> deja-dup-26.0-1.fc19.x86_64
> duplicity-0.6.21-1.fc19.x86_64
> python-2.7.5-3.fc19.x86_64
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/duplicity/+bug/1202363/+subscriptions
>

[Julian Sikorski (belegdol)]

Good point. duplicity actually does work when sudo-ed, deja-dup does not because the configuration is stored in the user account.

[Julian Sikorski (belegdol)]

You were right. I had truecrypt mount the volume with my user and group id (as opposed to root) and now it works. I am still not sure if this is correct though.

[Kenneth Loafman (kenneth-loafman)]

That is correct if you want the user to be able to write to the drive as
that user, otherwise you need root.

On Sun, Nov 10, 2013 at 7:18 AM, Julian Sikorski <email address hidden> wrote:

> You were right. I had truecrypt mount the volume with my user and group
> id (as opposed to root) and now it works. I am still not sure if this is
> correct though.
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/1202363
>
> Title:
> Error setting permissions: Operation not permitted when trying to
> backup to NTFS
>
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> New
>
> Bug description:
> DUPLICITY: INFO 1
> DUPLICITY: . Writing
> /media/realcrypt1/backup/duplicity-full.20130717T193222Z.vol1.difftar.gz
>
> DUPLICITY: WARNING 1
> DUPLICITY: . Attempt 1 failed: GError: Error setting permissions:
> Operation not permitted
>
> DUPLICITY: DEBUG 1
> DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
> DUPLICITY: . File
> "/usr/lib64/python2.7/site-packages/duplicity/backend.py", line 316, in
> iterate
> DUPLICITY: . return fn(*args, **kwargs)
> DUPLICITY: . File
> "/usr/lib64/python2.7/site-packages/duplicity/backends/giobackend.py", line
> 137, in copy_file
> DUPLICITY: . target.get_parse_name())
> DUPLICITY: . File
> "/usr/lib64/python2.7/site-packages/duplicity/backends/giobackend.py", line
> 112, in handle_error
> DUPLICITY: . raise e
> DUPLICITY: . GError: Error setting permissions: Operation not permitted
> DUPLICITY: .
>
> The above happens when trying to backup to a truecrypt-encrypted NTFS
> external drive. It used to work in Fedora 18, in Fedora 19 it does not
> anymore. The following package versions are involved:
>
> deja-dup-26.0-1.fc19.x86_64
> duplicity-0.6.21-1.fc19.x86_64
> python-2.7.5-3.fc19.x86_64
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/duplicity/+bug/1202363/+subscriptions
>

[Julian Sikorski (belegdol)]

This was not needed before. While uid and gid were defaulting to root, the dmask was set to 000 and fmask to 111. Maybe ntfs-3g or gio changed at some point.

[Tomáš Valenta (vali-9)]

It does not work on FAT as well.

My situation -- backup of home directory to a vfat mount. It creates a backup file duplicity-full-...difftar.gz, but later it apparently wants to change its permissions which is nonsense on FAT mount. Duplicity should not set (or at least rely on success) permissions of backup files explicitly.

As a user running duplicity I have full permissions to the backup file (i.e. 0666), but I am not the owner of the file and cannot be so. The FAT partition is mounted that the owner of all files is a particular user (root in my case). I cannot change it to a different user (me), because other users would have the same problem making backups to the mount.

[Kenneth Loafman (kenneth-loafman)]

This is not a duplicity issue. Permission problems are at the system level and cannot be solved by userspace programs.

[Tomáš Valenta (vali-9)]

NB: It worked on Ubuntu 13.04 (clean install), but stopped working after upgrading to 13.10 for me.

[Tomáš Valenta (vali-9)]

Kenneth, I think I get your point. I resolved my issue mounting the FAT partition
mount -t vfat -o rw,...,quite /FAT
Thanks to the "quite" option, all chmod and chown operations succeed (do nothing) and duplicity works again.
For NTFS, "silent" option should work similarly. But there are other ways.

But still it is weird duplicity (via deja dup) stopped working after upgrade to 13.10. And anyway, I think it should not change owner/permissions of backup files or it should be possible to turn this behaviour off.

[Pagaille (mgwebmail)]

Hi, anything new with this problem ? Is anybody working on it ? Thanks.