You can use podman to build that container and run it. In the directory of the container file enter 'podman build -f ’ then select the docker.io image and podman will build it for you without being root. After it is built, run it with 'podman run -it '. I just did it now, it works. You will likely need to look at the options for sharing a directory in your home, or networking possibly.
I’m not familiar with how BuildKit works but would suggest trying that in a classic Fedora virtual machine to make sure this is not specific to Silverblue and probably open a bug report for the docker or moby-engine package.
Thanks for you fast response. I can confirm, that podman works for this easy example. But for my project, I need to use a “docker sdk”, which internally calls docker directly. And it uses docker compose as well.
I’m not sure if it would work for your needs, but I am aware of podman-docker (which basically adds a symlink for you) and podman-compose (which is similar to docker-compose).
Additionally, you can use docker-compose itself with podman, as shown in this article:
The quick summary of the article, to get docker-compose working with podman, adapted to Silverblue:
(I think this can be applied live without rebooting, but rpm-ostree should tell you if you do need a reboot.)
And then you should be able to run docker-compose with podman as a backend, as long as you don’t need swarm functionality.
Again, I don’t know if it works with BuildKit or not, but it’s probably worth a try.
Also, there are a few buildkit-related packages in Fedora (which I guess you know about already?), but I don’t know if they work with podman with the compatibility stuff installed.
$ dnf search buildkit
==================================================================== Name Matched: buildkit =====================================================================
golang-github-moby-buildkit.x86_64 : Concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit
golang-github-moby-buildkit-client-connhelper-dockercontainer-devel.noarch : Concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit
golang-github-moby-buildkit-devel.noarch : Concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit
If it works on Workstation, it probably means that BuildKit is doing something fishy. We would need better logs to get the actual error. I don’t know how to do that unfortunately.