GID wrong (0) for os.chown when copying or moving files

[Ralf Herold]

Using duplicity 0.6.20, python 2.7.2, gpg 2.0.17 under Mac OS X 10.8, the following error is reproducible when trying to list remote backup (WebDAV) contents on a different computer from where the backup was made:

Traceback (most recent call last):
  File "/opt/local/bin/duplicity", line 1403, in <module>
    with_tempdir(main)
  File "/opt/local/bin/duplicity", line 1396, in with_tempdir
    fn()
  File "/opt/local/bin/duplicity", line 1272, in main
    sync_archive(decrypt)
  File "/opt/local/bin/duplicity", line 1072, in sync_archive
    copy_to_local(fn)
  File "/opt/local/bin/duplicity", line 1021, in copy_to_local
    tdp.move(globals.archive_dir.append(loc_name))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/duplicity/path.py", line 617, in move
    self.copy(new_path)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/duplicity/path.py", line 443, in copy
    self.copy_attribs(other)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/duplicity/path.py", line 448, in copy_attribs
    util.maybe_ignore_errors(lambda: os.chown(other.name, self.stat.st_uid, self.stat.st_gid))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/duplicity/util.py", line 65, in maybe_ignore_errors
    return fn()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/duplicity/path.py", line 448, in <lambda>
    util.maybe_ignore_errors(lambda: os.chown(other.name, self.stat.st_uid, self.stat.st_gid))
OSError: [Errno 1] Operation not permitted: '/Users/<username>/.cache/duplicity/duply_<backupname>/duplicity-full-signatures.20120929T191652Z.sigtar.gz'

In "copy" calling "copy_attribs", the self.stat.st_uid is correctly set (e.g., 504) but the self.stat.st_gid is 0, which would be root and this throws an OSError message as duplicity is run as normal user. I could not find where in duplicity/path.py the gid is determined; this may be an issue with the ROPath object?

This is a temporary fix: In duplicity/path.py, line 448, change self.stat.st_gid to -1:

- util.maybe_ignore_errors(lambda: os.chown(other.name, self.stat.st_uid, self.stat.st_gid))
+ util.maybe_ignore_errors(lambda: os.chown(other.name, self.stat.st_uid, -1))

(--ignore-errors does not fix the OSError.)

I have seen an informal report for duply (http://niebegeg.net/post/32010111657/duplicity-backups-wiederherstellen) which mentions above issue as well but this may not have been submitted as bug.

Many thanks -

[Lee Verberne (verb)]

This is affecting me as well on OpenBSD 5.2 w/ python 2.7.3 & duplicity 0.6.19. The root cause is BSD semantics for new file creation in which a new file inherits the GID of the directory in which it was created. e.g.

[user@host]:~% cd /tmp
[user@host]:/tmp% ls -ld
drwxrwxrwt 7 root wheel 512 Nov 13 01:18 .
[user@host]:/tmp% id
uid=1002(user) gid=1000(group) groups=1000(group)
[user@host]:/tmp% touch look_at_my_gid && ls -lh look_at_my_gid
-rw-r--r-- 1 user wheel 0B Nov 13 01:19 look_at_my_gid

So, duplicity creates a temporary file in /tmp. When it does the os.lstat() via tdp.setdata() in copy_to_local(), tdp.stat.st_gid is set (correctly) to 0. Then copy_attribs() attempts to copy that gid to a file in the cache and fails.

The work around I'm using -- which seems easier than modifying the source -- is to use the --tempdir command line option to set the temp directory to one whose GID matches the non-privileged user running duplicity. ~/.cache/tmp, for example.

[Ralf Herold (ralf-herold)]

Hi verb, many thanks for clarifying the issue. I had missed the point on inherited GID. Thanks also for the work around, which is certainly better than my crude approach.