-
Bug
-
Resolution: Duplicate
-
Undefined
-
None
-
None
-
None
-
False
-
sat-rocket
-
None
-
None
-
None
-
None
When attempting to enable IOP on a disconnected Satellite the containers can fail to start due to overlay access issues.
To reproduce;
1) Configure a Satellite with a default umask of 0027. Most users configure this as part of CIA profiles, like CIS Benchmark Level 2 for RHEL 9. This can be applied via the the collection provided by Ansible;
ansible-galaxy install RedHatOfficial.rhel9_cis
Or via openscap;
dnf install openscap-scanner scap-security-guide oscap xccdf eval --remediate --profile xccdf_org.ssgproject.content_profile_stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
2) Import the containers as noted in the documentation
3) The containers will import without error, but some containers will not be able to run, for example;
[root@satellite ~]# podman run -it --entrypoint /bin/bash fe9de9694285
{"msg":"exec container process `/bin/bash`: Permission denied","level":"error","time":"2026-02-24T03:49:30.266372Z"}
This is due to the umask at the time of the container import. If the containers are imported with umask 0022 they have no issues. This can be set in the import script, for example;
[root@satellite ~]# cat setup_containers #!/bin/bash umask 0022 images=( "satellite/iop-ingress-rhel9:6.18" "satellite/iop-advisor-frontend-rhel9:6.18" ...
The 7 umask to "others" prevents the container users from access other images layers and prevents them from being able to run.
- duplicates
-
SAT-41866 Disconnected STIG environment iop install failure due to UID mismatch
-
- To Do
-