If nmtui does not show an Ubuntu Server interface, identify the network manager first. A common Server setup passes Netplan configuration to systemd-networkd, while Desktop often uses NetworkManager. Check the active path before installing or enabling another manager.
The target is Ubuntu 24.04 LTS Server’s wired IPv4. The example assigns 192.168.50.24/24 to ens33. The address, DNS, and gateway are changed to the actual network allocation values, and the VM console is prepared for SSH change work. Ubuntu’s configuration flow was based on the official network document .
Linux operation articles seen together · Rocky 9 Fixed IP · Ubuntu 24.04 Netplan · Ubuntu 26.04·nmtui·systemd service·log·LVM root extension·general partition root Expand
On this page
1. Check the current device and configuration file
cat /etc/os-release
ip -br link
ip -4 -br address
ip -4 route
sudo netplan get
sudo netplan status -a
systemctl is-active systemd-networkd NetworkManager
sudo ls -la /etc/netplan
sudo ls -la /run/netplan /lib/netplan
The last command may print an error if the directory does not exist. This is the step to check whether the file exists. Whether a service is active and who manages a specific NIC are separate pieces of information. Also check the networkd·NetworkManager display for the device in netplan status -a.
Netplan reads multiple YAMLs combined. If you think that one file with the last name deletes the entire previous file, the existing address or path may remain. View the saved original and the merge results of netplan get together. Even if you directly modify the creation result, such as /run/systemd/network, it may be overwritten the next time it is created. Please refer to the file processing description of netplan generate.
2. Store existing files and organize them in one place
net_backup_dir="/root/netplan-before-$(date +%Y%m%d-%H%M%S)"
sudo install -d -m 0700 "$net_backup_dir"
sudo cp -a /etc/netplan/. "$net_backup_dir/"
Note the backup directory name. The example below assumes that the configuration of ens33 has been collected as /etc/netplan/60-static.yaml. If the same ens33 definition exists in the existing file, back it up and move or modify that part. Other NIC, bridge, VLAN, and IPv6 settings are not erased. It is important not to just add a new file name and leave the existing DHCP settings unattended.
If there are /run/netplan settings distributed by a management tool or a network policy from the cloud provider, check the management path first. We do not treat VMware VMs you operate and managed cloud instances on the same terms.
3. Write YAML for static IP
sudoedit /etc/netplan/60-static.yaml
network:
version: 2
renderer: networkd
ethernets:
ens33:
dhcp4: false
addresses:
- 192.168.50.24/24
routes:
- to: default
via: 192.168.50.1
metric: 100
nameservers:
addresses:
- 192.168.50.1
| field | What this example does |
|---|---|
| renderer: networkd | Actual application is handled by systemd-networkd |
| dhcp4: false | Disable IPv4 DHCP address assignment |
| addresses | Specify the address and prefix of the device |
| routes: to: default | Specify the default route to another network |
| nameservers | Specify the DNS server to use for name lookup |
The default path is expressed as routes. In this configuration, the gateway must be on the same subnet as ens33. Add on-link to prevent invalid gateways from being forced through. If 192.168.50.1 is a network that does not provide DNS service, replace the nameservers value with the actual DNS address. Field-specific behavior can be found in Netplan YAML specification.
In the file above, only IPv4 settings were added. If the existing IPv6 address, RA, and DHCPv6 policies were specified, the necessary fields are preserved. Indent YAML with spaces instead of tabs, and restrict file permissions because network settings may contain authentication information.
sudo chmod 600 /etc/netplan/60-static.yaml
sudo netplan get
sudo netplan generate
4. Apply netplan try and check at the new address
generate is the step to check the syntax and create backend settings. We have not yet confirmed actual communication success. Run the command below on the VM console and check SSH connection to the new address in a separate terminal.
sudo netplan try --timeout 120
If your connection is OK and you confirm the change in the original confirmation window, your settings will be retained. After confirming, there is no need to run netplan apply again for the same operation. If there is no confirmation within the timeout period, it will attempt to revert to its original running state.
However, in the official document netplan try, there is a caution to check whether it is actually restored after cancellation or timeout. Don’t assume that even the YAML on your edited disc has returned to its original content. After checking communication and file contents, decide whether to reboot.
ip -4 address show dev ens33
ip -4 route
resolvectl status ens33
resolvectl query example.com
getent ahostsv4 example.com
curl --connect-timeout 5 --max-time 10 -I https://example.com
127.0.0.53 seen in /etc/resolv.conf may be a local DNS stub. The actual upstream DNS resolves to resolvectl status. It is better for maintenance to modify the nameservers in the original configuration rather than adding the nameserver directly to the file.
If cloud-init recreates the file
If the file header says cloud-init generated it, check the regeneration policy. When you intentionally take over network configuration on a VM you manage, the following file can disable cloud-init’s network configuration generation. It does not disable all other cloud-init functions.
sudoedit /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
network:
config: disabled
Creating this file will not delete the existing 50-cloud-init.yaml. You’ll need to move the current settings to a file you can manage yourself and clean up duplicate definitions. In the cloud, where the provider injects the address and route, the decision is made after checking the corresponding policy. Disabling network settings in cloud-init The scope of the settings is described in the document .
5. Recovery and DHCP switchover
If it fails, restore the backup file from the VM console. Below is a case where the file created in this work is 60-static.yaml. If you only copy the backup, leaving the newly created file behind, it may be merged again, so remove that file first. The backup path variable uses the actual path recorded in the previous section.
sudo rm -f /etc/netplan/60-static.yaml
sudo cp -a "$net_backup_dir/." /etc/netplan/
sudo netplan generate
sudo netplan apply
If you have created new cloud-init settings, whether to restore or maintain the file is also determined based on the original management policy. To switch to the DHCP configuration independently of restoring the original profile, remove the manual addresses·routes·nameservers for that NIC and clean them up as follows: There should be no manual addresses left over in other YAML.
network:
version: 2
renderer: networkd
ethernets:
ens33:
dhcp4: true
After saving this file, check permissions in the following order: generate·try. If you have multiple networks, you must also decide which NIC to place the default route on. Ubuntu 26.04·nmtui continues the configuration of Ubuntu 26.04 and a two NIC example.
Verification Scope · 2026-10-18: Verified networkd static address enforcement and destination-specific route selection on the isolated secondary NIC of Ubuntu 24.04.5 VM. The generation of the example YAML was also verified with Netplan 1.2 on Ubuntu 26.04.1. No work was done to change the address of the VM’s default SSH NIC or the actual VMware NAT network.
Download the network·systemd example file·Netplan YAML, bundled scripts that read service·environment files and storage structures. Change the address and device name to match the actual environment. It does not include scripts to auto-expand disks.



