I have a docker folder in my home directory, where docker-compose is located along with app specific folders, e.g. nextcloud, some nginx-app and so on.
Yesterday I updated Fedora 38->39 and due to some problems with xauth I chowned the entire home folder to my default user. Since then the pages served by the webserver show “403 Forbidden” and the nextcloud page implies the config.php couldn’t be read correctly, making me think there’s a permissions issue.
These files were likely created through docker in the first place, since they are designated in the docker-compose.yml . Would they create files with container specific users like www-data (which I don’t have in the system in general), if you have them, what do the permissions look like?
If you are using bind volumes, where a host folder is mapped into a container folder, then you need to make sure the uid:gid of the host folder and files in it, are aligned with the uid:gid of the process inside the container.
The Dockerhub description should mention which UID:GID is used. If not, you can docker exec into the container and execute id if the USER instruction was used in the Dockefile of the image or ps auxfn to see which process is executed with which user id.
Yes, that’s right, I have them mapped to a container folder. For Nextcloud I have one mapping within the home folder (where I changed chown to my user), and one mapping to a drive for files (unchanged) (user 33, group tape).
Inside the nextcloud container user www-data is set as default for all files and folders (the config file was root though). Container-cd to the external mapping for files doesn’t display them (is this expected?) . Running id returns root on all fields. Running ps auxfn returns PIDs with both 0 and 33.
I am not entirely sure what this means. But I assume you mean if you change into the container folder where you mapped the host folder into, you don’t see the files. It could be a SELinux permission issue. If I remember right, binds require :z or :Z when SELinux is enforced (see: https://docs.docker.com/storage/bind-mounts/#configure-the-selinux-label).
Changing to 33:tape directly in the mapped folder or www-data:www-data (likely equivalent) in the container seems to get rid of the config inaccessible error, so that seems to be solved.
However now it generates the somewhat expected error, which is good, that data is inaccessible.
Since I don’t think I did any changes to the data folder, is it possible that the Fedora upgrade could have changed SELinux-settings (enabled according to sestatus) (which in turn should make this a more prevalent issue than my chown mindlessness)?
After some more testing I put setenforce 0 and restarted the container (and the docker service), which generated the same problem. Maybe I need to do a full reboot with setenforce 0 to know for sure though.
Edit: I think I found the solution to the last problem, which has to do with that drives are mounted different due to unrelated login issues after F39, which was the root cause of the chown messup in the first case.