🚨 Linux Error Guide: 'modprobe: FATAL: Module not found' — Fix Missing Kernel Modules

Overview

modprobe cannot locate a kernel module and refuses to load it, printing the module name and the directory it searched:

modprobe: FATAL: Module nf_conntrack not found in directory /lib/modules/5.15.0-113-generic

A common cause-specific variant appears right after a kernel upgrade when the running kernel and the installed modules no longer match:

modprobe: FATAL: Module dm_crypt not found in directory /lib/modules/6.5.0-41-generic
insmod: ERROR: could not insert module ...: Unknown symbol in module

The number in the path is the key clue: modprobe only searches /lib/modules/$(uname -r), so the error usually means either the module was never installed for this kernel, or you are running a kernel whose module tree is missing.

Symptoms

• A service fails to start because a required module (networking, storage, crypto) won’t load.
• modprobe <mod> fails with “not found in directory /lib/modules/”.
• The failure began immediately after a kernel upgrade, before a reboot, or in a custom/cloud kernel.
• ls /lib/modules/$(uname -r) is missing or nearly empty.
• Third-party/DKMS drivers (NVIDIA, ZFS, VirtualBox) vanish after a new kernel.

Common Root Causes

• Running kernel doesn’t match installed modules. A kernel upgrade replaced modules for the new version, but the machine still runs the old one (or vice versa) and its module tree was removed.
• modules.dep is stale. depmod was never run after modules were added, so modprobe can’t resolve the name.
• The module lives in an extras package. On RHEL/Ubuntu, less-common modules ship in kernel-modules-extra / linux-modules-extra-<ver> which isn’t installed.
• DKMS module not rebuilt. Out-of-tree drivers weren’t recompiled for the new kernel.
• Custom/minimal or cloud kernel. The module was simply not built (or was built into the kernel and doesn’t exist as a loadable .ko).
• Secure Boot rejects an unsigned module. The module exists but can’t load; combined with a name typo this surfaces as “not found.”

Diagnostic Workflow

First, confirm which kernel is running and whether its module tree exists at all:

uname -r
ls -d /lib/modules/$(uname -r) && ls /lib/modules/$(uname -r)/kernel | head

Search for the module across every installed kernel — this reveals a version mismatch instantly:

find /lib/modules -name 'nf_conntrack*.ko*' 2>/dev/null
modinfo nf_conntrack 2>&1 | head       # errors if not found for running kernel

Rebuild the dependency map and retry; a stale modules.dep is a frequent, cheap fix:

sudo depmod -a
sudo modprobe -v nf_conntrack

Check whether the module is built into the kernel rather than loadable, and whether Secure Boot is enforcing:

grep -i nf_conntrack /boot/config-$(uname -r)   # 'y' = built-in, 'm' = module
mokutil --sb-state 2>/dev/null

Example Root Cause Analysis

After a routine apt upgrade, a firewall host lost NAT and systemd logged modprobe: FATAL: Module nf_nat not found in directory /lib/modules/5.15.0-113-generic.

uname -r reported 5.15.0-113-generic, but ls /lib/modules/ showed only 5.15.0-119-generic — the upgrade had installed a newer kernel and its linux-modules package, and autoremove had purged the modules for -113, yet the box had not rebooted, so it was still running -113 with no module tree.

Two paths were valid: reboot into -119 (whose modules were present), or reinstall linux-modules-5.15.0-113-generic to keep running the current kernel until a scheduled window. The team reinstalled the matching modules package, ran depmod -a, and modprobe nf_nat succeeded immediately. They also found nf_conntrack and friends lived in linux-modules-extra, which they added to the base image to prevent a repeat.

Prevention Best Practices

• Reboot promptly after kernel upgrades so the running kernel always matches its installed modules; don’t let uname -r drift from /lib/modules.
• Pin or preserve the modules package for the running kernel and be careful with autoremove, which can purge in-use kernel modules.
• Install kernel-modules-extra (RHEL) / linux-modules-extra-$(uname -r) (Ubuntu) up front if you rely on less-common modules.
• Run depmod -a after manually adding any .ko file, and let DKMS manage out-of-tree drivers so they rebuild automatically per kernel.
• Under Secure Boot, sign custom modules and enroll the key (MOK) so they aren’t rejected at load time.

Quick Command Reference

# What kernel am I on, and does its module tree exist?
uname -r
ls /lib/modules/$(uname -r)

# Rebuild dependency map and retry
sudo depmod -a
sudo modprobe -v <module>

# Find the module across kernels / get its details
find /lib/modules -name '<module>*.ko*'
modinfo <module>

# Install the extras package (pick your distro)
sudo dnf install kernel-modules-extra-$(uname -r)
sudo apt-get install linux-modules-extra-$(uname -r)

# DKMS status and rebuild for the current kernel
dkms status
sudo dkms autoinstall -k $(uname -r)

Conclusion

modprobe: FATAL: Module not found is almost always a kernel/module version mismatch: the module simply doesn’t exist under /lib/modules/$(uname -r). Check the running kernel against its module tree, run depmod -a, and install the matching or -extra modules package — or just reboot into the kernel whose modules are present. For third-party drivers, let DKMS rebuild them per kernel and sign them under Secure Boot, and the module will be there when the service needs it.