The environment created by `buildah unshare` includes its own kernel mount namespace, so a filesystem that's mounted inside that environment won't be mounted for the shell (or script) that invoked `buildah unshare`, and it won't still be there for the next command. In short, a path returned by "buildah mount ..." from inside of a "buildah unshare" shell isn't guaranteed to be meaningful outside of that "buildah unshare" shell. The big exception to that is when you're using the "vfs" driver, which doesn't actually mount anything, and the "mountpoint" you get back from "buildah unshare buildah mount $container" is just a plain directory, both inside and outside of the `buildah unshare` environment. I suspect the difference in behavior you're seeing between the two cases is due to different storage drivers being used -- if one of them is using "vfs" and the other is using "overlay", for example, that would explain the difference what you're seeing. It's possible to work around that, though. The `buildah unshare` command can be told to mount the container's rootfs and set an environment variable to point to it using its "--mount" flag, and the command will be able to reference the variable if the shell that tries to expand the variable is run under `buildah unshare`. `buildah cp` will also create destination directories when it has to, so you can use it directly instead of `unshare`, and while the quoting is still a little awkward, this will probably work: container=$(buildah from scratch) buildah copy $container centos8-repos/*.repo /etc/yum.repos.d/ buildah copy $container centos8-repos/RPM-GPG-KEY* /etc/pki/rpm-gpg/ buildah unshare --mount fs=$container \ sh -c 'dnf --release 8 install -y -q --installroot $fs \ redhat-release glibc-langpack-en glibc-langpack-de \ glibc-langpack-ru bash shadow-utils' buildah run $container rpm -qa | sort At that point there will be enough in the container rootfs for `buildah run` to be able to exec things in the rootfs, and you should be all set. When I tried this on my box, dnf was looking for GPG keys outside of the chroot, i.e., in the host's /etc/pki/rpm-gpg, and dnf was new enough that it wasn't creating a database in the chroot in the same format that "rpm" on CentOS 8 expected, so "rpm -qa" produced an empty list, but those are problems that buildah isn't in a position to solve. HTH, Nalin