Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
If one configures overlay2 driver, looks like docker fails to run container. I can run same container with overlay driver.
# docker run -ti fedora bash
Unable to find image 'fedora:latest' locally
Trying to pull repository registry.access.redhat.com/fedora ...
Pulling repository registry.access.redhat.com/fedora
Error: image fedora:latest not found
Trying to pull repository docker.io/library/fedora ...
latest: Pulling from docker.io/library/fedora
2bf01635e2a0: Pull complete
Digest: sha256:64a02df6aac27d1200c2572fe4b9949f1970d05f74d367ce4af994ba5dc3669e
Status: Downloaded newer image for docker.io/fedora:latest
bash: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: Permission denied
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
Dan,
It indeed is SELinux issue. I set selinux in permissive mode and running container worked. Following is avc.
type=AVC msg=audit(1471961779.544:9632): avc: denied { read } for pid=6527 comm="bash" name="libtinfo.so.6.0" dev="dm-0" ino=1363793 scontext=system_u:system_r:svirt_lxc_net_t:s0:c786,c1001 tcontext=system_u:object_r:docker_var_lib_t:s0 tclass=file
overlay works and I see the label docker_share_t on overlay dir and its child. But overlay2 still is docker_var_lib_t and that probably is the problem.
This looks like labeling is not working. docker_var_lib_t is the default label of /var/lib/docker, which is not supposed to be used in docker. Overlay and SELinux do not work together in RHEL7. Until we get the patches in. So your dockerd should not be run with selinux-enabled. Sadly the current patch that prevents this only looks for overlay not overlay2.
Ok, it worked for me when I removed --selinux-enabled from /etc/sysconfig/docker-latest.
So for now, people can use it the way they use overlay. That is remove --selinux-enabled and things should work.
p10sunu, I am the last person in the world to tell people to disable SELinux. But until the RHEL7.4 kernel ship the choice is to run SELinux with Device Mapper Back end or disable SELinux for container work loads when running Overlay. The kernel needs to be fixed to make both run together.