GID wrong (0) for os.chown when copying or moving files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Duplicity |
New
|
Undecided
|
Unassigned |
Bug Description
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/
with_
File "/opt/local/
fn()
File "/opt/local/
sync_
File "/opt/local/
copy_
File "/opt/local/
tdp.
File "/opt/local/
self.
File "/opt/local/
self.
File "/opt/local/
util.
File "/opt/local/
return fn()
File "/opt/local/
util.
OSError: [Errno 1] Operation not permitted: '/Users/
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_
+ util.maybe_
(--ignore-errors does not fix the OSError.)
I have seen an informal report for duply (http://
Many thanks -
description: | updated |
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.