AlmaLinux dnf Error: Failed to Download Metadata for Repo (Causes and Fixes)

The message looks alarming because it stops every update on the box: Error: Failed to download metadata for repo 'something': Cannot download repomd.xml. In practice it rarely means AlmaLinux is broken. dnf reads the metadata of every enabled repository before it does anything, so a single dead repository anywhere in /etc/yum.repos.d/ is enough to block an unrelated security update. The skill is finding which repository is the problem and deciding whether to repair it or remove it.

Read the repo name in the error first

The error always names the repository that failed, and that name decides everything that follows. A failure on baseos, appstream or extras points at AlmaLinux's own mirrors or at your network. A failure on anything else, a database vendor, a monitoring agent, a panel, a PHP repository, points at a third party that has probably moved or retired the URL.

dnf repolist -v 2>&1 | head -40
grep -R "baseurl\|mirrorlist\|metalink" /etc/yum.repos.d/ | head -30

In our experience the third-party case is by far the most common. A repository pinned to an old product version, such as an end-of-life database release, simply stops existing upstream, and every dnf command on the server starts failing the day that URL returns a 404.

Test the URL by hand

Before changing any configuration, ask the repository directly. This separates a dead URL from a network or TLS problem on your side:

curl -I https://repo.almalinux.org/almalinux/9/BaseOS/x86_64/os/repodata/repomd.xml

A 200 means the mirror is fine and the fault is local. A 404 means the path is gone. A timeout or certificate error means the problem sits between your server and the internet. Use the exact baseurl from the failing repo's file in place of the example, and add the architecture and release your server actually runs.

When a third-party repo is dead

If the repository is gone for good, you have two honest choices: point it at a supported replacement, or disable it. Check what the repo was providing first, so you do not silently lose updates for software you depend on.

dnf list installed | grep -i repo-name
dnf config-manager --set-disabled repo-id

For something you still need, find the vendor's current repository instructions and replace the old file rather than editing it in place, so you are not left with half of each configuration. AlmaLinux's own AppStream also carries several database and runtime streams, which can make an extra repository unnecessary altogether.

Clear the cache properly

A stale or half-written metadata cache produces the same error and survives simple retries. The quick fix is more thorough than deleting /var/cache/dnf by hand:

dnf clean all
dnf makecache

If that still fails on a specific repo, run dnf --enablerepo=* clean all once so disabled-but-cached repositories are cleared as well, then retry.

Rule out clock skew, certificates and proxies

These three cause failures that look like repository problems but are not. A server whose clock has drifted rejects valid TLS certificates, so check timedatectl and make sure time synchronisation is running. An outdated CA bundle can break HTTPS to the mirrors, which update-ca-trust refreshes. And a server behind a proxy needs it configured for dnf specifically:

timedatectl
update-ca-trust
grep -i proxy /etc/dnf/dnf.conf

On hosting servers we also check for a recent firewall or security-tool change, since a rule that blocks outbound HTTPS to unfamiliar hosts will cut off the mirrors without any other symptom.

GPG key and release package problems

If the failure mentions a signature or key rather than a download, the repository metadata arrived but could not be verified. After a release or a key rotation, the fix is to make sure the release package is current and the key is imported from AlmaLinux's own site rather than a third party:

dnf upgrade almalinux-release
rpm --import https://repo.almalinux.org/almalinux/RPM-GPG-KEY-AlmaLinux-9

Match the key file to your major version. Never disable gpgcheck to push past the error. That removes the one protection that stops a tampered package from installing as root.

A short-lived 404 right after a point release

Occasionally a mirror lags behind a new minor release, and you get a 404 on a path that will exist within hours. If the URL looks correct and the same request works from another network, wait and try again after dnf clean expire-cache before changing anything. Edits made in a panic during a mirror lag are the ones we most often have to undo later.

If the server came over from CentOS

Servers migrated from CentOS 7 or 8 often still carry repository files from the old distribution, pointing at addresses that were retired when those releases ended. If dnf errors name centos repositories on an AlmaLinux machine, the migration left debris behind. Listing everything in /etc/yum.repos.d/ and removing files that belong to a distribution you no longer run is the cleanup. On cPanel machines, our guide to installing and optimising cPanel with CloudLinux and LiteSpeed covers the surrounding stack, and when a WHM package update fails the repository layer is the first place to look. For a regular rhythm that catches this before it blocks a security patch, see our Linux server maintenance checklist.

AlmaLinux repository errors are easy to fix and easy to make worse. If you would prefer an engineer to untangle the repository files on a production server and keep patching on schedule afterwards, that is what our AlmaLinux server management service covers.