On Thu, 8 Jun 2006, Douglas Bollinger wrote: > Using: rdiff-backup 1.0.4 on source and dest. > > Source: Runs as root > Dest: a non-root, regular user > > Source: Make a directory with 644 perms: > > [EMAIL PROTECTED] ~/.gnome2 $ ll > total 188K > drw-r--r-- 2 doug users 4.0K 2006-05-27 08:23 accels > > It will backup without any problems at dest... > > [EMAIL PROTECTED] ~/backup_sets/ghidorah/home/doug/.gnome2 $ ls -l > total 188 > drw-r--r-- 2 backup users 4096 May 27 08:23 accels > > But now the backup user at dest can't enter that directory anymore... > > [EMAIL PROTECTED] ~/backup_sets/ghidorah/home/doug/.gnome2 $ cd accels > -su: cd: accels: Permission denied > > I believe at some point having a directory that a normal user at the dest > can't enter will be a problem. At least, when rdiff-backup-data became > corrupt and I erased it, rdiff-backup couldn't create a new data directory > until I put sane 730 perms on all the backup directories at source and dest.
rdiff-backup, for better or worse, does a chmod on the directory while it's operating. it has no problems with the directory... i even tried removing rdiff-backup-data subdir and doing a new backup and it worked as well. i'm using 1.0.4 + recent cvs but i don't think that will make a difference... > Granted, this was using the older version, but I'm leary of nuking the new > rdiff-backup-data directory as it takes hours to create and I would like to > keep the backup revisions for now. Besides, once the 644 perms directories > are created, I don't see how a normal user on dest can get around entering the > directory. Or am I wrong on this? you can just chmod it... rdiff-backup won't care even if you do a restore -- it'll use its own metadata representation to get the correct perms. > Of course, the solution for me was to have sane perms for directories at the > source, but this seems like a bug if you wish to backup as a normal user at > dest. there've been issues similar to this in the past -- ben generally chooses to have the destination be as faithful a mirror as possible given the constraints of the destination filesystem/user/OS/etc. i said "for better or worse" above because rdiff-backup emphatically cannot operate with a read-only repository even when doing a restore... precisely because of tweaks like this required to read the mirror... although it shouldn't be too hard to add a feature where it sets the mirror perms to something explicit (i.e. r/w by backup user, and r/o for restore group)... i'd review such a patch if someone wrote it. if you're somehow getting rdiff-backup tracebacks when i'm not getting them then we should look further... otherwise i think this is a feature request rather than a bug report... -dean _______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
