Bug 6590 - [sender] could not find xattr #1 for home/jdoe/TheFresh
[sender] could not find xattr #1 for home/jdoe/TheFresh
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.0.5
Other Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-29 18:05 UTC by Lukasz Stelmach
Modified: 2016-06-26 19:10 UTC (History)
3 users (show)

See Also:


Attachments
Concept patch (1.47 KB, patch)
2016-01-15 14:55 UTC, SATOH Fumiyasu
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lukasz Stelmach 2009-07-29 18:05:55 UTC
I get a message like the one in the summary when I try to copy files with their EAs (xattrs.c:591 in 3.0.6, I run 3.0.5). However, "TheFresh" directory has got no attributes (empty output of getfattr -dm. /home/jdoe/TheFresh).

The error does not occur during a dry-run, although it shows a line like this (-i)
.d........x home/jdoe/TheFresh/
when neither local nor remote (target) copy of the directory have any EAs.
The command is:
/usr/bin/rsync -XAHain --stats --delete-excluded --delete --iconv=utf8,utf8 --password-file=/root/rsync/rsync.backup.cred --filter='. /root/rsync/system.exclude' / backup@10.1.2.6::violetta/0

There seem to be completely nothing special about this /home/jdoe/TheFresh directory whatsoever.
Comment 1 Lukasz Stelmach 2009-07-29 18:19:34 UTC
OK I managed to work it around somehow. I removed trusted.SGI_ACL_DEFAULT attribute from several files in the /home/jdoe directory (it hasn't been set on TheFresh, I think).

getfattr -dm. didn't show it but it was there as I moved the files from XFS.
Comment 2 SATOH Fumiyasu 2011-04-18 23:53:39 UTC
I met the same problem here with transferring from rsync 3.0.8 + Solaris 10
xattrs patch (backported from 3.1.0dev) on Solaris 10 to rsync 3.0.8 on
Debian GNU/Linux.

I'm using the following command-line:
 
# rsync \
    --password-file /srv/osstech-work/etc/rsync.password \
    --iconv UTF-8,EUC-JP-MS \
    --archive \
    --acls \
    --xattrs \
    --hard-links \
    --numeric-ids \
    --delete \
    --stats \
    --partial \
    --progress \
    remote::home \
    /export/home \
   ;

When I remove "--iconv UTF-8,EUC-JP-MS" from the above command-line,
the problem is gone.

Can you try to remove --iconv option from your command-line?
Comment 3 Mantas M. 2014-04-24 10:20:31 UTC
I'm hitting the same (or at least a very similar) bug when trying to use --fake-super when backing up a server that runs Samba 4, and I always get the following error when rsync reaches the Samba "sysvol":

| [sender] could not find xattr #1 for Adm
| rsync error: protocol incompatibility (code 2) at xattrs.c(620) [sender=3.1.0]

(Both ends run 3.1.0; I also tried 3.1.1pre1.)

It seems this only happens when the "Adm" directory has xattrs from multiple namespaces, security.*, system.* and user.* ... (specifically, Samba sets security.NTACL and user.DOSATTRIB), and if I remove either security.NTACL _or_ user.DOSATTRIB, it works fine.

To reproduce:

#!/bin/sh -ex
mkdir Adm
sudo setfattr --restore=- <<'EOF'
# file: Adm
security.NTACL=0sBAAEAAAAAgAEAAIAAQAIlTbcbYS4nDSXwRaCyfUXTGYaUGme0BW6093Nz6ifNwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcG9zaXhfYWNsAHhnWbOkV88BuuACskYEKF40Vz8II2s/PkYW216aikVHSnkIiA2SLHYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEABIC0AAAAxAAAAAAAAADgAAAAAQIAAAAAAAUgAAAAIAIAAAEFAAAAAAAFFQAAAJn1WnqkTiRm4eaHmAECAAACALgABwAAAAADJAD/AR8AAQUAAAAAAAUVAAAAmfVaeqROJGbh5oeYAAIAAAADJAD/AR8AAQUAAAAAAAUVAAAAmfVaeqROJGbh5oeYBwIAAAAAGAD/AR8AAQIAAAAAAAUgAAAAIAIAAAALFAD/AR8AAQEAAAAAAAMAAAAAAAMUAP8BHwABAQAAAAAABRIAAAAAAxQAqQASAAEBAAAAAAAFCwAAAAADFACpABIAAQEAAAAAAAUJAAAA
system.posix_acl_access=0sAgAAAAEABwD/////AgAHAMLGLQACAAUAw8YtAAIABwDGxi0AAgAHAMjGLQACAAUAysYtAAQAAAD/////CAAAAGQAAAAIAAcAwMYtAAgABwDCxi0ACAAFAMPGLQAIAAcAxsYtAAgABwDIxi0ACAAFAMrGLQAQAAcA/////yAAAAD/////
system.posix_acl_default=0sAgAAAAEABwD/////AgAHAMDGLQACAAcAwsYtAAIABQDDxi0AAgAHAMbGLQACAAcAyMYtAAIABQDKxi0ABAAAAP////8IAAAAZAAAAAgABwDCxi0ACAAFAMPGLQAIAAcAxsYtAAgABwDIxi0ACAAFAMrGLQAQAAcA/////yAAAAD/////
user.DOSATTRIB=0sMHgxMAAAAwADAAAAEQAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA42UbOkV88BAAAAAAAAAAA=
EOF
sudo rsync -a -X --fake-super Adm/ Adm-new/

[receiver] could not find xattr #1 for .
rsync error: protocol incompatibility (code 2) at xattrs.c(620) [receiver=3.1.0]
Comment 4 Mantas M. 2014-04-24 10:23:21 UTC
Ah, on the second thought, I'm actually looking for bug 9594...
Comment 5 Hans-Kristian 2015-08-15 16:21:22 UTC
I am running into this on rsync v3.1.1 in Debian Jessie.

The symptoms are the same as #3, and as 3.1.1 have the patch in https://bugzilla.samba.org/show_bug.cgi?id=9594 as I have understood I think this is another issue.

Command:
rsync -avihh --stats --out-format=%i %C %n%L --numeric-ids --partial-dir=.rsync-partial --timeout=600 --acls --xattrs --fake-super -e ssh -i <key> -f merge <rule_file> root@<source>:/ <destination>

Result:
[sender] could not find xattr #1 for root/test
rsync error: protocol incompatibility (code 2) at xattrs.c(622) [sender=3.1.1]
2015-08-15 17:50:54 -> Rsync returned non-zero exit code [ 2 ]

The issue is caused by attributes set via Samba4 and only when "security.NTACL" and "user.DOSATTRIB" coexists. Other xattrs set on the same file doesn't seem to matter.

Reproducer for a problematic source file:
---
#!/bin/bash

set -e

dest="/root/test"

[[ -f ${dest} ]] && rm -f "${dest}"
echo "1" > "${dest}"

setfattr -n "security.NTACL" -v "0sBAAEAAAAAgAEAAIAAQCN16Y6BFqNVEMomAM+v42pydr5hYsoWGyPpwyCBv866wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcG9zaXhfYWNsAJzHXbI01dABZggOgcJ1PT/NJyBGmeTVwbN/3SXfnPAVXgM5MFQOssUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEABIC0AAAA0AAAAAAAAADsAAAAAQUAAAAAAAUVAAAAeg7SFXszBjXjUnZeUAQAAAEFAAAAAAAFFQAAAHoO0hV7MwY141J2XgECAAACAHgABAAAAAAAJAD/AR8AAQUAAAAAAAUVAAAAeg7SFXszBjXjUnZeUAQAAAAAFAD/AR8AAQEAAAAAAAUSAAAAAAAkAAAAAAABBQAAAAAABRUAAAB6DtIVezMGNeNSdl4BAgAAAAAUAAAAAAABAQAAAAAAAQAAAAA=" "${dest}"
setfattr -n "user.DOSATTRIB" -v "0sMHgyMAAAAwADAAAAEQAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABE9FdC2w9ABAAAAAAAAAAA=" "${dest}"

---
Comment 6 SATOH Fumiyasu 2016-01-13 10:44:19 UTC
You can reproduce this bug by the following:

# rm -rf src dst
# mkdir src dst
# touch src/f
# setfattr -n security.a -v 0sAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA src/f
# setfattr -n user.a -v 0sAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA src/f
# rsync --fake-super -X src/f dst
[sender] could not find xattr #1 for f
rsync error: protocol incompatibility (code 2) at xattrs.c(622) [sender=3.1.2]

In the first case, "security.a" and "user.a" have 33 bytes each other.
If "security.a" and/or "user.a" is reduced to 32 or shorter, 
rsync does not fail as the following:

# rm -rf src dst
# mkdir src dst
# touch src/f
# setfattr -n security.a -v 0sAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA src/f
# setfattr -n user.a -v 0sAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= src/f
# rsync --fake-super -X src/f dst
(no output, thus no error)

And then, if you change "user.a" to "user.s" (or "user.t", "user.u" ...)
from the first case, rsync does not fail too:

# rm -rf src dst
# mkdir src dst
# touch src/f
# setfattr -n security.a -v 0sAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA src/f
# setfattr -n user.s -v 0sAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA src/f
# rsync --fake-super -X src/f dst
(no output, thus no error)
Comment 7 SATOH Fumiyasu 2016-01-13 11:15:12 UTC
(In reply to SATOH Fumiyasu from comment #6)

I can reproduce this bug on Debian sid (amd64) with Linux kernel 4.3.3,
ext4 and XFS.
Comment 8 SATOH Fumiyasu 2016-01-13 12:43:27 UTC
(In reply to SATOH Fumiyasu from comment #7)

# rm -rf src dst
# mkdir src dst
# touch src/f
# setfattr -n security.a -v 0sAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA src/f
# setfattr -n user.rsync -v 0sAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA src/f
# rsync "$@" --fake-super -X src/f dst
[sender] could not find xattr #1 (2) for f cnt=1
rsync error: protocol incompatibility (code 2) at xattrs.c(622) [sender=3.1.2]

Change "user.rsync" to "user.rsynd":

# rm -rf src dst
# mkdir src dst
# touch src/f
# setfattr -n security.a -v 0sAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA src/f
# setfattr -n user.rsynd -v 0sAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA src/f
# rsync "$@" --fake-super -X src/f dst
(no output, thus no error)
Comment 9 SATOH Fumiyasu 2016-01-13 19:15:13 UTC
(In reply to SATOH Fumiyasu from comment #6)

The boundary "33 bytes" depends on "#define MAX_FULL_DATUM 32" in xattrs.c.
If I increase it to 64, the boundary value becomes 65 bytes
(i.e, MAX_FULL_DATUM+1 bytes).
Comment 10 SATOH Fumiyasu 2016-01-15 14:55:09 UTC
Created attachment 11780 [details]
Concept patch

This is a concept patch to describe what the problem is.
This fixes this bug, but does NOT a fundamental problem I think.
Comment 11 SATOH Fumiyasu 2016-01-15 15:03:50 UTC
(In reply to SATOH Fumiyasu from comment #10)
> This fixes this bug, but does NOT a fundamental problem I think.

Oops... Correction: This patch does NOT fix a fundamental problem I think.
Comment 12 Roman Dubtsov 2016-06-18 11:55:54 UTC
Hi, I think I've found the source of this bug. 

send_xattr_request() skips xattrs that are abbreviated:

552         case XSTATE_ABBREV:
553             /* Items left abbreviated matched the sender's checksum, so
554              * the receiver will cache the local data for future use. */
555             if (am_generator)
556                 rxa->datum[0] = XSTATE_DONE;
557             continue;

But recv_xattrs_request() does not have a good way to detect skipped elements because it is only able to traverse the xattrs list once.

I do not understand the code well enough to understand if it's reasonable to skip abbreviated xattrs, so I do not have a better solution than the one by SATOH Fumiyasu which modifies recv_xattrs_request() to loop over xattrs list multiple times.
Comment 13 Wayne Davison 2016-06-26 19:10:06 UTC
I have committed a fix for this bug to git which will be in the next release. Thanks for the reproducing script, diagnosis, and suggested patch. My apologies for the delay in getting this fixed.