Resolvconf Command Not Found | Fast Restore Steps

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 resolvconf and confirm it prints nothing.
  • Check The Resolver File Type — Run ls -l /etc/resolv.conf to see whether it’s a file or a symlink.
  • See Who Owns DNS — Run systemctl is-active systemd-resolved and note whether it says active.
  • Verify Current Nameservers — Read /etc/resolv.conf and confirm it lists usable nameserver lines.
  • Check For A Tight PATH — If the error came from cron or a systemd unit, print $PATH in 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 update so you install from current indexes.
  • Install resolvconf — Run sudo apt install resolvconf when your release offers it.
  • Install openresolv — Run sudo apt install openresolv when you want a drop-in provider that’s widely used.
  • Confirm It Runs — Run resolvconf -h and 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 install and let it finish.
  • Finish Pending Config — Run sudo dpkg --configure -a to complete any half-done installs.
  • Reinstall The Provider — Run sudo apt install --reinstall resolvconf or sudo 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.conf and 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 status and 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 show and 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 modify ipv4.ignore-auto-dns yes when DHCP keeps overwriting you.
  • Reconnect Cleanly — Run nmcli connection down , then nmcli 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.conf and set DNS= and FallbackDNS=.
  • Restart resolved — Run sudo systemctl restart systemd-resolved after changes.
  • Confirm The Link — Recheck that /etc/resolv.conf still 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 apply and confirm you keep network access.
  • Recheck Resolver Output — Inspect resolvectl status or /etc/resolv.conf after 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.1 to confirm you can reach a public IP.
  • Test Name Resolution — Run getent hosts example.com to see if the resolver can map a name to an IP.
  • See The Active DNS Server — Run resolvectl dns or read /etc/resolv.conf for the active nameserver lines.

Common Failure Patterns

  • Stub Resolver Without resolved — If /etc/resolv.conf lists 127.0.0.53 but systemd-resolved is 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.conf is 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.