[SOLVED] Strange Warning on Incremental Backup

[oldgeek]

While doing an incremental backup to an external HD, I got the following warning:

root@steve-H110M-H:~# btrfs send -p /mnt/snapshots/@_200830-144355_ro /mnt/snapshots/@_200907-151433_ro | btrfs receive /backup
At subvol /mnt/snapshots/@_200907-151433_ro
At snapshot @_200907-151433_ro
WARNING: capabilities set multiple times per file: /backup//@_200907-151433_ro/usr/lib/x86_64-linux-gnu/libexec/kf5/start_kdeinit

Any help on what happened? Is the copy on the HD reliable? Any way I can check? I'm holding off doing the incremental backup of the @home snapshot until I find out there's no problem.

[GreyGeek]

I've recently experienced the same problem, also doing an incremental backup,
"btrfs send -p /mnt/snapshots/@20200905 /mnt/snapshots/@20200906 | btrfs receive /backup"

and for the 20200902 and 20200903 as well, but mine involved the gnome-keyring-daemon. The problem appears to alternate between usages of the differential backup command, one showing the warning and the next usage not.

There not much on the internet related to this problem except for what I found concerning "capabilities", which are properties of files that the getcap and setcap commands can adjust. When I check /usr/bin/gnome-keyring-daemon I get:

sudo getcap /usr/bin/gnome-keyring-daemon
/usr/bin/gnome-keyring-daemon = cap_ipc_lock+ep

The meanings are given in the man pages.

Kleopatra runs OK and my key ring works fine, so I gather from a 2015 report of a similar problem that it is related to the kernel, which I recently updated.

My rollback a couple days ago to reverse the effects of lots of experimentation with arduino, gps and XOD stuff worked fine.

So, I expect the problem to go away with the next kernel update. Meanwhile, I am ignoring it, since it doesn't seem to affect my system. df and usage report normally, and fstrim works as expected.

[oldgeek]

Thanks, GreyGeek. I deleted the subvolume on the external HD and tried the process again, with the same results. My incremental backup of the @home snapshot went well, and so far everything is running well, so I'll do what you do and leave it alone. I do these backups every week so that I have a pretty up-to-date record if something goes wrong. I used your BTRFS manual to get started and it has been most helpful. I'm getting the feel of the file system now and won't go back to Ext4.

[GreyGeek]

I just did my daily incremental backup and got the warning again for my /usr/bin/gnome-keyring-daemon file.
I opened mc and used it to compare that file on my
/mnt/snapshots/@20200907/usr/bin/gnome-keyring-daemon
with the backup on
/backup/@20200907/usr/bin/gnome-keyring-daemon
and both were identical. And, they both have the same cap settings:

root@jerryAspire-V3-771:~# getcap /mnt/snapshots/@20200907/usr/bin/gnome-keyring-daemon
/mnt/snapshots/@20200907/usr/bin/gnome-keyring-daemon = cap_ipc_lock+ep

root@jerryAspire-V3-771:~# getcap /backup/@20200907/usr/bin/gnome-keyring-daemon
/backup/@20200907/usr/bin/gnome-keyring-daemon = cap_ipc_lock+ep

So, I am ignoring it and suspect that the next update of the kernel, or btrfs-progs, or what ever will remove the problem.

[jlittle]

It would be interesting to see the results of

getcap /usr/lib/x86_64-linux-gnu/libexec/kf5/start_kdeinit
getcap /backup//@_200907-151433_ro/usr/lib/x86_64-linux-gnu/libexec/kf5/start_kdeinit

My Kubuntu says

/usr/lib/x86_64-linux-gnu/libexec/kf5/start_kdeinit = cap_sys_resource+ep

[GreyGeek]

It would be interesting to see the results of

getcap /usr/lib/x86_64-linux-gnu/libexec/kf5/start_kdeinit
getcap /backup//@_200907-151433_ro/usr/lib/x86_64-linux-gnu/libexec/kf5/start_kdeinit

My Kubuntu says

/usr/lib/x86_64-linux-gnu/libexec/kf5/start_kdeinit = cap_sys_resource+ep

Mine says the same for start_kdeinit.

[oldgeek]

So does mine. For the second command, I get this:

/backup//@_200907-151433_ro/usr/lib/x86_64-linux-gnu/libexec/kf5/start_kdeinit = cap_sys_resource+ep

So I guess everything's OK, right?

