Please provide repo for docker-ce on Fedora 32

[hhlp]

• [ ] This is a bug report
• [x] This is a feature request
• [x] I searched existing issues before opening this one

The Docker-CE Fedora repository is the recommend way to install recommended way. It has many benefits over installing from a package or any other method.

Fedora also releases a new version every six months. The Fedora repository also takes a very long time to become ready after the release of a new version, with many issues being opened after each recent Fedora is release.

Fedora has officially branched Version 32 February 11/2020 and might have a beta release on March 17/2020.

I'm filing this issue to hopefully put this task on the radar, so that there might be a repository set up in time for the Fedora 32 release cycle....

NOTE

Some of us migrate when the beta version is ready so we have to disable the repository and wait for it to be ready

Release Schedule: https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html

Regards.,

[vincent-olivert-riera]

It seems this won't happen on time for tomorrow's release. Perhaps the focus has been put on getting cgroupsv2 working? https://github.com/opencontainers/runc/issues/2315

[kiview]

Just noticed that Docker container have no internet connectivity after upgrade to Fedora 32. User needs to add docker network interface to trusted firewall zone. I hope official package will keep this in mind and configure firewalld accordingly.

[christian-korneck]

I have upgraded my Fedora 31 workstation to Fedora 32. Here are some issues I've experienced with Docker (most of them have been reported by other people above, but I'm trying to give some details).

1.) Since Fedora 31 cgroups v2 is enabled by default. To be able to run Docker you need to revert to cgroups v1 by setting a parameter in the kernel cmdline. (Not a bug, just mentioning it for completeness).

grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
reboot

2.) There is no Fedora 32 repo for Docker, so updates fail. (I had Docker already installed on Fedora 31).

$ dnf repolist docker-ce-stable --verbose
error: Status code: 404 for http://download.docker.com/linux/fedora/32/repodata/repomd.xml (IP: 13.35.253.112) (http://download.docker.com/linux/fedora/32/repodata/repomd.xml).

3.) there's an iptables issue. From inside a Docker container pinging any destination works. However, tcp/udp connections don't work (i.e. the local DNS server set by Docker in the container can only be pinged, but not reached on the DNS service).

journalctl -t firewalld shows these errors after booting:

firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -F DOCKER' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -X DOCKER' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -F DOCKER-ISOLATION-STAGE-1' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -X DOCKER-ISOLATION-STAGE-1' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -F DOCKER-ISOLATION-STAGE-2' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -X DOCKER-ISOLATION-STAGE-2' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -F DOCKER-ISOLATION' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -X DOCKER-ISOLATION' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -D FORWARD -i docker0 -o docker0 -j DROP' failed: iptables: Bad rule (does a matching rule exist in that chain?).
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -D FORWARD -i docker0 -o docker0 -j DROP' failed: iptables: Bad rule (does a matching rule exist in that chain?).

As someone mentioned above, adding the Docker interface to the trusted firewall zone is a quick workaround:

firewall-cmd --permanent --zone=trusted --add-interface=docker0
firewall-cmd --reload

[davidkna]

The networking issues appear to be caused by firewalld switching to nftables. The changeset also has some recommendations for solvings this issue which to also appear to amount to making docker0 part of a trusted zone.

[Bouhnosaure]

I had this same issue and i wasn't able to ping anything within a container, I've fixed it with :

firewall-cmd --get-zone-of-interface=enp1s0
   FedoraWorkstation

firewall-cmd --zone=FedoraWorkstation --add-masquerade --permanent

firewall-cmd --reload

[nlzet]

I had this same issue and i wasn't able to ping anything within a container, I've fixed it with :

firewall-cmd --get-zone-of-interface=enp1s0

   FedoraWorkstation

firewall-cmd --zone=FedoraWorkstation --add-masquerade --permanent

firewall-cmd --reload

another solution for now is changing the firewalld.conf “FirewallBackend” from nftables to iptables

