I have been using restic (currently at v. 0.8.0.r44g06cb3f70), running as root, to back up system files from my Arch Linux desktop machine to a local (NAS) repository for some time. Very recently, I began seeing “extended attribute” warnings from restic such as (for example)
can not obtain extended attribute security.capability for /usr/bin/rcp
The files in question are still backed up to the repo, so the backup is still “working,” but I’m not sure if I should be concerned about the warnings.
Also, if I try to list the extended attributes of the file in question with # getfattr -d /usr/bin/rcp, no attributes are shown. Similarly # lsattr /usr/bin/rcp shows nothing relevant.
There is also a potentially relevant comment in the Arch extended attribute documentation which states
Warning: By default, extended attributes are not preserved by cp, rsync, and other similar programs.
From the timing, I suspect the new warnings are associated with some substantial recent Arch upgrades. Has anyone else seen anything similar? Is there anything I can or should do to address these warnings?
It looks like restic is trying to save the extended attribute security.capability, which seems to be used for binaries which have been assigned a capability, e.g. for listening to low TCP ports without having to run as root, and the kernel denies restic reading the attribute.
For you, this means that restic won’t be able to restore that particular attribute, but otherwise the backup is fine.
The warning in the documentation is unrelated, it concerns copying files with cp or rsync.
Can you check with getcap /usr/bin/rcp if any capabilities are set?
Many thanks for the pointer to getcap. I am not very familiar with either extended attributes or capabilities and that put me on the right track.
Long story short, the extended attribute security.capability had somehow been corrupted for each of the files in question. Reinstalling the associated package restored the security.capability attribute and eliminated the restic warnings. Nice that restic detected an issue even though normal maintenance (e.g. fsck) had not.
Of further interest, as a test I restored one of the files from a pre-corruption restic snapshot and confirmed that restic had saved the extended attribute correctly. So it’s all good.
