#1

Hi! I’m excited for Silverblue, really like container-based workflows, and have been slowly transitioning my projects to use podman. One problem that I’m encountering is with a Yocto-based project – namely, the bitbake utility doesn’t like being run as root (inside the container). In order to please bitbake, I changed the in-container uid to 1001, but this created a weird situation where I was unable to write to any files created from inside the container on my host. (Right now, I’m running neovim on my host OS, and this is problematic because many of bitbake's companion tools require you to edit files it generates.) All the problematic files had permissions 0644 and were owned by uid 100999, which makes sense given the contents of /etc/subuid.

Is there a way I can work around this and assign container uid 1001 to my host uid? In the ideal case, I don’t need to modify /etc/subuid and can simply hand off my repository including a Makefile that calls out to podman to anyone with podman and user namespaces. Thanks!

#2

Welcome to the wonderful world of containers, we hope you enjoy your stay. :grin:

What if you make the in-container UID the same as your normal user, e.g. 1000? I’ve often done this with no trouble. Also, it may or may not be relevant, but what SELinux-related flags are you passing in?

As a side note, depending on what exactly you’re trying to accomplish, fedora-toolbox may be helpful.

#3

After your suggestion, my testing podman command-line is:

$ podman run --rm -it -v ${ROOT}/yocto:/app/yocto:Z \
    -v ${ROOT}/${BUILD_DIR}:/app/build:Z \
    -u $(id -u):$(id -g) \
    -w /app \
    /bin/bash

Inside the container, I attempted to touch a file in /app/build, and that failed with Permission denied. It turns out this doesn’t pass a permission check, since all the files in the volumes are owned by root inside the container.

To clarify, I’m not running this on Silverblue, just traditional Workstation, but I’m trying to prepare all my personal projects for an exciting Silverblue future.

#4

What if you either delete the volumes or sudo chown -R $USER directory them? They might still have some screwy permissions from before.

#5

The default behavior for rootless podman is root inside the container is mapped to your user, and other UIDs in the container are mapped into high UID’s in your subuid range (see /etc/subuid). So you need to either:

If you note everything else that toolbox is doing to create a seamless interactive environment, you might want to consider just using toolbox :slight_smile: toolbox has some initial support for multiple containers, which would allow for a project-specific toolbox, if you want to go that way, though the basic mode of toolbox is just to have a single “fedora 30” toolbox. We’d love to find out about anything you find missing or difficult with toolbox!

#6

Thank you so much, this works!

Yes, I understand toolbox is the right way to go here :slight_smile: . That said, my goal here is to create a Makefile that is reasonably portable for non-Fedora users too. I’m hoping to be able to use something similar at work, where we all use Ubuntu.