[quackerd]

Changing FirewallBackend to iptables worked for me on CentOS 8 which defaults to nftables like Fedora 32 does. Docker or libnetwork need to support nftables natively.

[KevinAtSesam]

I had trouble connecting to my local Kafka instance after upgrading to Fedora 32. Something with the routing messed up. I could connect to my local webserver, but the webserver could not communicate with Kafka.

I've corrected the issue, in two steps:

• I added the the docker0 interface to the trusted list, as instructed by https://github.com/docker/for-linux/issues/955#issuecomment-620932240
• I set masquerading on for my zone FedoraWorkstation, as instructed by https://github.com/docker/for-linux/issues/955#issuecomment-621141128

[yrsurya]

while running docker run with --network=host is also worked for me as I don't want to update those firewalls manually. will wait to hear if this can be reolved soon in latest repos which supports fedora32.

[tymokvo]

:arrow_up: same, and can be achieved in a docker-compose.yml with:

    build:
      network: host

under the appropriate service entries.

[christian-korneck]

running docker run with --network=host is also worked for me

I don't think that's what you usually want. With --network=host you loose container network isolation and your containers have the same interfaces and IPs as the host. (This is useful when you i.e. want to run a packet capture program in a container that should have access to the host's network interface).

[Kidlike]

How are we supposed to install docker on a fresh fedora system? The official instructions (https://docs.docker.com/engine/install/fedora/) don't work...

[vincent-olivert-riera]

How are we supposed to install docker on a fresh fedora system? The official instructions (https://docs.docker.com/engine/install/fedora/) don't work...

I think Fedora doesn't care about Docker any more and they just ship podman instead.

You need to wait until the Docker rpm packages for Fedora 32 are built. Or, you can just install the ones for Fedora 31, which should also work.

[jpopelka]

dnf install moby-engine works for me (after tinkering with cgroups and firewall)

[Frosthage]

dnf install moby-engine works for me (after tinkering with cgroups and firewall)

Have you managed to make it run containers from a docker-compose file?

[quackerd]

I think Fedora doesn't care about Docker any more and they just ship podman instead.

Docker needs to support nftables and cgroups v2. Debian Buster uses nftables backend by default and had problems with docker too. The workaround is basically - 1. tell the kernel to use cgroup v1. 2. set firewalld backend to iptables or disable firewalld.

[vincent-olivert-riera]

Docker needs to support nftables and cgroups v2. Debian Buster uses nftables backend by default and had problems with docker too. The workaround is basically - 1. tell the kernel to use cgroup v1. 2. set firewalld backend to iptables or disable firewalld.

I know, I know:

$ cat /proc/cmdline 
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.6.8-200.fc31.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet resume=/dev/mapper/fedora-swap usbcore.autosuspend=-1 systemd.unified_cgroup_hierarchy=0

$ systemctl is-active firewalld
inactive

$ systemctl is-active docker
active

[jpopelka]

Have you managed to make it run containers from a docker-compose file?

yes

[Kidlike]

Actually when I ignored the official instructions and just blindly tried dnf install docker, it worked because Fedora has an alias for moby-engine. it's actually docker version 19.03.8.

The rest is the same old story - cgroups, selinux, user groups, etc...

[Frosthage]

Have you managed to make it run containers from a docker-compose file?

yes

How? My google fu is failing me. :/

[lexfrei]

@Frosthage use docker stack:

# install
dnf install moby-engine
# remove live-resotore line
vim /etc/sysconfig/docker
# enable and start docker
systemctl enable --now docker
# create one node swarm cluster
docker swarm init
# delpoy
docker stack deploy -c docker-compose.yml redis

Tested on clean f32 just right now, for you <3

[jpopelka]

How? My google fu is failing me. :/

I don't remember any specific docker-compose related hacks. I think all I had to do (F32) was:

• grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
• firewall-cmd --permanent --zone=FedoraWorkstation --add-masquerade
• dnf install moby-engine docker-compose
• systemctl enable docker
• reboot

And docker-compose build & docker-compose up work with my docker-compose.yml

[Frosthage]

@lexfrei @jpopelka Thanks heaps!

[sparish-xevo]

In addition to the steps people have listed above, I also had a br-<ugly-hash> interface that I had to set as trusted before my docker containers were able to talk to each other. Found it by running firewall-config.

[navjotjsingh]

Is there any ETA on an official Fedora 32 repo?

[rhubarbselleven]

After reading this and the commentary here I read the following: https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/

Installed podman and all issues disapeared. Really don't want to be maintaining kernel options - otherwise I'd be running Gentoo again

[vincent-olivert-riera]

Really don't want to be maintaining kernel options

I guess you are talking about the kernel option for using cgroups v1. That's only temporary since the Docker team are working on adding support for cgroups v2: https://github.com/opencontainers/runc/issues/2315

[rhubarbselleven]

Yeah but when this is all done and dusted - I'm not going to remember to go and undo all of that

[SuperSandro2000]

I'm not going to remember to go and undo all of that

Sounds like you need some configuration management in a git history with comments.

I am have the feeling that redhat/fedora want to push buildah cause on Debian/Ubuntu I never need to change any kernel options.

[N-ickJones]

I have upgraded my Fedora 31 workstation to Fedora 32. Here are some issues I've experienced with Docker (most of them have been reported by other people above, but I'm trying to give some details).

1.) Since Fedora 31 cgroups v2 is enabled by default. To be able to run Docker you need to revert to cgroups v1 by setting a parameter in the kernel cmdline. (Not a bug, just mentioning it for completeness).

grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
reboot

2.) There is no Fedora 32 repo for Docker, so updates fail. (I had Docker already installed on Fedora 31).