[GreyGeek]

Hasn't hurt me. I *suspect* that some process in btrfs or the kernel is trying to set a capability on the file in question that is already set, so a "WARNING" is posted, not an error or a failure to create the incremental backup.

I use a script to create my snapshot and incremental backup:

#!/bin/bash
#
# script to create backup snapshots to /mnt/snapshots and a differential backup to /backup
# To be run as root from /
#
NOW=$(date +%Y%m%d%H%M)
eval "mount /dev/disk/by-uuid/ce2b5741-c01e-4b3d-b6ba-401ad7f7fcdf /mnt"
eval "mount /dev/disk/by-uuid/e84e2cdf-d635-41c5-9f6f-1d0235322f48 /backup"
#
eval 'vdir /mnt/snapshots'
#
MKSNAP='btrfs su snapshot -r /mnt/@ /mnt/snapshots/@'$NOW
eval $MKSNAP
eval 'sync'
eval 'sync'
#
echo Enter previous snapshot
read PREVSNAP
#
if [[ -s '/mnt/snapshots/@'$PREVSNAP ]]; then
    MKINC='btrfs send -p /mnt/snapshots/@'$PREVSNAP
    MKINC=$MKINC' /mnt/snapshots/@'$NOW
    MKINC=$MKINC' | btrfs receive /backup'
    eval $MKINC
    eval 'sync'
    eval 'sync'
    eval 'umount /backup'
    eval 'umount /mnt'
else
    echo 'Bad name: @'$NOW
fi

[jlittle]

So I guess everything's OK, right?

I think so, but I imagine for backups you'd want more than "thoughts".

There was a bug in btrfs that handled capabilities incorrectly sometimes, what I'd call a race condition, and the warning comes from the patch to fix it. My reading is that the warning is triggered if the capability is set twice during a btrfs receive, but it doesn't hurt. I have a btrfs backup from 2017 where the capability is missing.

Linux capabilities are not much used. I could find 6 in /usr. They're supposed to be preferable to "setuid" programmes, where the programme runs as the id of the owner of the programme, to let users do system stuff, but Linux steadily eliminated setuid over the years. I suspect they're only there to meet some security standard.

<digression=history>My ancient experience with DEC VMS which heavily used something like these (called privileges) was that the experts eventually found this approach to limiting privilege escalation didn't really help much, because an attacker with any of a long list of privileges could use it to pivot and gain the others.</digression>

[oldgeek]

Greygeek, the script looks useful. Apart from changing the dev uuid, what else do I have to do to start writing this script and using it? I've never written a script before, and I have no idea how to write it or even where to start. Do I use Kate? Konsole? Any help would be appreciated.

[oldgeek]

I have made two incremental snapshots to my backup external HD today and did not receive any error message. There has been a kernel update since I last had the message, so I assume that it took care of whatever was triggering the error.

[GreyGeek]

Greygeek, the script looks useful. Apart from changing the dev uuid, what else do I have to do to start writing this script and using it? I've never written a script before, and I have no idea how to write it or even where to start. Do I use Kate? Konsole? Any help would be appreciated.

I have merged my @home subvolume into @ so that I have only the @ subvolume on my system. So, I need to make only one snapshot and do only one incremental backup. If you still use @ and @home you will have to add code to snapshot @home and do the backup on it as well.

I "sudo -i" to root. Kate won't start in that environment and for me Kate won't allow saving a text file on /, but it does in /etc and such. So, I installed featherpad, which has no qualms working in a root environment. But, what ever works for you.

The line which does "eval '/mnt/snapshots'" is to list my snapshots so I can choose which one I want to use as the base for an incremental snapshot. Usually the previous one but sometimes not. Also, if I mistype the name the mistake will cause the script to quit without unmounting the drives, so I can finish the task manually. So far, I've never had that happen. I included "@" as part of the prompt strings in

if [[ -s [B]'/mnt/snapshots/@'[/B]$PREVSNAP ]]; then
    MKINC=[B]'btrfs send -p /mnt/snapshots/@'[/B]$PREVSNAP
    MKINC=$MKINC[B]' /mnt/snapshots/@'[/B]$NOW
    MKINC=$MKINC' | btrfs receive /backup'
    eval $MKINC

because you can't use the "@" character in response to the "read" command.

Be sure to mark the script with the "execute" permission after you've finished it.

[oldgeek]

Thanks for your response.