All Products
Search

This Product

    :Missing critical system users in a Linux instance

    Document Center

    :Missing critical system users in a Linux instance

    Last Updated:Jun 20, 2026

    If critical system users are missing from a Linux instance, you may be unable to establish a remote connection. You can use the instance health diagnostics feature to resolve this issue.

    Prerequisites

    A diagnostic report from the instance health diagnostics feature indicates that the root account check on the Linux instance has failed.

    Background

    Symptom: In a Linux operating system, the /etc/passwd file stores basic information for all system users, and the /etc/shadow file stores password information for system users. If critical system user information, such as the root user and its password, is lost from these files, you cannot log in to the instance.

    Solution: You need to restore the information in the /etc/passwd and /etc/shadow configuration files. Additionally, the /etc/group file must also be fixed because it stores basic information about system groups and the relationships between users and groups.

    Procedure

    1. Prepare the correct system user configuration files.

      The required repair steps depend on your specific Linux distribution because the set of critical system users can vary and you may have created additional users.

      Obtain the correct system user configuration files from a healthy ECS instance to use as a reference for the affected instance. The healthy ECS instance must run the same Linux distribution and have the same software packages as the affected instance. The required configuration files are located at the following paths:

      • /etc/passwd
      • /etc/shadow
      • /etc/group
      You can view the configuration files directly on the healthy ECS instance or download them to your local machine for reference. This topic uses CentOS 7.5 as an example. The following are samples of the file content:
      • /etc/passwd
        root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
polkitd:x:999:998:User for polkitd:/:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
postfix:x:89:89::/var/spool/postfix:/sbin/nologin
chrony:x:998:996::/var/lib/chrony:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/sbin/nologin
      • /etc/shadow
        root:$6$Q9lA****/t1KPM$JLqO59UTxwGm****/rU7bHL0q5TVAij****/KeWAWPiO.6booVwpp7rdR9****.irQ6nso3YGVSqQqpyT****.:18668:0:99999:7:::
bin:*:17632:0:99999:7:::
daemon:*:17632:0:99999:7:::
adm:*:17632:0:99999:7:::
lp:*:17632:0:99999:7:::
sync:*:17632:0:99999:7:::
shutdown:*:17632:0:99999:7:::
halt:*:17632:0:99999:7:::
mail:*:17632:0:99999:7:::
operator:*:17632:0:99999:7:::
games:*:17632:0:99999:7:::
ftp:*:17632:0:99999:7:::
nobody:*:17632:0:99999:7:::
systemd-network:!!:17864::::::
dbus:!!:17864::::::
polkitd:!!:17864::::::
sshd:!!:17864::::::
postfix:!!:17864::::::
chrony:!!:17864::::::
ntp:!!:17864::::::
tcpdump:!!:17864::::::
nscd:!!:17864::::::
      • /etc/group
        root:x:0:
bin:x:1:
daemon:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:
mem:x:8:
kmem:x:9:
wheel:x:10:
cdrom:x:11:
mail:x:12:postfix
man:x:15:
dialout:x:18:
floppy:x:19:
games:x:20:
tape:x:33:
video:x:39:
ftp:x:50:
lock:x:54:
audio:x:63:
nobody:x:99:
users:x:100:
utmp:x:22:
utempter:x:35:
input:x:999:
systemd-journal:x:190:
systemd-network:x:192:
dbus:x:81:
polkitd:x:998:
ssh_keys:x:997:
sshd:x:74:
postdrop:x:90:
postfix:x:89:
chrony:x:996:
ntp:x:38:
tcpdump:x:72:
nscd:x:28:
    2. Establish a remote connection to the affected instance.
      When an ECS instance is in repair mode with a mounted repair disk, you can connect to the instance only by using VNC. For more information, see Connect to an instance by using VNC.
    3. View the mount information of the original system disk of the affected instance.
      On the mounted repair disk, the file system of the original system disk is mounted to a temporary directory. You can use one of the following methods to find the directory:
      • On the details page of the system disk, view the Associated Instances/tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse**** section. The path of the temporary directory is in the format of . In this example, is the temporary directory, where bp19bspzms79kqse**** is the cloud disk serial number of the original system disk.
      • On the mounted repair disk, run the mount command. For example, if the device path of the original system disk is /dev/vda, run the following command:
        mount | grep /dev/vda
        The following output is returned:
        /dev/vda1 on /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse**** type ext4 (rw,relatime)
    4. Run the chroot command on the temporary path of the original system disk to enter the chroot environment.
      You must perform the file repair in the temporary path of the original system disk. For example, if the temporary path is /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****, run the following command:
      chroot /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****
    5. In the chroot environment, run the following commands to back up the original /etc/passwd and /etc/shadow files. 
      cp /etc/passwd /etc/passwd.bak
