Hi,
Got Rocky 9 up and running on my home lab! All fine apart from one thing.
I have tried to install docker using the normal method. i.e. something like: How to Install Docker on Rocky Linux and AlmaLinux
There are “9” variant rpms in that repo.
But docker fails to start with the error:
failed to start daemon: mkdir /etc/docker: permission denied
which is very wierd given it runs as root AFAIK.
Anyone else tried that? I am wondering if it’s a docker thing or a rocky thing…
Yes, but docker isn’t supported, see Podman and Buildah instead.
I followed your instructions and it works. It does not mention that you need to logout/login after you run the usermod command to add the user to the docker group. The group changes take effect on next login.
Alternatively, you could also run newgrp which eliminates the need to log out and in.
Ah, for me the it is docker service itself that won’t start.
i.e. systemctl start docker.
So that bit doesn’t even rely on me being in the docker group.
Interesting that it worked for you guys.
I must have messed something up.
I’ll keep digging.
EDIT: I think it’s probably because that repo “9” is centos stream which will be different to Rocky 9. Or different enough. At least that is my understanding. I should have a look at podman.
You guys are an inspiration. We are learning loads from you guys @nazunalika @iwalker @joebeasley3 @jlehtone keep it up and we appreciate it men.
I ran into exactly the same issue yesterday when trying to install docker-ce 20.10.17 on a fully updated Rocky 9 VM. Turns out that this is apparently an selinux issue:
# ausearch -c dockerd
----
time->Fri Jul 29 15:20:32 2022
type=PROCTITLE msg=audit(1659075632.966:1964): proctitle=2F7573722F62696E2F646F636B657264002D480066643A2F2F002D2D636F6E7461696E6572643D2F72756E2F636F6E7461696E6572642F636F6E7461696E6572642E736F636B
type=SYSCALL msg=audit(1659075632.966:1964): arch=c000003e syscall=179 success=no exit=-13 a0=580502 a1=7f57d0000b60 a2=0 a3=c000c1eb28 items=0 ppid=1 pid=12518 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dockerd" exe="/usr/bin/dockerd" subj=system_u:system_r:container_runtime_t:s0 key=(null)
type=AVC msg=audit(1659075632.966:1964): avc: denied { quotaget } for pid=12518 comm="dockerd" scontext=system_u:system_r:container_runtime_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem permissive=0
----
time->Fri Jul 29 15:20:32 2022
type=PROCTITLE msg=audit(1659075632.967:1965): proctitle=2F7573722F62696E2F646F636B657264002D480066643A2F2F002D2D636F6E7461696E6572643D2F72756E2F636F6E7461696E6572642F636F6E7461696E6572642E736F636B
type=SYSCALL msg=audit(1659075632.967:1965): arch=c000003e syscall=258 success=no exit=-13 a0=ffffffffffffff9c a1=c00023c950 a2=1ed a3=7f58001181a0 items=0 ppid=1 pid=12518 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dockerd" exe="/usr/bin/dockerd" subj=system_u:system_r:container_runtime_t:s0 key=(null)
type=AVC msg=audit(1659075632.967:1965): avc: denied { create } for pid=12518 comm="dockerd" name="docker" scontext=system_u:system_r:container_runtime_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0
Switching selinux off or to permissive mode “fixes” the issue, but obviously that’s not exactly a clean solution.
Two observations:
container-selinux package is installed and should contain policies that allow the directory creation and subsequent operations by dockerd / runc, but apparently that’s not working for some reason.docker-ce version on a fully patched RHEL 9 VM, and things are working fine, so this seems to be Rocky-specific …@nazunalika: Is there a better place to open an issue about this than the forums?
You can use the selinux tools to resolve selinux issues without having to turn selinux into permissive mode. Once the problem occurs, you can then from the console do:
audit2allow -a /var/log/audit/audit.log
based on the results, you can then follow the command suggested to create a policy. Obviously the command I gave would then allow all violations. Once you view the output, and let’s say the suggested violation is named docker_t, then what you can do is this to filter even more:
grep docker_t /var/log/audit/audit.log | audit2allow -M my-docker-rules
then you can install the created module with:
semodule -i my-docker-rules
and you will have resolved the issue in a more controlled pattern than by allowing all violations that would have shown in the first command I posted.
Hi @iwalker,
Thanks a lot for the quick response. I will definitely give the custom selinux policy a shot and report back here.
Still, the question remains why this is apparently necessary on Rocky 9 and not on RHEL 9, with both having the same versions of docker-ce (3:20.10.17-3.el9) and container-selinux (3:2.179.1-1.el9_0) installed.
I don’t have an RHEL9 to hand, but you could compare the content of each files within that container-selinux package to see if there are any differences. I see 20 files in that package in total, but not all of them will have an effect on selinux itself, so could be easy enough to nail it down. The copy both files to your system and do a diff between them. Theoretically there shouldn’t be any differences, but it could be one way to find out.
This is likely due to the container-selinux package being built in an incorrect order when we bootstrapped 9.0. We are pushing an update over the weekend that should hopefully address this (as well as podman.service issues that were reported at our bug tracker).
Fantastic. I also had issues with podman!
I will give both docker-ce and podman a go again next week after the updates arrive.