Fix "sudo: unable to resolve host ...: Name or service not known"

hostname
# add a line with exactly that name (Debian/Ubuntu convention)
echo "127.0.1.1 $(hostname)" | sudo tee -a /etc/hosts
sudo true    # should now run without the warning

The message comes in a few variants depending on how the lookup failed:

sudo: unable to resolve host myhost: Name or service not known
sudo: unable to resolve host myhost: Temporary failure in name resolution
sudo: unable to resolve host myhost: No address associated with hostname

What the error means

sudo looks up the machine's own hostname, because rules in /etc/sudoers can be limited to specific hosts. It reads the name from the kernel (the value hostname prints) and resolves it through the normal resolver, which checks /etc/hosts first and then DNS. When neither knows the name, sudo prints this warning and carries on. Your command still runs; it is not a permissions problem like user is not in the sudoers file.

The side effect people notice is a delay: if the lookup goes out to DNS and waits for a timeout, every sudo call hangs for several seconds before running. Check how your name resolves:

hostname
cat /etc/hostname
getent hosts "$(hostname)"

If getent prints nothing, the name is unresolvable and you will see the warning. Note this is about your own name only; if other names do not resolve either, you have a general DNS problem, covered in Temporary failure in name resolution.

Cause 1: the hostname was changed but /etc/hosts was not

This is by far the most common reason. hostnamectl set-hostname (or the settings app, or editing /etc/hostname) changes the system name, but on Debian-family systems nothing updates the 127.0.1.1 line in /etc/hosts, which still holds the old name:

127.0.0.1   localhost
127.0.1.1   oldname

# IPv6 lines
::1         localhost ip6-localhost ip6-loopback

Edit the file and replace the old name with the new one:

sudo nano /etc/hosts
# change:  127.0.1.1   oldname
# to:      127.0.1.1   newname

If the machine has a fully qualified name, list it first, then the short name: 127.0.1.1 newname.example.com newname. Do not change or remove the localhost lines, since many programs depend on them. Our guide to changing the hostname covers the whole procedure so this does not happen again.

Cause 2: a typo or invisible character

The name must match exactly. Check for a mismatch between /etc/hostname and /etc/hosts, including stray spaces, Windows line endings or a name that was pasted with a non-ASCII character:

cat -A /etc/hostname
grep -n "$(hostname)" /etc/hosts

cat -A shows a line ending as $; a ^M$ means a carriage return got into the file. Hostnames may only contain letters, digits and hyphens (plus dots between labels). A name with an underscore or space can be set but often fails to resolve.

Cause 3: cloud-init, Raspberry Pi or WSL rewrites the files

If the fix disappears after reboot, a boot-time tool owns the files:

• cloud-init (cloud servers, Ubuntu Server images, Raspberry Pi images configured with the imager): it may set the hostname from the provider's metadata and regenerate /etc/hosts from a template. Set preserve_hostname: true in /etc/cloud/cloud.cfg (or a file in /etc/cloud/cloud.cfg.d/) to keep your own name, and if manage_etc_hosts: true is set, edit the template under /etc/cloud/templates/ instead of the file itself.
• WSL: Windows generates /etc/hosts and the hostname at each start. Set the hostname in /etc/wsl.conf under [network] with hostname = myhost, or set generateHosts = false there and maintain /etc/hosts yourself. Then run wsl --shutdown from Windows.
• Docker containers: /etc/hosts is created by Docker with the container ID as hostname. Use --hostname or --add-host on docker run rather than editing it inside the container.

Cause 4: /etc/hosts is missing, unreadable or skipped

An accidentally deleted or overwritten /etc/hosts, or one with wrong permissions, breaks local lookups. It should be readable by everyone:

ls -l /etc/hosts       # expect: -rw-r--r-- 1 root root
sudo chmod 644 /etc/hosts

The resolver only reads it if files appears on the hosts: line of /etc/nsswitch.conf:

grep ^hosts /etc/nsswitch.conf

Example output (Fedora):

hosts:      files myhostname resolve [!UNAVAIL=return] dns

myhostname (an NSS module from systemd) resolves the local hostname even without a hosts entry, which is why some systems never show the warning. Debian and Ubuntu lines often do not include it, so they depend on /etc/hosts. Restore files at the start of the line if it is missing.

Distro notes

• Ubuntu, Debian, Mint, Raspberry Pi OS: the installer writes the 127.0.1.1 hostname line, and renaming later needs a manual edit. These are the systems where the warning shows up most.
• Ubuntu 26.04: the default sudo is sudo-rs. Its messages can be worded differently from classic sudo, but the underlying cause and fix are the same: make your hostname resolvable. Other tools (Postfix, Java apps, hostname -f) also misbehave when it is not.
• Fedora, openSUSE, Arch: they normally rely on myhostname in nsswitch.conf, so the warning is rare. Adding a hosts line is still the simplest fix if you see it.

How to prevent it

• Whenever you rename a machine, update /etc/hostname (via hostnamectl) and /etc/hosts together.
• On cloud and Pi images, decide whether cloud-init manages the hostname and configure it once in cloud.cfg.
• Keep hostnames to lowercase letters, digits and hyphens.

For managing accounts and sudo access more generally, see Linux user management.

Frequently asked questions