The page provides tips on using the sudo command-line utility, managing the
sudoers plugin, and preventing or fixing issues that arise.
During each execution of the sudo command, the following process takes place
to validate the sudoers files:
The validation of the sudoers files might fail due to any of the following
errors:
You must follow specific syntax rules when you make changes to the sudoers
files. Any deviation from this syntax, including but not limited to a
missing or extra character or an inappropriate comma, can make the file
invalid. Invalidation of the file makes it impossible to use the sudo
utility.
Solution
The solution is to use visudo utility to edit the sudoers files. It
validates the file content before saving and notifies in case of issues. The
visudo utility was created for editing the file in a safe fashion.
The following examples shows both correct and incorrect syntax samples:
Correct syntax
user ALL=(ALL) ALL
Incorrect syntax
user ALL=(ALL), ALL
Syntax error example
$ sudo useradd username
/etc/sudoers:20:17: syntax error
user ALL=(ALL), ALL
^
Errors of this type can be caused by one of the following:
sudoers plugin.However, logical errors are not recognized during validation, because they do not violate syntax rules and therefore are tricky to detect.
Solution
You must carefully read the official documentation and adhere to its principles when you edit the file.
Google also recommends that you use the visudo utility to edit the
sudoers files, as it can detect some types of logical errors, such as:
If any issues are detected, you see a warning message.
The following examples shows both logically correct and incorrect samples:
Logically correct
barbara ALL=(ALL:ALL) /usr/bin/ls
Logically incorrect
barbara ALL=(4LL:ALL) /usr/bin/ls
^
barbara ALL=(ALL;ALL) /usr/bin/ls
^
bar6ara ALL=(ALL:ALL) /usr/bin/1s
^ ^
In addition to errors caused by the content of the sudoers files, their
excessive file permissions or incorrect ownership can also cause the sudo
utility to fail.
Solution
You see a description of these errors in the output of the failed sudo
command. Read through the error message description and make the necessary
corrections.
The following is an example of the correct file permissions and ownership
$ ls -l /etc/sudoers
-r--r----- 1 root root 700 Jan 1 12:00 /etc/sudoers
$ sudo useradd username
The following example shows the error that is displayed when there are redundant permissions for the all users permission group:
$ ls -l /etc/sudoers
-r--r---w- 1 root root 700 Jan 1 12:00 /etc/sudoers
$ sudo useradd username
sudo: /etc/sudoers is world writable
sudo: no valid sudoers sources found, quitting
sudo: error initializing audit plugin sudoers_audit
The following example shows the error that
is displayed for incorrect ownership. In this example, a user with an ID
that is not 0 (or a user that is not root) is the owner of the file:
$ ls -l /etc/sudoers
-r--r----- 1 user user 700 Jan 1 12:00 /etc/sudoers
$ sudo useradd username
sudo: /etc/sudoers is owned by uid 1000, should be 0
sudo: no valid sudoers sources found, quitting
sudo: error initializing audit plugin sudoers_audit
For more information about the configuration of the sudoers files, read
Sudoers Manual.
To learn how to manage and use the visudo editor, read
Visudo Manual.
Issues in the sudoers files cause negative effects and can affect the
functionality of the entire system.
The sudo command no longer works.
This is the most noticeable consequence of issues in the sudoers files.
The consequence of this is the inability to use elevated privileges for
users, which blocks their activity on the server.
However, more destructive and unpredictable consequences are failures of the
applications that rely on the sudo command. In some cases, this may cause
the application to fail completely, leading to unexpected behavior, crashes,
or data loss. Another example is when the sudo command is called by an
application during the OS boot sequence and fails. It can lead to OS failure
or cause the boot sequence to get stuck.
Possible unauthorized access to the system.
Another risky consequence is that issues in the sudoers files can lead to
unauthorized access to the system. This can happen due to a logical error,
when rules in the sudoers files give some users or groups excessive
permissions.
This may also happen because the system owner temporarily disables or weakens the system's defenses in order to log in and fix the problem.
If you lose elevated user privileges or can't use the sudo command due to
problems with the sudoers files, then use the superuser account for recovery.
In Unix-like operating systems, the superuser is a special user account with ID
equal to 0, that is usually called root. The superuser has full access to the
system resources, and can perform any administrative task without restrictions.
While interacting with the OS on behalf of the superuser is generally considered
insecure, it may be the only option for certain tasks such as recovery of the
sudoers files.
Logging in directly as the superuser exposes the OS to risk. To avoid this risk, Google recommends that you use a startup script functionality, as this script is executed on behalf of the superuser.
Read more about Compute Engine startup scripts.
To recover the sudoers files with a startup script, do the following:
Create a backup copy of the current startup script if it's already in use. The backup approach depends on how the startup script is configured.
If the script content is set directly in the metadata value, you can copy the script content to the Cloud Storage bucket, local file or any other temporary private storage.
If the contents of the script are already in the remote storage and its
URL address is used, then you can just temporary remove the
startup-script-url metadata key to disable the current startup script.
Update the startup script with the following command sequence:
mv /etc/sudoers /etc/sudoers.backup.$(date +"%s") && echo "%google-sudoers ALL=(ALL:ALL) NOPASSWD:ALL" > /etc/sudoers && chown 0:0 /etc/sudoers && chmod 0440 /etc/sudoers
Read more about what the commands does
mv /etc/sudoers /etc/sudoers.backup.$(date +"%s")
This command creates a copy of the /etc/sudoers file
with a different name and deletes the original file. The
name of the new file contains a timestamp at the end for
uniqueness (e.g. sudoers.backup.1672527600).
echo "%google-sudoers ALL=(ALL:ALL) NOPASSWD:ALL" > /etc/sudoers
This command creates previously deleted file
/etc/sudoers with a single rule that allows authorized
Google Cloud users with access to the VM to execute any
commands on behalf of any system user. This rule always
exists by default in an additional file
/etc/sudoers.d/google_sudoers.
chown 0:0 /etc/sudoers
This command sets the owner of the /etc/sudoers file to a
user whose ID is 0 and a group of owners to a group
whose ID is 0.
chmod 0440 /etc/sudoers
This command sets permissions for the /etc/sudoers
file to read-only and allows only its owner and owner group
to read the file.
Stop the VM, if it's running. Restart the VM to trigger the execution of the startup script.
Сonnect to the VM and edit the
broken sudoers file to recover it.
sudo visudo /etc/sudoers.backup.TIMESTAMPSave the changes and replace the current /etc/sudoers file with the file
you just edited.
sudo mv /etc/sudoers.backup.TIMESTAMP /etc/sudoersMake sure that the original issue with using the sudo command and elevated
privileges has been fixed.
Remove the temporary startup script and restore the original one if it was used.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2026-07-17 UTC.