$ dnf repolist docker-ce-stable --verbose
error: Status code: 404 for http://linux.dropbox.com/fedora/32/repodata/repomd.xml (IP: 13.35.253.112) (http://linux.dropbox.com/fedora/32/repodata/repomd.xml).

3.) there's an iptables issue. From inside a Docker container pinging any destination works. However, tcp/udp connections don't work (i.e. the local DNS server set by Docker in the container can only be pinged, but not reached on the DNS service).

journalctl -t firewalld shows these errors after booting:

firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -F DOCKER' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -X DOCKER' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -F DOCKER-ISOLATION-STAGE-1' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -X DOCKER-ISOLATION-STAGE-1' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -F DOCKER-ISOLATION-STAGE-2' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -X DOCKER-ISOLATION-STAGE-2' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -F DOCKER-ISOLATION' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -X DOCKER-ISOLATION' failed: iptables: No chain/target/match by that name.
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -D FORWARD -i docker0 -o docker0 -j DROP' failed: iptables: Bad rule (does a matching rule exist in that chain?).
firewalld[854]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -D FORWARD -i docker0 -o docker0 -j DROP' failed: iptables: Bad rule (does a matching rule exist in that chain?).

As someone mentioned above, adding the Docker interface to the trusted firewall zone is a quick workaround:

firewall-cmd --permanent --zone=trusted --add-interface=docker0
firewall-cmd --reload

I had this same issue and i wasn't able to ping anything within a container, I've fixed it with :

firewall-cmd --get-zone-of-interface=enp1s0
   FedoraWorkstation

firewall-cmd --zone=FedoraWorkstation --add-masquerade --permanent

firewall-cmd --reload

My fix involved both of these solutions.

Fix the c group issue

dnf install grubby grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0" reboot

fix the first docker network issue (internet connection)

firewall-cmd --permanent --zone=trusted --add-interface=docker0; firewall-cmd --reload;

fix the second docker network issue (communication between containers)

Find your network interface ip addr # Example: mine was ens33 with altname enp2s1

