Could not search B-tree: Operation not permitted

[Dreamsorcerer]

After upgrading my (Debian) server, my backup scripts now get ERROR: Could not search B-tree: Operation not permitted when running btrfs sub show /home/backup-laptop/home/2024-03-03. I assume this is probably some change caused by the kernel upgrade.

Assuming this is not a bug, what is the expected way to achieve this without running as root? I use this command to check if the last snapshot was fully synced (e.g. the receive command didn't get killed by the machine shutting down or similar), by checking the output has something under 'Received UUID'.

[kdave]

There was no change that would affect the subvolume show command, the root privs are needed when enumerating snapshots or if the subvolume directory is not accessible for the user. I'm not sure it's necessary to use the search tree ioctl, it's all under https://github.com/kdave/btrfs-progs/blob/master/cmds/subvolume.c#L1712, the iterator can use a non-privileged way of enumeration. I'm not sure why it's not used, maybe it could, more investigation needed.

[kdave]

A quick hack to force the unprivileged search does not work (unsetting iter->use_search_tree manually).

[Dreamsorcerer]

There was no change that would affect the subvolume show command

Well, it worked before upgrading, and never had that error.

I'm not sure it's necessary to use the search tree ioctl, it's all under https://github.com/kdave/btrfs-progs/blob/master/cmds/subvolume.c#L1712, the iterator can use a non-privileged way of enumeration. I'm not sure why it's not used, maybe it could, more investigation needed.

Good to know, would be good to have the backups working again without root.

[Dreamsorcerer]

the root privs are needed when enumerating snapshots or if the subvolume directory is not accessible for the user.

Just rereading this, are either of those true in this case? I've given a path to a specific snapshot, and the parent directory is owned by the user.

root@sam-backups:~# su - backup-laptop
backup-laptop@sam-backups:~$ ls -l
total 0
drwxr-xr-x 1 backup-laptop backup-laptop 40626 Mar  3 13:13 home
[...]
backup-laptop@sam-backups:~$ btrfs sub show home/2024-03-03
ERROR: Could not search B-tree: Operation not permitted
backup-laptop@sam-backups:~$ 
logout
root@sam-backups:~# btrfs sub list /home/backup-laptop/home/
[...]
ID 5854 gen 644248 top level 5 path home/backup-laptop/home/2024-03-03

[Dreamsorcerer]

Any recommendations on a workaround for this? I need to get something working again soon.

[Dreamsorcerer]

Ok, workaround for now is chmod +s /usr/bin/btrfs.

[kdave]

That's dangerous and should not be done, perhaps except some highly restricted environments.

[Dreamsorcerer]

The only alternative I have is to login directly as root with a passwordless SSH key...
When a better solution is presented, I'll look at updating the setup.

[Forza-tng]

The only alternative I have is to login directly as root with a passwordless SSH key... When a better solution is presented, I'll look at updating the setup.

Maybe you can get some ideas from https://digint.ch/btrbk/doc/ssh_filter_btrbk.1.html

[Dreamsorcerer]

Maybe you can get some ideas from https://digint.ch/btrbk/doc/ssh_filter_btrbk.1.html

That would be logging in as root, but restricting the commands to a whitelist, right? Would be nice to be able to do both (i.e. run all the basic backup btrfs commands as a restricted user). I'll take a look at incorporating it later regardless.

[cumber]

Is the problem that it's trying to enumerate snapshots to show in the Snapshot(s) field? Could it just not include that field (or show an unavailable indicator) if we don't have the permission rather than blocking access to all the information from subvolume show?

It's definitely awkward that I can create and delete snapshots purely from user level, but I need to get root involved just to get information about them.