cp /etc/shadow /etc/shadow.bak
    6. /etc/passwdAdd the missing information to the file.
      1. Use the instance health diagnostic report in the ECS console to obtain information about the missing critical system users.
      2. /etc/passwdFrom the reference configuration file, find and copy the line for the corresponding critical system user.
      3. chroot/etc/passwdPaste the line to the corresponding position in the file in the .
        Note You can connect to an ECS instance in repair mode only by using a VNC remote connection. To paste the copied content, click the Paste from clipboard button at the top of the window.
        /etc/passwd The following describes the format of the file.
        An example of a user information line is as follows: 
        postfix:x:89:89::/var/spool/postfix:/sbin/nologin
        Each user information line contains the following seven fields, separated by colons (:): 
        username:password:UID:GID:user description:home directory:logon shell
        After you paste the user information, check the new entry:
        • UIDUIDEnsure that the new UID is unique within the file.
        • GIDchroot/etc/group/etc/groupGIDchroot/etc/groupGIDGIDThe of the new user must exist in the file of the . If the does not exist, copy the line that contains the corresponding from the reference file to the file in the . Ensure that the new GID is unique within the file.
          For example:
          • chroot/etc/groupGID/etc/groupIf the file of the contains the 89, you do not need to modify the file.
          • chroot/etc/groupGID/etc/groupGIDchroot/etc/groupGIDIf the file of the does not contain the 89, you must copy the line that contains the 89 from the reference file to the file in the . Ensure the GID is unique within the file.
        • /etc/groupchroot/etc/groupIf the new user is associated with a group in the reference file, make sure that the same association is present in the file of the .

          For example, if the postfix user is missing from the /etc/passwd file in the chroot environment, you must copy the correct configuration entries from the /etc/passwd and /etc/group files. If the correct /etc/group file specifies that the postfix user also belongs to the mail group (for example, mail:x:12:postfix), you must also copy this configuration entry to the /etc/group file in the chroot environment.

    7. /etc/shadowAdd the missing information to the file.
      1. Use the instance health diagnostic report in the ECS console to obtain information about the missing critical system users.
      2. /etc/shadowFrom the reference configuration file, find and copy the line for the corresponding critical system user.
      3. Paste the line to the corresponding position in the /etc/shadow file in the chroot environment.
        Note You can connect to an ECS instance in repair mode only by using a VNC remote connection. To paste the copied content, click the Paste from clipboard button at the top of the window.
        If no information is missing from the /etc/shadow file in the chroot environment, you do not need to paste any content.
    8. After the repair is complete, exit the chroot environment and check the status of the instance.
      1. exitchrootRun the command to exit the .
      2. In the ECS console, navigate to the instance health diagnostics page, detach the repair disk, and then return the instance to normal operating mode.
      3. Establish a remote connection to the repaired ECS instance to verify that you can log on.

    Other solutions

    For more information about how to attach the system disk of an affected instance to a healthy instance for repair, see Critical system users are missing from a Linux instance.