How to fix selinux config issues in context of a podman, i am getting /lib64/libc.so.6: cannot apply additional memory protection after relocation: Permission denied

[groovyman]

Dear friends,

i am getting an error, when i am running a podman build on technical user account, that has its home-dir on a mounted raid.
The running os i a standard fedora-server-39.

Firstly i ran into a similar problem like #3234, my podman build reported a /lib64/libc.so.6: cannot apply additional memory protection after relocation: Permission denied and @rhatdan conclusion showed me the way to copy with this problem:

// determine the graphRoot path
$ podman info | grep graphRoot

// setup alleged moved storage directory give me an error:
# semanage fcontext -a -e /var/lib/containers /mnt/raider/home2/techlxoffice/.local/share/containers/storage
ValueError: SELinux policy is not managed or store cannot be accessed.

# restorecon -R -v /home/root/containers

Finally, a google-search led me to a simplified test case, running a simple fedora inside podman:

/mnt/raider/home2/techlxoffice$ podman run -i -t registry.fedoraproject.org/fedora bash
bash: error while loading shared libraries: /lib64/libc.so.6: cannot apply additional memory protection after relocation: Permission denied

I think, that the problem came from the way i set up the technical user. I freshly installed a fedora-server on a ssd a mounted a raid-Disk to this machine. The i used the cockpit-web to create some technical users (with the home partition on the mounted raid). I believe, that the home-dir creation of the technical user are not made to be located on a mounted drive/raid-device.

Do you have any ideas how analyse this problem ?

[rhatdan]

This is an selinux issue, take a look at the storage.conf man page and the section about labeling alternative containers/storage rather then the default in a user homedir.

[radeksm]

I run into the same problem while bulding chromadb container image, nothing special simply:
podman build -f Dockerfile -t localhost/chromadb:latest .
I managed to fix the problem by running this command as the same user which builds container image:
restorecon -R -v ~/.local/share/containers/storage