Does the new user "userB" belong to the same set of groups as the old user "userA"?

More details here: https://serverfault.com/questions/947301/nginx-displaying-failed-13-permission-denied-when-trying-to-access-new-site

Basically:

1. Check user permissions on the public directory -> You said userA and userB both have access.
2. Check that the new userB belongs to a group with rx access to the public directory for the website.

I do exactly what you describe - run multiple containers as various unprivileged service users simultaneously - and haven't had an issue doing it. The only thing that tripped me up was that I initially didn't realize that the service users needed to have a home directory created. I thought the service users wouldn't have a need for a home directory since they were single-purpose, but it turns out podman requires it to function, and if you try to run it as a user without one, it will fail to start in weird ways. Is there any chance that is the source of your issue?

Try running it with either plan podman or podman quadlets

Is the path a file or something? On my system the corresponding path is a directory with a bunch of symlinks in it. The directory has user/group matching my account with permissions set to 755. (i.e. rwxr-xr-x)

I tried rebooting thinking that could fix it as well, possibly to match mismatched kernel versions, but no changes to responses.

If I try to podman start a service, the command will sometimes hang for a bit, but always ends with the same mkdir error as the podman ps error above.

I'm not really sure what to make of that other that guessing that something's gone wrong with podman's internal state handling. Did something you ran recently crash maybe? (I'm assuming podman ps used to work for you, right?)

My kneejerk reaction is "try rebooting". If it persists there might be something odd going on with file permissions perhaps?

Discovered it was because I had just updated on system, and

uname -a

was showing a different than version than the following showing my Linux version installed

pacman -Q linux

So I simply had to reboot.

Podman works perfectly fine on systems without systemd. Alpine Linux with OpenRC is one such example.

Maybe I overreacted. I do see it as being optional. Thanks for commenting guys.

https://lemmy.ca/post/61963162

Stop spreading fud

introducing ID verification at the operating system level, how do you guys plan on slowly moving your Podman

Systemd is doing no such thing.

I have very limited experience with Podman and no experience with quadlets but I'm still curious. Are quadlets exclusive to Systemd?

I ask because I currently use Alpine Linux which uses OpenRC by default. It took a few days just to figure out how to get my HomeAssistant container to run without using a Docker Compose file. That's my only true experience with Podman so I don't actually know how dependant Podman is with Systemd.

According to this post, they are not introducing ID verification. They are adding one more optional field to the existing list of optional fields for storing data about the user.

https://programming.dev/post/47380789/22787208

Edit: add "optional"

Worked! Thank you :)

You are missing an After= for your database and redis containers.

No need to enable, it won't work nor do anything. Do need to systemctl --user daemon-reload

Might be obvious but did you enable the Quadlets? So systemctl enable quadlet.service or whatever the equivalent is. I think the quadlet is just a regular systemd unit.

Edit: I noticed you already got an answer!

This worked! I searched through so many threads trying to find an answer, and this was the answer. Thank you so much. I only needed the below text added to my ~/.config/containers/systemd/my-custom-quadlet.container. Nice and simple:

[Install]
WantedBy=default.target

Any idea how I can get Quadlet to start on system boot?

I implemented these, but my containers are not starting on system boot. I even set restart: always

Podman Quadlets is what you're after, I think.

Not something baked-in, no, since the entire point of podman is that it's server- (service-)less.

However they do have a command to manually launch the respective user's podman manager, which IIRC is podman system service -t0 (note: runs in the foreground) so if you add that to a service entry (eg.: via runit user units or systemd user scopes) or just launch it via your user crontab's @reboot, it should work without issues.

This is literally my runit user unit for podman:

#!/bin/sh
export XDG_RUNTIME_DIR=/run/user/1000
exec podman system service -t0 

This looks great! But I'm seeing here that it hasn't been updated since November 2024.

https://github.com/containers/podlet