Set and Verify a Hostname with nmtui-hostname

nmtui-hostname changes the system hostname through NetworkManager's text interface, and this guide shows you how to confirm it actually stuck. Renaming a machine sounds trivial until monitoring, certificates and SSH known-hosts quietly disagree with each other. On this machine, the installed command comes from NetworkManager 1.46.0.

• Time: about ten minutes.
• You need: a local or remote terminal, NetworkManager running, and permission to change the system hostname.
• Note: the interface is interactive, so use a real terminal rather than a pipeline. Saving may trigger a PolicyKit prompt or require an administrator account.

1. Record the current hostname

Save the current value in your notes before changing anything. This is a read-only check that needs no elevated privileges:

$ nmcli general hostname
old-name.example

You can also check it through systemd's hostname tool:

$ hostnamectl status
   Static hostname: old-name.example

Keep the old value visible while you work. A hostname change can ripple into shell prompts, monitoring, remote access records, certificates, inventory systems and scripts that reference the machine by name. This guide only changes the hostname: it does not rename network connections, update DNS, touch /etc/hosts, or issue new certificates.

2. Check the installed activity

The manpage describes nmtui-hostname as the standalone form of the nmtui hostname activity. It takes no hostname argument, so run it bare:

$ command -v nmtui-hostname
/usr/bin/nmtui-hostname
$ nmtui-hostname

Do not add a value after the command: it is a curses screen, not a command-line setter. The installed 1.46.0 binary also rejects options such as --version, so use the package query when you need a version number:

$ dpkg-query -W -f='${Package} ${Version}\n' network-manager
network-manager 1.46.0-1ubuntu2.8

Your distribution's package revision may differ even when the upstream NetworkManager version matches.

3. Enter the new hostname

When the screen opens, use the hostname field nmtui shows you. Replace the example below with the name assigned to this machine:

edge-01.example

• Follow your naming rules. A fully qualified name such as edge-01.example is often less ambiguous than a short one, but the right choice depends on your DNS and operating policies.
• Never paste untrusted text into the field: no whitespace, no shell punctuation, nothing you have not checked. If in doubt, stop and ask whoever owns DNS and host inventory.
• Confirm through the screen's control, using arrow or Tab keys and the key hints nmtui shows at the bottom. If authentication is requested, review the action before entering credentials: a password prompt is a permission boundary, not proof the hostname itself has been validated.

Changing a hostname is a system-wide state change. It usually will not drop active network connections, but programs can notice the new name immediately, so avoid doing this mid-incident or during a maintenance window that needs a stable host identity.

4. Exit and verify the saved value

Once nmtui reports the change accepted, exit the interface and ask NetworkManager for the hostname from the shell:

$ nmcli general hostname
edge-01.example

Check the system view too:

$ hostnamectl status
   Static hostname: edge-01.example

Depending on the init system and NetworkManager configuration, the status output can show other hostname fields; the useful check is that the static or system hostname now matches what you entered. hostname gives you the kernel's current name too:

$ hostname
edge-01.example

If the shell prompt still shows the old name, start a new shell or log in again: a prompt is presentation, not authoritative verification, and existing SSH sessions can keep their old prompt until refreshed.

5. Recover if the name is wrong

Do not hand-edit /etc/hostname while diagnosing a failed nmtui change; that can leave the service view and the file out of step. Reopen the same activity and enter the recorded old value:

$ nmtui-hostname

Confirm, exit, and verify again:

$ nmcli general hostname
old-name.example

If nmtui cannot save the value, check that NetworkManager is running and your account is allowed to perform the operation:

$ nmcli general status
$ nmcli general permissions

Both commands are read-only. A denied permission needs an administrator or the right PolicyKit rule; retyping credentials will not fix a policy denial. If NetworkManager itself is unavailable, do not restart it blindly on a remote machine: investigate the service state through your normal change-control process, since a restart can affect managed interfaces.

6. Check the surrounding systems

Setting the system hostname does not guarantee every name service knows about it. From a host where the name should resolve, test the DNS record separately. Review /etc/hosts, SSH known-host records, monitoring labels, configuration-management inventory and TLS names too if they reference the old value, updating each through its own normal process rather than assuming the hostname change cascades automatically.

NetworkManager can also learn a hostname from DHCP or reverse DNS depending on configuration. If the name reverts after a reconnect or reboot, investigate hostname management settings and the network's DHCP or DNS behaviour before repeating the nmtui change: that is a configuration-ownership problem, not a faulty text interface.