Locations owned by nobody:nobody can fail RPM transactions

[garrett]

Describe the bug
Installing any libvirt related utilities such as libvirt-client or virt-viewer now fails within toolbox. It used to work before (up until a few weeks ago).

Now, it's met with:

Error unpacking rpm package libvirt-libs-6.6.0-3.fc33.x86_64
error: unpacking of archive failed on file /var/lib/libvirt: cpio: chown
error: libvirt-libs-6.6.0-3.fc33.x86_64: install failed

Steps how to reproduce the behaviour

1. Inside a toolbox container, run sudo dnf install -y libvirt-client
2. See error

Expected behaviour
libvirt-client should be installable inside of toolbox

Actual behaviour
An error happens when trying to install libvirt-libs

Output of toolbox --version (v0.0.90+)
toolbox version 0.0.97

Toolbox package info (rpm -q toolbox)
toolbox-0.0.97-1.fc33.x86_64

Output of podman version

Version:      2.2.0
API Version:  2.1.0
Go Version:   go1.15.5
Built:        Tue Dec  1 18:04:57 2020
OS/Arch:      linux/amd64

Podman package info (rpm -q podman)
podman-2.2.0-2.fc33.x86_64

Info about your OS
Fedora Silverblue 32

Additional context
We use the libvirt utilities while building VMs for Cockpit. This has worked in a toolbox container for over a year. It stopped being installable a few weeks ago. (I assumed it was something wrong on my system and/or the RPM itself, until I reinstalled Silverblue to get btrfs and tried rebuilding the container from scratch.)

Without this working properly, I will no longer be able to use Silverblue, as I depend on toolbox to let me build and run VMs inside a development container. 😢 I'm sure a lot of other developers might be in the same situation.

While the error looks similar to #629, I think this is different (although may have a similar root cause, with mapping the host directory into the container).

The most recent change related to libvirt I've seen is related to the minikube commit @ a8a7742 (from issue #379 / PR #548). Perhaps enabling minikube broke libvirt-related packages inside of toolbox?

[garrett]

I've found a workaround to sudo umount /var/lib/libvirt before installing the package.

Hopefully a proper fix will come soon. (Meanwhile, adjusting my toolbox container build script...)

[debarshiray]

Yes, this is a known problem.

Here's the downstream Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1830830

Here's an attempted pull request to address this: #640

The problem is that, in rootless containers, bind mounts from the host have their ownership set to nobody:nobody if they aren't owned by the user. RPM doesn't like this and complains.

[debarshiray]

Should be fixed by #640

[debarshiray]

My apologies for the delay, and thanks for your patience. :)

[cassidyjames]

I'm getting this again today in my Fedora 38 and 39 containers when trying to install Flatpak; is it possible this has regressed? @garrett's suggestion of unmounting /var/lib/flatpak and then installing Flatpak indeed worked.

Edit: d'oh! I am on an old version of Toolbx. So of course I wouldn't have this fix. Sorry for the noise.