Description of problem: With today's upgrade of libattr (due to bug #485473), something changed with rdiff-backup to kill my rdiff-backup scripts. Namely, when I try to run the script I get the exception below, and rdiff-backup dies. According to the rdiff-backup mailing list, the exception "is occurring while updating ACL's, so it's likely that the update to libattr is the cause." I also note that the backup drive is NTFS-formatted, but it has caused no problems with rdiff-backup until today. FYI, my backup script looks like (with some identity fudging): ARCHIVEROOT=/media/LaCie/LinuxBack ; ########################################### ## Home Directory ######################### ########################################### SOURCEDIR=/home/USER/ ; MOZCACHEDIR=/home/USER/.mozilla/firefox/0pntvzz6.default/Cache/ ; ARCHIVENAME=COMPUTER-rdiff-backup-home ; rdiff-backup \ -v3 \ --print-statistics \ --exclude-sockets \ --exclude $SOURCEDIR"Music/" \ --exclude $SOURCEDIR"Videos/" \ --exclude $SOURCEDIR".Trash/" \ --exclude $MOZCACHEDIR \ $SOURCEDIR $ARCHIVEROOT/$ARCHIVENAME ; rdiff-backup --print-statistics --force --remove-older-than 3W $ARCHIVEROOT/$ARCHIVENAME Version-Release number of selected component (if applicable): rdiff-backup-1.2.5-1.fc10.x86_64 attr-2.4.43-2.fc10.x86_64 How reproducible: Always. Actual results: Exception '[Errno 95] Operation not supported' raised of class '<type 'exceptions.IOError'>': File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 304, in error_check_Main try: Main(arglist) File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 324, in Main take_action(rps) File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 280, in take_action elif action == "backup": Backup(rps[0], rps[1]) File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 337, in Backup backup_final_init(rpout) File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 497, in backup_final_init checkdest_if_necessary(rpout) File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 905, in checkdest_if_necessary dest_rp.conn.regress.Regress(dest_rp) File "/usr/lib64/python2.5/site-packages/rdiff_backup/regress.py", line 71, in Regress for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf) File "/usr/lib64/python2.5/site-packages/rdiff_backup/rorpiter.py", line 281, in __call__ last_branch.fast_process(*args) File "/usr/lib64/python2.5/site-packages/rdiff_backup/regress.py", line 268, in fast_process if rf.metadata_rorp.isreg(): self.restore_orig_regfile(rf) File "/usr/lib64/python2.5/site-packages/rdiff_backup/regress.py", line 292, in restore_orig_regfile rpath.copy_attribs(rf.metadata_rorp, tf) File "/usr/lib64/python2.5/site-packages/rdiff_backup/rpath.py", line 190, in copy_attribs if Globals.acls_write: rpout.write_acl(rpin.get_acl()) File "/usr/lib64/python2.5/site-packages/rdiff_backup/rpath.py", line 1336, in write_acl acl.write_to_rp(self, map_names) File "/usr/lib64/python2.5/site-packages/rdiff_backup/eas_acls.py", line 371, in write_to_rp self.default_entry_list, map_names) File "/usr/lib64/python2.5/site-packages/rdiff_backup/eas_acls.py", line 380, in set_rp_acl acl.applyto(rp.path) Expected results: rdiff-backup backups the directory in question.
What version of libattr do you have installed? Does the 2.4.43-2 version fix things?
Thought I put it up there...hmm. Well, I have: attr-2.4.43-2.fc10.x86_64 libattr-devel-2.4.43-2.fc10.x86_64 libattr-2.4.43-2.fc10.i386 libattr-2.4.43-2.fc10.x86_64 libattr-devel-2.4.43-2.fc10.i386 Indeed, I think it was the 2.4.43-2 version that *caused* the break because the problems began occurring after I updated Fedora yesterday.
weird. I don't see anything in the changes there that would cause this. :( If you revert those packages everything works again as normal? I'm adding the attr maintainer here to see if he has any ideas...
(In reply to comment #3) > weird. I don't see anything in the changes there that would cause this. :( > > If you revert those packages everything works again as normal? > > I'm adding the attr maintainer here to see if he has any ideas... You are absolutely right, it is *not* due to attr...somehow. I reverted and no go. So I tried this: # rdiff-backup -v3 /etc/ /scratch/trialback where I'm backing up *not* to my external drive, but to a local disk, and it worked. Is there something that could have changed how my external NTFS drive was mounted that would kill rdiff-backup? Because it has worked fine for a over a year until then.
I think I might possibly see the problem. Previous to that day, I had upgraded NTFS-3G from 2009.1.1 to 2009.2.1. Then, on the Day of Trouble, I rebooted, which remounted the drive now using 2009.2.1. If you look at the notes for that package: STABLE Version 2009.2.1 (February 12, 2009) -- Release Notes <snip> # Change: The user extended attribute namespace is supported by default on Linux. and from the release notes: The user namespace extended attributes are supported from now by default on Linux. The other namespaces like system, security, and trusted, are supported by the Advanced NTFS-3G driver. Please see more at http://pagesperso-orange.fr/b.andre/advanced-ntfs-3g.html and http://pagesperso-orange.fr/b.andre/extend-attr.html I read this as saying now the default option is "streams_interface=xattr" it seems, and not "streams_interface=none" So I try: # mount -t ntfs-3g /dev/sdd1 /media/LaCie -o streams_interface=none and then a trial: # rdiff-backup -v3 /etc/ /media/LaCie/trial Huzzah! It works! So, is there a setting I should set on rdiff-backup...or one I should set for autofs/fuse/?? (whichever one sets the default mounting during boot up)?
You can try running rdiff-backup with '--no-eas' and see if that works? So, is this a rdiff-backup bug in not handling them right, or a ntfs-3g bug in the way they are implementing it? It's not clear to me which one it is. ;(
I remounted my drive without "streams_interface=none" and then tried: # rdiff-backup -v3 --no-eas /etc/ /media/LaCie/trial That fails. However, running: # rdiff-backup -v3 --no-acls /etc/ /media/LaCie/trial does work. I, too, am unsure who is to "blame" here. My guess is rdiff-backup in the sense that this change is very new and thus needs to be interpreted and included in the code...but this is mighty low-level stuff here. One question I have with these workaround is *which* is better? Mounting with "streams_interface=none" or using "--no-acls"?
Everything seems to work as expected. Stable NTFS-3G (not the Advanced one) supports only the User namespace EAs. ACLs are using EAs in the System namespace. This is why --no-acls works. --no-eas failing is unexpected unless it means "all EAs except the ACLs". "rdiff-backup --no-acls" is better because it will also save User EAs, though you can have the same problems with the Security and Trusted namespace EAs.
ok. So, where are we here? There is a 1.2.7 now upstream where they say: "Don't crash when filesystem can't set ACL. Thanks to Matt Thompson for the bug report." Is this the same bug? ;) If so, I can push out a 1.2.7 update...
Yep! Of course, in that irony that is bugzilla, I can't test to see if it's fixed until the updated RPM is out. So, please do push the update and I'll test and close this bug.
Sorry for the delay. I have wipped up a scratch build for f10 at: http://koji.fedoraproject.org/koji/taskinfo?taskID=1238693 Can you test that and confirm the fix? If it looks ok, I can push out to f9/f10 testing.
(In reply to comment #11) > Sorry for the delay. > > I have wipped up a scratch build for f10 at: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1238693 > > Can you test that and confirm the fix? > If it looks ok, I can push out to f9/f10 testing. That build does indeed seem to work now when I don't use --no-acls. It seems to detect the missing ACLs settings...or whatever: Warning: Access Control List file not found The only thing I saw was that the package wasn't signed (i.e., 'yum localinstall --nogpgcheck') but that seems to be kind of common with koji packages. Thanks for the help. I'd mark this CLOSED, but I'm not too sure on the subfield (NEXTRELEASE? RAWHIDE?).
rdiff-backup-1.2.7-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/rdiff-backup-1.2.7-1.fc10
rdiff-backup-1.2.7-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/rdiff-backup-1.2.7-1.fc9
Well, the updates system will close this once it hits stable, so you can just wait for that... :) I would like to let it sit in testing for a few days at least before pushing it to stable.
rdiff-backup-1.2.7-1.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update rdiff-backup'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-2700
rdiff-backup-1.2.7-1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rdiff-backup'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2721
rdiff-backup-1.2.8-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/rdiff-backup-1.2.8-1.fc10
rdiff-backup-1.2.8-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/rdiff-backup-1.2.8-1.fc9
rdiff-backup-1.2.8-1.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update rdiff-backup'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-3429
rdiff-backup-1.2.8-1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rdiff-backup'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3483
rdiff-backup-1.2.8-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
rdiff-backup-1.2.8-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.