Linux machine-id: How to Check and Reset It for Cloned Systems

The machine-id is a persistent identifier for a systemd-based Linux installation. It is normally stored in /etc/machine-id and does not change when you reboot or rename the host. If you clone a server or virtual machine without preparing this file, separate systems can end up with the same ID.

What is the machine-id?

The machine-id identifies a local system with a 128-bit value. In /etc/machine-id, it is normally represented as 32 lowercase hexadecimal characters followed by a newline. Systemd establishes the value during installation or boot and ordinarily keeps it across later boots.

It is not a human-readable server name. A hostname is a name an administrator can choose and change; the machine-id identifies the operating system installation. If you need to rename a host, see How to Change the Hostname on Rocky Linux.

The machine-id is also different from a hardware serial number or network interface MAC address. Replacing hardware or changing network settings does not, by itself, change it. The systemd machine-id(5) manual documents its format and initialization behavior.

How to check the current machine-id

On a system you administer, display the current value with:

cat /etc/machine-id

A normally initialized system displays a 32-character hexadecimal value. Do not write an arbitrary string into the file merely because it is empty or missing. Images, containers, and read-only file systems can initialize the ID differently during boot.

Do not paste the real ID into a public post, log, or support request. Systemd says it should be treated as confidential and not exposed to untrusted environments, especially over a network. If an application needs a stable identifier that it can expose, it should use an application-specific derived ID rather than publishing the raw machine-id.

Does a reboot or hostname change affect it?

Normally, no. The machine-id is persistent for an operating system installation rather than regenerated on every boot. It is independent of the hostname, IP address, and MAC address.

If two servers have different names but the same machine-id, investigate whether an image was copied without being prepared for cloning. Conversely, matching hostnames do not necessarily imply matching machine IDs.

When should you reset a machine-id?

The main case is preparing one operating system image for use by multiple virtual machines, cloud instances, or containers. A direct disk clone can copy /etc/machine-id along with everything else. To give each instance its own ID, prepare the source image while it is shut down, then let each clone obtain an ID when it boots.

There is usually no reason to reset the ID on a running server just to make it different. Do so only for a specific need, such as fixing duplicate IDs or building a deployment image. Systemd notes that network-visible identifiers can be derived from the machine-id; see its guidance on building images safely.

How the file state affects first boot

Removing /etc/machine-id and leaving it empty are not equivalent. Decide whether the image should also run first-boot initialization.

When systemd considers a boot the first one, units with ConditionFirstBoot=yes can run, along with other initialization. An empty file allows an ID to be established without triggering those first-boot actions. A read-only file system may also require an existing empty file so a temporary ID can be bind-mounted over it. See the First Boot Semantics section of machine-id(5) for the exact rules.

Resetting the ID in an image intended for cloning

The following example assumes that a powered-off image has been mounted by a separate management system at /mnt/image-root. Replace that path with the actual mount point. These commands are not instructions to modify /etc/machine-id on a running production server.

1. Shut down the source VM or image and make a backup or snapshot. Keep the original if you are turning a copy into a reusable template.
2. Mount the image on another system. Confirm that /mnt/image-root really is the image's mount point, then inspect both ID paths:

findmnt --mountpoint /mnt/image-root
ls -l /mnt/image-root/etc/machine-id /mnt/image-root/var/lib/dbus/machine-id

If findmnt does not show the intended mount point, stop. /var/lib/dbus/machine-id may be a symbolic link to /etc/machine-id or a separate file. If a separate file retains the old ID, systemd may reuse it.

To run first-boot initialization as well

On a writable image that should be recognized as a first boot, verify the mount point again and remove the file inside the image:

sudo rm -- /mnt/image-root/etc/machine-id

Alternatively, if the image needs the file to remain present, write uninitialized followed by a newline. Choose one method, not both:

printf 'uninitialized\n' | sudo tee /mnt/image-root/etc/machine-id > /dev/null

If /var/lib/dbus/machine-id is a separate regular file containing the previous ID, it must also be reset. Only after confirming with ls -l that it is not a symbolic link, remove that file from the powered-off image:

sudo rm -- /mnt/image-root/var/lib/dbus/machine-id

If it is a symbolic link, do not run that command. Check its target and the distribution's layout instead. Systemd can reuse a separate D-Bus ID when /etc/machine-id is empty or absent.

To get a new ID without first-boot actions

If first-boot-only units should not run, leave an empty file inside the image:

sudo truncate -s 0 -- /mnt/image-root/etc/machine-id

Systemd can establish an ID from an empty file but does not treat that boot as the first one. An empty file can also matter for a read-only image. This method still requires checking for a separate D-Bus ID that could be reused, as described above.

Unmount the image cleanly, boot a clone, and verify that each deployed instance has a different ID. Compare actual values only within a trusted management environment; do not publish them. Running systemd-machine-id-setup alone does not guarantee a random ID, because it can reuse an existing D-Bus ID or another supplied value. Its order of precedence is described in the systemd-machine-id-setup(1) manual.

What do two commonly suggested commands actually do?

You may also see this pair presented as a way to reset the machine-id:

sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id

The first command reduces /etc/machine-id to zero bytes without removing it. Systemd can establish an ID at the next boot, but an empty file does not trigger first-boot-only units. It does not immediately replace the ID already held by the running system and its services.

The second command removes the D-Bus ID path. If that path is a separate regular file containing the old ID, removing it can prevent reuse. If it is a symbolic link to /etc/machine-id, however, rm -f removes only the link. The -f option also suppresses an error when the path does not exist, so successful execution is not proof that the IDs were reset correctly.

Do not copy these two commands directly onto a running production server as a routine procedure. First inspect the paths with ls -l /etc/machine-id /var/lib/dbus/machine-id. For a cloning template, use the powered-off-image procedure above and verify the result after each clone boots. Systemd may obtain an ID from other environment-provided sources as well as D-Bus; see the initialization order in machine-id(5).

If running servers already have duplicate IDs

Do not simply empty or remove /etc/machine-id while continuing to run a production server. Running processes may have cached the existing value, and journal, network, or application state may be affected. Identify the original and the clone, choose which instance will change, and plan downtime.

Back up affected services and data, shut down the clone, and modify its disk from a separate environment. After it boots, confirm that its new ID differs from other systems and that networking and relevant services work normally. Preparing a complete VM template may also require resetting SSH host keys, random seeds, hostnames, and other per-instance state. The Red Hat guide to VM templates describes using virt-sysprep; review its full set of changes before using it.

Frequently asked questions

Can I use a machine-id as a password or authentication token?

No. It identifies a system; it is not an authentication secret. Avoid exposing the raw value, but do not design authentication around it.

Do matching machine IDs prove two systems are identical?

No. A cloning process may have copied the ID. Inspect the systems and the image-deployment process rather than assuming they are the same machine.

Does changing the hostname with hostnamectl change the machine-id?

No. The hostname and machine-id serve different purposes and are stored separately. Renaming a host does not generate a new /etc/machine-id.

Should I delete or empty the file in a cloning image?

Remove it or mark it uninitialized if first-boot initialization should run. Leave it empty if you only need a new ID without those first-boot actions. Check the image builder's requirements, including read-only file systems.