Additional step to assign a zone to my interface

firewall-cmd --get-default-zone FedoraWorkstation firewall-cmd --get-zone-of-interface=ens33 no zone firewall-cmd --get-zone-of-interface=enp2s1 no zone firewall-cmd --permanent --zone=FedoraWorkstation--add-interface=ens33; firewall-cmd --permanent --zone=FedoraWorkstation --add-interface=enp2s1;

firewall-cmd --zone=FedoraWorkstation --add-masquerade --permanent firewall-cmd --reload

Now everything seems to be working correctly. Thanks for the help.

[gregmartyn]

@N-ickJones what version of docker are you on now? docker --version docker-compose --version

[N-ickJones]

@N-ickJones what version of docker are you on now? docker --version docker-compose --version

Hey Greg,

This is the output for those two commands:

Docker version 19.03.9, build 9d98839 docker-compose version 1.25.4, build unknown

[damaestro]

There is a new zone, libvirt, that can be used so you don't modify your default FedoraWorkstation zone. It fixed my issues after upgrade.

[jon@dahome ~]$ sudo firewall-cmd --permanent --zone=FedoraWorkstation --add-interface=docker0
The interface is under control of NetworkManager, setting zone to 'FedoraWorkstation'.
success
[jon@dahome ~]$ docker run -it alpine /usr/bin/nslookup github.com 1.1.1.1
nslookup: write to '1.1.1.1': Host is unreachable
;; connection timed out; no servers could be reached

[jon@dahome ~]$ sudo firewall-cmd --permanent --zone=libvirt --add-interface=docker0
The interface is under control of NetworkManager, setting zone to 'libvirt'.
success
[jon@dahome ~]$ docker run -it alpine /usr/bin/nslookup github.com 1.1.1.1
Server:     1.1.1.1
Address:    1.1.1.1:53

Non-authoritative answer:
Name:   github.com
Address: 140.82.112.3

[damaestro]

There is a new zone, libvirt, that can be used so you don't modify your default FedoraWorkstation zone. It fixed my issues after upgrade.

https://bugzilla.redhat.com/show_bug.cgi?id=1817022 seems to have much more detail and gives a few options. I seem to have issues with some internal connections still, but I was able to get general network access working using the new zone. It might also be a completely unrelated upgrade issue that I've not found yet.

[rforberger]

I also need the Docker packages for Fedora 32 x86_64.

[nlzet]

I also need the Docker packages for Fedora 32 x86_64.

For now (as a workaround) you can edit the repository file and install the version for fedora 31.

Replace $releasever with 31 in /etc/yum.repos.d/docker-ce.repo

[rforberger]

Thanks @nlzet

I know about the workaround, but don't want to apply it, since I will have to switch back to the $releasever variable, once packages for Fedora 32 come available.

[yrsurya]

docker: Error response from daemon: cgroups: cgroup mountpoint does not exist: unknown.

Anyone seeing this error?

[philbates35]

The latest version of the moby-engine package pushed to Fedora 32 repo (19.03.8-2.ce.gitafacb8b.fc32) now provides its own docker zone out of the box that docker0 is assigned to:

$ firewall-cmd --get-active-zones
FedoraWorkstation
  interfaces: wlp2s0
docker
  interfaces: docker0
libvirt
  interfaces: virbr0

So no more need to tinker around moving it to trusted / libvirt zone.

However this still wasn't enough to allow didn't get my web container to communicate with my db container specified in my docker-compose. I still had to additionally run:

# probably want to run this with --permanent
$ firewall-cmd --zone=FedoraWorkstation --add-masquerade

[fbsanchez]

I had this same issue and i wasn't able to ping anything within a container, I've fixed it with :

firewall-cmd --get-zone-of-interface=enp1s0
   FedoraWorkstation

firewall-cmd --zone=FedoraWorkstation --add-masquerade --permanent

firewall-cmd --reload

