Resolvconf command not found means a resolvconf provider isn’t installed or your system uses systemd-resolved; fix it by matching the DNS tool to your distro.
You’ll see this message when a script calls resolvconf and your system can’t find the command. Sometimes DNS still works and only that script fails. Other times name lookups fail too because /etc/resolv.conf is missing, stale, or managed by the wrong service.
This article gets you to a stable fix that survives reboots and network changes. You’ll start with quick checks, then pick one of two paths. Install a resolvconf provider when you truly need the resolvconf command. Or lean into systemd-resolved when that’s what your distro already runs.
Why This Error Shows Up
resolvconf is a helper that gathers DNS settings from places like DHCP clients, VPN tools, and interface scripts, then writes a merged resolver file. On older Debian and Ubuntu setups it often sat between networking tools and /etc/resolv.conf. On many current installs, DNS is handled by NetworkManager, systemd-resolved, or a distro-specific resolver stack, so the resolvconf binary may be absent.
The same error can appear in a few common situations. A VPN helper might be coded to call resolvconf -a on connect and resolvconf -d on disconnect. A minimal cloud image might skip it to keep the base small. A container image might not ship any DNS helper at all and relies on the resolver file injected by the runtime.
Don’t treat this as a “just install stuff” moment. The best fix is the one that matches who owns DNS on your box today. When you match the owner, you reduce surprises like DNS breaking after suspend, after a VPN disconnect, or after the next package upgrade.
Resolvconf Command Not Found
Run these checks before you change anything. They tell you whether you’re missing a package, dealing with a PATH issue, or fighting a broken resolver file.
- Confirm The Command Is Missing — Run
command -v resolvconfand confirm it prints nothing. - Check The Resolver File Type — Run
ls -l /etc/resolv.confto see whether it’s a file or a symlink. - See Who Owns DNS — Run
systemctl is-active systemd-resolvedand note whether it saysactive. - Verify Current Nameservers — Read
/etc/resolv.confand confirm it lists usablenameserverlines. - Check For A Tight PATH — If the error came from cron or a systemd unit, print
$PATHin that context and confirm it includes/usr/sbin.
If /etc/resolv.conf points into /run/systemd/resolve/, you’re on the systemd-resolved route. If it’s a plain file that changes on every connect, NetworkManager or a DHCP client is writing it. If it’s empty or points at a dead server, you’ll want to fix DNS ownership first, then worry about the missing command.
If you arrived here because a tool printed resolvconf command not found, keep that tool in mind as your final test. Your goal isn’t just to make one site load. Your goal is to make the original command run clean, then confirm DNS still works after a reboot.
Fixing Resolvconf Command Not Found On Ubuntu And Debian
On Debian-family systems, the cleanest fix is often to install a package that provides the resolvconf command. Some releases ship a package named resolvconf. Others steer you toward alternatives that provide the same interface, such as openresolv. Either way, the aim is simple. Put a compatible binary on the system so scripts that expect resolvconf can run.
Before you install anything, confirm whether the failing tool actually needs resolvconf. If the tool calls resolvconf -a and resolvconf -d, a provider install is usually enough. If the tool never calls resolvconf and writes /etc/resolv.conf directly, installing a provider won’t change its behavior, so your fix belongs in that tool’s config.
Install A Provider Package
- Refresh Package Metadata — Run
sudo apt updateso you install from current indexes. - Install resolvconf — Run
sudo apt install resolvconfwhen your release offers it. - Install openresolv — Run
sudo apt install openresolvwhen you want a drop-in provider that’s widely used. - Confirm It Runs — Run
resolvconf -hand verify you get help text instead of an error.
Fix A Half-Installed Package State
If your system says the package is broken, fix the package manager state first, then install again. This is common after an interrupted upgrade or a forced reboot.
- Repair Broken Dependencies — Run
sudo apt --fix-broken installand let it finish. - Finish Pending Config — Run
sudo dpkg --configure -ato complete any half-done installs. - Reinstall The Provider — Run
sudo apt install --reinstall resolvconforsudo apt install --reinstall openresolv.
Pick The Least Surprising Option
This table helps you choose a path that fits your current DNS owner without piling on extra moving parts.
| What You See | Best Fix | Why It Works |
|---|---|---|
| WireGuard tool fails with resolvconf missing | Install openresolv | Provides the expected command while keeping the rest of DNS the same. |
| /etc/resolv.conf links into /run/systemd/resolve/ | Use systemd-resolved | Keeps the resolver flow your distro already set up. |
| /etc/resolv.conf is a plain file that keeps changing | Stay with NetworkManager | NetworkManager already writes DNS for active connections. |
| DNS breaks after VPN disconnect | Use a provider | Lets VPN hooks add and remove DNS without clobbering the file. |
When systemd-resolved Is The Real Fix
On many systems, systemd-resolved is already the DNS owner. In that case, installing resolvconf can be unnecessary. The cleaner move is to restore the expected /etc/resolv.conf link and tell your networking tool to speak to resolved.
A quick clue is the content of /etc/resolv.conf. If you see nameserver 127.0.0.53, your machine is using the local stub resolver. That’s normal for resolved. If the file is missing or points somewhere else, DNS can behave oddly even as resolved is running.
Restore The Standard resolv.conf Link
- Check The Current Link — Run
ls -l /etc/resolv.confand note its target. - Link To The Stub File — Run
sudo ln -rsf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf. - Restart The Resolver — Run
sudo systemctl restart systemd-resolved. - Verify Resolver State — Run
resolvectl statusand confirm DNS servers are listed.
Some posts suggest copying files around. Avoid that. A symlink stays current when DNS servers change. A copied file goes stale the moment your network changes.
Point Network Tools At resolved
If a tool insists on setting DNS, try to switch it to the resolved method it already knows. WireGuard’s wg-quick can use resolvectl on systems where it’s available. Many VPN clients also have a “use systemd-resolved” toggle or a plugin.
- Check The Tool’s DNS Mode — Look for options like
systemd-resolved,resolvectl, or “set DNS via resolved”. - Disable Old Hooks — If your VPN scripts call resolvconf directly, remove that hook when resolved is your DNS owner.
- Test A Connect And Disconnect — Bring the link up, then down, and confirm DNS returns to the pre-VPN state.
Make The Fix Stick After Reboots
A fix that works once but breaks on reboot is almost always a DNS ownership problem. Something recreates /etc/resolv.conf or changes DNS servers at boot, and your one-off edit gets overwritten. Your goal here is to set DNS where your system expects it, not in a file that gets replaced.
For NetworkManager Systems
NetworkManager can manage DNS directly or hand it off to resolved. Which one is active depends on your distro defaults and your config. If NetworkManager owns your connections, set DNS in the connection profile, not by editing /etc/resolv.conf.
- List Connection Profiles — Run
nmcli connection showand pick the active profile. - Set DNS Servers — Run
nmcli connection modify.ipv4.dns "1.1.1.1 8.8.8.8" - Disable Auto DNS If Needed — Run
nmcli connection modifywhen DHCP keeps overwriting you.ipv4.ignore-auto-dns yes - Reconnect Cleanly — Run
nmcli connection down, thennmcli connection up.
For systemd-resolved Systems
If resolved is active, it can take DNS from DHCP, from NetworkManager, or from its own config file. Keep your changes in one place. Mixing static DNS in multiple tools is how you end up with a stub file that looks right while real queries still fail.
- Set Global DNS — Edit
/etc/systemd/resolved.confand setDNS=andFallbackDNS=. - Restart resolved — Run
sudo systemctl restart systemd-resolvedafter changes. - Confirm The Link — Recheck that
/etc/resolv.confstill points at the stub file.
For Servers With Netplan
On Ubuntu server images, netplan often defines interfaces and feeds settings to systemd-networkd or NetworkManager. If you change DNS in netplan, regenerate the config so it applies on boot.
- Edit Netplan YAML — Update DNS servers under the correct interface stanza.
- Apply The Change — Run
sudo netplan applyand confirm you keep network access. - Recheck Resolver Output — Inspect
resolvectl statusor/etc/resolv.confafter the apply.
Troubleshooting When DNS Still Fails
If the command exists and DNS still fails, treat it as a resolver problem, not a missing-binary problem. Work from the bottom up. Can you reach the gateway. Can you resolve a name. Can you reach a site over HTTPS.
- Test Raw Connectivity — Run
ping -c 2 1.1.1.1to confirm you can reach a public IP. - Test Name Resolution — Run
getent hosts example.comto see if the resolver can map a name to an IP. - See The Active DNS Server — Run
resolvectl dnsor read/etc/resolv.conffor the active nameserver lines.
Common Failure Patterns
- Stub Resolver Without resolved — If
/etc/resolv.conflists127.0.0.53butsystemd-resolvedis inactive, restore the link and start the service. - Stale File After VPN — If DNS breaks only after disconnect, switch the VPN client to resolved mode or use a resolvconf provider so DNS entries roll back cleanly.
- Wrong File Permissions — If
/etc/resolv.confis read-only due to flags or immutable bits, remove that lock so the owning service can update it. - Multiple Owners Fighting — If NetworkManager and another service both write DNS, pick one owner and disable the other’s DNS writing.
Once you’ve fixed the underlying DNS path, rerun the command that started the issue. If you hit this because a tool printed resolvconf command not found, the final proof is that the tool can connect, disconnect, and reconnect without leaving DNS in a broken state.
If you manage VPN tools, keep a note of which one edits DNS. Two tools fighting over resolv.conf can look like outages even when the link stays up.
