Description of problem: All of my systems have all user file systems (anything you would want to back up) mounted with user_acl and xattr. These are all ext3 or ext4 file systems (the only ext3 ones left are /boot on some machines). When doing an amandabackup using tar with the xattr and user_acl options to backup sent to tar, I get a lot of this: ? /bin/tar: ./ConsoleKit: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./ConsoleKit/run-seat.d: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./ConsoleKit/run-session.d: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./ConsoleKit/seats.d: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./NetworkManager: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./NetworkManager/dispatcher.d: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./X11: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./X11/applnk: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./X11/fontpath.d: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./alternatives: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./amanda: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./amanda/DailySet1: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./audisp: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./audisp/plugins.d: Warning: Cannot acl_get_file: No such file or directory ? /bin/tar: ./audit: Warning: Cannot acl_get_file: No such file or directory It only shows on directories. I have never seen it on a plain file. I do not know if this is a kernel bug or a tar bug. However, to have warnings like this when nothing is really wrong is quite a problem as it grows the AMANDA report and causes it to say STRANGE instead of SUCCESS. Version-Release number of selected component (if applicable): tar-1.25-6.fc15.x86_64 How reproducible: Always Steps to Reproduce: 1. Setup a system to mount everything with user_acl and xattr 2. do a tar with options --acls --selinux --xattrs on /etc 3. Watch the warnings spew out Additional info: This also affects the latest I tried with F14 (about a month or two ago).
Strange, it works just fine on my machine with locally compiled f15 tar, maybe some issue in libacl - could you please try to get ltrace of run for the one failing directory? Are these directories (where acl_get_file complains about not existing file or directory) on the disk? Could you please write the whole tar command you are using for the backup? Maybe there is some issue with some cwd change... similar to issue https://bugzilla.redhat.com/show_bug.cgi?id=688567 ...
I will try to do this later today or tomorrow. As a note, the files are in the tarball, it just seems to be complaining about the xattr, user_acl stuff. Actually, I forgot that when I tested this with tar directly it worked if I was in the right directory. It didn't work if I emulated the tar that Amanda does. /bin/tar --create --file /dev/null --directory / --one-file-system --atime -preserve=system --acls --selinux --xattrs --listed-incremental /var/lib/amanda/gnutar-lists/HOST_FQDN__0.new --sparse --ignore-failed-read --totals --exclude-from/var/log/amanda/amgtar._.20110629092945.exclude. I hope I got the spaces right on this as this is from /proc/pid/cmdline The excludes knock out /etc, /home and /var for the ones for etc I think the only change is the --directory and the excludes. Yes, that is the only difference. The excludes just go completely away in /home and /etc as there is nothing to exclude in my setup. Doing an ltrace on this will be a bit difficult as I do not remember how I duplicated it with tar directly.
(In reply to comment #2) > Doing an ltrace on this will be a bit difficult as I do not remember how I > duplicated it with tar directly. If the tar process runs for a long enough period and still produces the warnings, you can find the process on your system manually and attach ltrace to the corresponding PID using the -p option of ltrace.
Looks like the same issue here (but mine slobbers files too): tar: ./lib/python2.7/site-packages/cherrypy/scaffold/__init__.py: Cannot setfilecon: No such file or directory I'm trying to migrate /usr from one FS to another, with: # tar --selinux --xattr -cf - -C /usr . | tar --selinux --xattr -xpf - -C /mnt/tmp Above was the result of that action... I have also noticed that SELinux attributes were not set on created directories (not sure whether they were supposed to be created only after files themselves were all created...) gamer ~ # ls -lZ /usr/ ... dr-xr-xr-x. root root system_u:object_r:lib_t:s0 lib drwxr-xr-x. root root system_u:object_r:usr_t:s0 local ... gamer ~ # ls -lZ /mnt/tmp dr-x------. root root unconfined_u:object_r:file_t:s0 lib drwxr-xr-x. root root unconfined_u:object_r:file_t:s0 local I interupted process before it had a chance to "finish"
if it was unclear from my previous comment - I posted only a single message - there are thousands of those flying by on the screen when I execute the original command.
I think I've found the problem and I have a fix. For details see the following gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=382067 look at comments #6 (steps for hitting the issue) and #7 (code analysis and fix). Basically, the current patch doesn't save acls or xattrs, just selinux labels, and only by luck. In brief what's happening is that, when dump_file0() in create.c makes the following call: xattrs_xattrs_get(st, p, fd); its calling with fd=0 in cases of files. But in xattr_xattrs_get there is a check: (fd == -1) ? ((xret = llistxattr (file_name, xatrs, xsz)) == -1) : ((xret = flistxattr (fd, xatrs, xsz)) == -1) So, it expects to list xattrs by file_name if fd = -1 or by file descriptor if fd != 1. But calling flistxattr() with fd=0 is wrong. The reason this happens is because fd is set to zero at the top of dump_file0() and only gets reset to a real file descriptor if subfile_open() is called. So fd == 0 means "I have no file desriptor" in dump_file0(), whereas fd == -1 means the same in xattrs_xattrs_get(). The fix is to replace the one and only call xattrs_xattrs_get(st, p, fd); in create.c to if (fd == 0) xattrs_xattrs_get(st, p, -1); else xattrs_xattrs_get(st, p, fd); This is a pretty trivial fix, do you need a patch?
Grr ... sorry a minor error but I don't want to cause confusion. Please change the line ... it expects to list xattrs by file_name if fd = -1 or by file descriptor if fd != 1. to it expects to list xattrs by file_name if fd = -1 or by file descriptor if fd != -1. That last number should be -1.
Anthony, thank you for the reproducer and the patch! This is actually a regression caused by update of tar to the new upstream release. The version of tar we have in F-14 seems to work fine using the scenario above.
Created attachment 524913 [details] Anthony's patch extended for ACLs and SELinux This seems to fix the creation with fd == 0. Unfortunately, the extraction is still broken in case -C is used. This is caused by the following upstream commit, which the xattr patch was not ready for: http://git.savannah.gnu.org/gitweb/?p=tar.git;a=commitdiff;h=4bde4f3
Created attachment 524917 [details] [PATCH 2/2] misc: partially revert upstream commit 4bde4f3 As a hotfix I will partially revert the upstream commit 4bde4f3. A proper solution would require to wrap all those name-based calls by the open-at.c wrapper. Note that selinux-at already exists as a module in gnulib, although tar does not include it yet. I am not sure about the acl/xattr functions...
fixed in tar-1.26-2.fc17
tar-1.26-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/tar-1.26-2.fc15
tar-1.26-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/tar-1.26-2.fc16
Package tar-1.26-2.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing tar-1.26-2.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/tar-1.26-2.fc16 then log in and leave karma (feedback).
I have not yet verified that this tar is backing up xattr and user_acls. However, it does get reed of the weirdness when called from AMANDA. I will try to do a back/restore of a test file and verify that user_acls and xattrs are working.
Great, thanks for testing! Please let us know if there was any badness going on.
tar-1.26-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
tar-1.26-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.