It's a workaround, works for individual containers but seems it has problems while you're trying to create a network of containers...

Masquerading forces container [A] to be identified as 'gateway' by container [B], staying both containers connected to same network...

I'm still searching for a solution...

[Kidlike]

The only thing that solved all networking issues for me, was to switch firewalld's backend to iptables instead of the new nftables.

[fbsanchez]

For me following has worked:

Cleanup:

firewall-cmd --permanent --zone=public --remove-masquerade
firewall-cmd --permanent --zone=public --remove-interface=docker0

Zone adjustment:

firewall-cmd --permanent --zone=libvirt --add-interface=docker_gwbridge 
firewall-cmd --permanent --zone=libvirt --add-interface=docker0

If custom networks:

firewall-cmd --permanent --zone=libvirt --add-interface=br-$(docker network ls --filter "name=mynetwork" -q)

[Kidlike]

@fbsanchez if I understand this correctly, in the case of using docker stack, I would have to add that custom network rule for each docker stack right?

By default stacks create a network called {stackName}_default. Would I need to add the firewall rule every time I destroy/create the same stack, or once is enough?

[fbsanchez]

Hi @Kidlike just tested, you can define 'default' zone to libvirt so all new ones will use that zone:

# firewall-cmd --set-default-zone=libvirt

So all new networks will be linked to that zone.

Hope it helps.

[ambigus9]

How? My google fu is failing me. :/

I don't remember any specific docker-compose related hacks. I think all I had to do (F32) was:

• grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
• firewall-cmd --permanent --zone=FedoraWorkstation --add-masquerade
• dnf install moby-engine docker-compose
• systemctl enable docker
• reboot

And docker-compose build & docker-compose up work with my docker-compose.yml

Thanks! Works perfectly!

Can you confirm how to add docker to the sudo group?

[damaestro]

https://developer.fedoraproject.org/tools/docker/docker-installation.html has the Fedora recommended instructions.

[ambigus9]

@damaestro It works even for F32?

[damaestro]

@damaestro It works even for F32?

@ambigus9 sorry I was not clear. There are instructions there on how to setup non-root Docker access on Fedora:

Why can’t I use docker command as a non root user, by default? The Docker daemon binds to a Unix socket instead of a TCP port. By default that Unix socket is owned by the user root and other users can access it with sudo. For this reason, Docker daemon always runs as the root user.

You can either set up sudo to give docker access to non-root users.

Or you can create a Unix group called docker and add users to it. When the Docker daemon starts, it makes the ownership of the Unix socket read/writable by the docker group.

Warning: The docker group is equivalent to the root user; For details on how this impacts security in your system, see Docker Daemon Attack Surface for details.

To create the docker group and add your user:

$ sudo groupadd docker && sudo gpasswd -a ${USER} docker && sudo systemctl restart docker $ newgrp docker You have to log out and log back in (or restart Docker daemon and use newgrp command as mentioned here) for these changes to take effect. Then you can verify if your changes were successful by running Docker without sudo.

[lwhitty]

I had this same issue and i wasn't able to ping anything within a container, I've fixed it with :

firewall-cmd --get-zone-of-interface=enp1s0
   FedoraWorkstation

firewall-cmd --zone=FedoraWorkstation --add-masquerade --permanent

firewall-cmd --reload

It's a workaround, works for individual containers but seems it has problems while you're trying to create a network of containers...

Masquerading forces container [A] to be identified as 'gateway' by container [B], staying both containers connected to same network...

I'm still searching for a solution...

The masquerade option also breaks programs like fail2ban running on containers since upstream source addresses are no longer logged correctly. A fail2ban rule match now blocks all traffic coming from the container host.

[damaestro]

The only thing that solved all networking issues for me, was to switch firewalld's backend to iptables instead of the new nftables.

I also moved firewalld back to iptables while upstream(s) work out how to handle this, and I'm not seeing any issues (also using cgroups v1.)