Short answer: On AlmaLinux 10, dnf and yum are Python scripts that start with #! /usr/bin/python3, so a broken /usr/bin/python3 link stops both with “cannot execute: required file not found”. Run rpm -V python3: if it reports the link changed, point it back with ln -sf python3.12 /usr/bin/python3; if the interpreter itself is missing, reinstall the python3 package with rpm. Do not install a source-built Python over the system one.
This came up on the AlmaLinux forum in October 2026: dnf and yum stopped with a confusing message, and the cause turned out to be /usr/bin/python3 pointing at /usr/local/bin/python3.12, which did not exist. We reproduced it on AlmaLinux 10.2 and tested both fixes.
Table of Contents
The error: required file not found
# dnf --version
bash: /usr/bin/dnf: cannot execute: required file not found
# yum check-update
bash: /usr/bin/yum: cannot execute: required file not found
# python3 -V
bash: python3: command not found
$ sudo dnf update
sudo: unable to execute /bin/dnf: No such file or directory“Required file not found” is about the interpreter, not the dnf file: /usr/bin/dnf exists, but the program named on its first line cannot be started. Both dnf and yum are links to dnf-3, a Python script.
Find the cause
# head -1 /usr/bin/dnf-3
#! /usr/bin/python3 -s
# ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 25 Oct 18 15:43 /usr/bin/python3 -> /usr/local/bin/python3.12
# rpm -qf /usr/bin/python3
python3-3.12.14-1.el10_2.x86_64
# rpm -V python3
....L.... /usr/bin/python3rpm -V compares the files with what the package installed. An L means the link points somewhere else than it should; missing means a file is gone. On AlmaLinux 10 the link should point to python3.12 in the same folder.
Fix 1: the link was changed
ln -sf python3.12 /usr/bin/python3
rpm -V python3 # prints nothing, exit code 0
dnf --version # 4.20.0That is all that was wrong on the forum system. If you installed your own Python under /usr/local, keep using it by its full path or a virtual environment, and leave /usr/bin/python3 to the system: many system tools besides dnf depend on it.
Fix 2: the interpreter itself is missing
If rpm -V python3 reports missing /usr/bin/python3.12, dnf cannot repair it, because dnf needs it to run. Download the same python3 package with curl, check its signature and reinstall it with rpm:
V=$(rpm -q --qf "%{VERSION}-%{RELEASE}.%{ARCH}" python3)
curl -fsSLO "https://repo.almalinux.org/almalinux/10/BaseOS/x86_64/os/Packages/python3-$V.rpm"
rpm -K "python3-$V.rpm" # digests signatures OK
rpm -Uvh --replacepkgs "python3-$V.rpm"
rpm -V python3 && dnf --versionOn our test system this restored /usr/bin/python3.12 and dnf worked again. If the exact version is no longer in the repository, take it from vault.almalinux.org. If python3-libs is damaged too, rpm -V python3-libs shows it; reinstall that package the same way.
AlmaLinux 9 behaves differently
On AlmaLinux 9.8, dnf starts with #!/usr/bin/python3.9, the versioned name, so a broken /usr/bin/python3 link did not stop dnf in our test (dnf --version still worked; only rpm -V flagged the link). Removing /usr/bin/python3.9 did stop it, with a different message: bad interpreter: No such file or directory. The fixes are the same, with the 9 repository path. We did not test AlmaLinux 8.
How we tested
On 18 October 2026 we unpacked the official AlmaLinux 10.2 and 9.8 container images and ran every command inside them with chroot as root: first the normal state, then the broken link, then the missing interpreter, each followed by the fix. The python3 package (3.12.14-1.el10_2) came from the AlmaLinux 10 BaseOS repository and its signature checked out. This is the package layer of a real AlmaLinux system, without its kernel or services.
Related: restart after updates and automatic security updates, server inventory report script.
At a glance
Frequently asked questions
Can I use alternatives to switch python3 to another version?
Not for the system Python on AlmaLinux 10: dnf and other system tools expect the version the distribution ships. Install other versions side by side, from a package or your own build in /usr/local, and call them by their full name or from a virtual environment.
What made the link change?
Usually a manual ln -sf after building Python from source, or a script that “sets the default python”. Building from source with make install instead of make altinstall writes into /usr/local, not /usr/bin, so it does not break dnf on its own.
Reading a lot of our guides? Go ad-free with srvScripts Pro for $6 a month. It also pays for new guides. Cancel any time.