this post was submitted on 27 Jun 2025
1 points (100.0% liked)

Linux

11682 readers
19 users here now

Welcome to c/linux!

Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!

Rules:

  1. Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.

  2. Be respectful: Treat fellow community members with respect and courtesy.

  3. Quality over quantity: Share informative and thought-provoking content.

  4. No spam or self-promotion: Avoid excessive self-promotion or spamming.

  5. No NSFW adult content

  6. Follow general lemmy guidelines.

founded 2 years ago
MODERATORS
[email protected]
1
Any help with a permissions issue re: containers? (sh.itjust.works)
submitted 6 days ago by [email protected] to c/[email protected]
4 comments fedilink hide all child comments
 

So I've been using rootless podman-compose to run my arr stack forever, and I've never had this issue. What seems to be happening is that sometimes, but not always, when a new folder is created or an existing folder's contents are modified, it seems to be setting the files and their folder's owner to "52587" which does not exist. This causes it to then not be able to access those files. I can manually change them back, of course, but the container just overwrites it again. If I specify the user in the compose.yml, it seems to ignore it. It is happening with a few different containers (all in the same compose.yml), as I've seen it now with Radarr and NZBget. The files are on a 12TB drive, and the container mounts and compose.yml are on the same drive, but the OS (Bazzite) is on a separate drive.

My thoughts so far for possibilities:

  1. The podman install is fucked somehow
  2. The drive itself is fucked
  3. Bazzite's weirdness is causing an issue

For #1, podman comes with Bazzite by default so I'm not entirely sure if I can rpm-ostree remove and reinstall, though that might be the next step I try. I'm not terribly good with podman to begin with so I'm not sure how to go about troubleshooting it much otherwise.

For #2, this is entirely a possibility, the drive is pretty old, but I'm not seeing any errors or anything in the SMART stuff and outside of this specific issue I have seen no other problems there.

For #3, this issue did start to happen maybe a month after switching from Arch to Bazzite, mostly because I also wanted to use this machine for Sunshine streaming and my arch install was a mess anyway. I know Arch, though, and this immutable stuff has tripped me up before, so maybe I go back. Feels like admitting defeat though, lol.

Any ideas to point me in the right direction would be greatly appreciated. Thanks!

top 4 comments
sorted by: hot top controversial new old
[–] [email protected] 0 points 6 days ago* (last edited 6 days ago)

Out of curiosity, are the containers that are having issues using non-root users internally? Podman maps your user to root inside the container, so a non-root user can have strange effects.

I had this issue when an image inherited a non-root user upstream.

[–] [email protected] 0 points 6 days ago

So I’ve been using rootless podman-compose

when a new folder is created or an existing folder’s contents are modified, it seems to be setting the files and their folder’s owner to “52587”

Rootless Docker and Podman run their applications within a user namespace. This means most of the user IDs within the container are mapped to a different uid range on the host, often called a subuid. It's part of how "rootless" mode can allow an unprivileged user to run software that expects to have privileged IDs.

https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md#etcsubuid-and-etcsubgid-configuration

which does not exist.

Are you sure it doesn't exist? Have you looked at the ranges defined in /etc/subuid on the host?

My first thought is that the uid numbers you see might be some of your host user's subuids. If so, they will appear as different uids (perhaps with usernames) within the container. Try launching a shell within the container and examining the same files, to see what their owners appear as there.

If this is what's happening, it's normal. As long as the software trying to access the files and the software creating the files are both in the same container, it should be fine. If it doesn't work, there's probably another problem in play.

By the way, Podman almost certainly has a way to map certain container uids to host uids of your choice, which can be convenient when you want to share files between containers or between a container and the host.

[–] [email protected] 0 points 6 days ago

This may be helpful: https://www.tutorialworks.com/podman-rootless-volumes/#how-to-allow-a-rootless-podman-container-to-write-to-a-volume

The real trick is set the ":Z" flag for the volume. This usually solves most problems, but will not allow that same volume to be used with other running containers.

[–] [email protected] 0 points 6 days ago

I only have experience with docker not podman so this may be completely useless, but I found that some containers respect environment variables

environment:
  - PUID=xxx
  - PGID=yyy

and some use the user mapping

user: xxx:yyy

(I guess this needs translating to uidmaps for podman). Maybe this is an issue here? Although #3 makes it sound like maybe not...