I can only infer you have a problem with selinux. You are mounting some hostpath to containers. When doing this, you need to label the path so that a container is able to access it based on current selinux policies. You can label the path manually, but in docker/podman there is an auto-relabelling mechanism via the z/Z letter at the end of the mountpoint like so:
volumes:
- ./hostpath:/container_mountpoint:z
so add “:z” at the end of your volume definitions and redeploy and see if the problem is coming from here. When inspecting the hostpath with ls -laZ you will notice the selinux label changed.
It is true, very often in development mode you tend to make changes to the containers storage while it is running. Very often we create docker/podman-compose setups to simulate as closely as possible the production runtime with networks etc. Or maybe you just want to connect pgadmin to your container so that you can query the db while it is running.
However one important idea here is that containers were designed to be a contained process that should not easily get access to host, for security reasons. So in development mode we are starting to see all sorts of blockages - but let’s get back to your concrete problem.
That “unknown” user should be a number from a range specified in your host system “/etc/subuid” file. Go ahead and cat this file and you will notice something like “myuser:startrange:endrange”. So the uid you see with ls -laZ should be from that range… So podman is creating a temporary user from that range. This is the base linux security model - something called Discretionary Access Control (DAC) - which means that every process is allowed to access only what it owns, not more than that. This specific feature from /etc/subuid is called “User Namespaces”. Every time you restart your podman, it will assign a new user and this is part of security. You could “sudo chown myuser:myuser /myfolder” so that you can edit the file from your host but this will mean that you will edit the file from the host but then the container process might fail again because the file ownership changed etc.
You could do something like
sudo podman-compose up
then the folder will not be owned by a dynamic user but by your direct linux user… so you will need to start your edit process in privileged mode like in the case of visual studio code: