Missing linux capabilities on target host running old kernel / btrfs-progs

[OliverUrbann]

I'm using btrfs on my Notebook which has Ubuntu 20.04 LTS with kernel 5.15. For backups I have setup an image file with btrfs on a server with Ubuntu 18.04 LTS with kernel 5.4.0. After a fresh backup btrbk-verify shows some differences:

[rsync] .f........x usr/lib/i386-linux-gnu/libgstbase-1.0.so.0.1602.0   # FAIL ndiffs=1
[rsync] .f........x usr/lib/ubiquity/target-config/50gkd-caps   # FAIL ndiffs=2
[rsync] .f........x usr/lib/x86_64-linux-gnu/libgstcontroller-1.0.so.0.1602.0   # FAIL ndiffs=3
[rsync] .f........x usr/share/doc/iputils-ping/copyright   # FAIL ndiffs=4
[rsync] .f........x usr/share/doc/iputils-tracepath/copyright   # FAIL ndiffs=5
[rsync] .f........x usr/share/doc/mtr-tiny/copyright   # FAIL ndiffs=6

On the server side (as an example):

getcap usr/share/doc/iputils-ping/copyright
usr/share/doc/iputils-ping/copyright = cap_net_raw+ep

Different files give different capabilities but on my notebook getcap gives nothing on these files. Note that /usr/bin/ping has the usual capabilities also on my notebook, so it is not always nothing.

On both machines the mount options for btrfs are the same. So why shows my older system capabilities, especially on docs? It is obviously not a btrbk bug but maybe someone here had similar experiences?

[digint]

btrfs had some issues in the past with send/receive on files with linux capabilities, I remember a couple of posts on the btrfs mailing list regarding this, and having trouble with it in my backups a couple of years ago. Not sure if it is the kernel of btrfs-progs, probably it's a combination of both. I suggest to upgrade btrfs-progs to the newest version on you server, and hope for the best. Or read through the btrfs mailing list...