The Same Install Command, Two Different Outcomes
On Huawei Cloud EulerOS, dnf install docker against a preconfigured local yum repository pulls Docker 18.09.0, a version the vendor’s own documentation flags as outdated and points users elsewhere for anything newer.
On CentOS 7, the equivalent path is longer: yum install docker-ce fails unless the official Docker CE repository has already been added with yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo.
Both commands read as “install docker with the package manager” in a runbook, but they resolve against different repository metadata, and that difference — not the package manager itself — decides whether the host gets a current release or a multi-year-old binary.
Why the Repository, Not the Command, Decides the Version
dnf and yum both resolve package names against whatever repositories are enabled on the host; a distribution’s own vendor repo can carry a package literally named docker that tracks upstream far more loosely than Docker’s own docker-ce channel.
The tempting fix — rerunning the install with different flags — does not change which repository dnf is querying, so it does not close the version gap. The operating condition that matters is which .repo file sits under /etc/yum.repos.d, not the flags passed to the installer.
A minimal discriminating check is to query which repo ID a package resolves against before installing, and compare that against the vendor’s official Docker CE mirror; if it resolves to a distro-maintained repo instead, expect an older build such as the 18.09.0 case on EulerOS.
Where dnf and Rootless Containers Actually Break
A second, unrelated failure mode appears once containers are involved: inside a rootless Podman container on Rocky Linux, dnf update can abort with cpio: chown failed errors on files such as /etc/tcsd.conf.
The root cause is not RPM corruption. A rootless container maps its internal UIDs to a subordinate range on the host defined in /etc/subuid and /etc/subgid, and when rpm tries to chown a file to an ID outside that range, the kernel rejects the operation, not dnf.
The standard allocation is 65536 IDs per user. The fix is to check the range with grep '^user:' /etc/subuid /etc/subgid, extend it with usermod --add-subuids 100000-165535 --add-subgids 100000-165535, then run podman system migrate to apply the new mapping.
A narrower fallback exists for hosts that can only map a single UID: setting ignore_chown_errors = "true" under [storage.options.overlay] squashes UID separation inside the image. The source frames this explicitly as a workaround, not a fix.
This distinction matters operationally because the error text mentions dnf and RPM unpacking, which sends people hunting through package-cache or mirror issues, when the actual failure boundary is the container runtime’s user-namespace configuration.
What to Verify Before You Trust systemctl start docker
A separate class of report on Stack Overflow’s docker-daemon tag describes sudo systemctl start docker failing outright, with only a manual daemon startup working, after a user purged a Docker cache directory that had grown to 3 TB along with the rest of the Docker and Containerd state.
The evidence does not establish one root cause for every systemctl-start failure in that tag; other open reports in the same feed cover daemon startup problems inside AKS clusters and Docker-in-Docker builds, which points to daemon-start failure as a symptom class with multiple distinct causes rather than a single bug.
Huawei’s own operational guidance for EulerOS adds a related but separate risk: an unexpected power loss can leave Docker’s state files unflushed, so containers created before the outage disappear from docker ps -a after reboot, and a damaged Docker DB file in the data-root directory is deleted automatically on restart unless DISABLE_CRASH_FILES_DELETE=true is set on the daemon.
| Symptom | Failure layer | Fix action |
|---|---|---|
dnf install docker installs an old build like 18.09.0 |
Repository metadata (vendor repo vs Docker CE repo) | Point dnf/yum at the official docker-ce repo before installing |
dnf update inside rootless Podman throws cpio: chown failed |
User-namespace UID mapping (/etc/subuid, /etc/subgid) | Extend the subuid/subgid range and run podman system migrate |
sudo systemctl start docker fails after a large cache purge |
Daemon state/cache directory corruption | Restart the daemon manually and inspect data-root state before reintroducing containers |
None of these three failure classes — old package versions, rootless chown errors, and daemon-start failures — share a fix. Conflating them wastes a debugging session, because the checks live in different layers: repo metadata, user-namespace mapping, and daemon state files.
A platform-specific wrinkle worth flagging before any RHEL-based rollout: Microsoft’s Defender for Cloud Apps documentation states that on RHEL version 7.1 or higher, the on-premises log collector must use Podman instead of Docker, so a Docker install runbook written for CentOS 7 cannot be reused unmodified for a RHEL 7.1+ host running that specific workload.
Docker Desktop on DNF-based distributions carries its own operational gap: there is no official DNF repository for it, so every update requires manually downloading a roughly 400MB RPM and running dnf install on it by hand — a gap significant enough that a third-party updater script exists specifically to automate that manual RPM cycle.
Before committing to a Docker-on-RPM rollout, verify three things independently: which repository dnf actually resolves the docker package against, whether the target host runs rootless containers that need a full subuid/subgid range, and whether the specific workload, as with Defender for Cloud Apps on RHEL 7.1+, is documented to require Podman instead of Docker outright.