How to Repair a Corrupted sudoers File on an AWS EC2 Instance (Without Detaching the Root Volume)

A corrupted sudoers file can prevent users from running any sudo command on an Amazon EC2 instance. This usually happens after an incorrect modification to /etc/sudoers or a file under /etc/sudoers.d/. When the configuration becomes invalid, administrative access through sudo stops working, making server management difficult.

Most recovery guides recommend detaching the root EBS volume and attaching it to another EC2 instance to repair the file. However, if your instance uses cloud-init, there is a much faster approach. You can use an EC2 User Data script to restore the sudoers configuration during the next boot without detaching the root volume.

In this guide, I’ll show you how to recover an AWS EC2 instance using this method.

Symptoms

If the sudoers file is corrupted, you may encounter errors similar to the following:

>>>/etc/sudoers.d/90-cloud-init-users: syntax error near line 5 <<<
sudo: parse error in /etc/sudoers.d/90-cloud-init-users near line 5
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

Why This Happens

This issue commonly occurs when:

• The sudoers file is edited using a normal text editor instead of visudo.
• Invalid syntax is added to /etc/sudoers.
• A file under /etc/sudoers.d/ contains incorrect entries.
• Incorrect file permissions or ownership are applied.
• An automation or deployment script accidentally modifies the file.

Since the sudoers configuration is invalid, Linux refuses to execute any sudo command to prevent potential privilege escalation.

Solution

Follow the steps below to recover the instance without detaching the root EBS volume.

Step 1 – Stop the EC2 Instance

Open the AWS Management Console, navigate to EC2, select the affected instance, and stop it.

Note: Ensure the instance is EBS-backed before stopping it.

Step 2 – Edit EC2 User Data

After selecting the instance, navigate to:

Actions → Instance Settings → Edit User Data

Step 3 – Add the Recovery Script

Paste the following script into the User Data section.

#cloud-boothook
#!/bin/bash
cp /etc/sudoers.d/90-cloud-init-users /etc/sudoers.d/90-cloud-init-users.bkp
echo "ec2-user    ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/90-cloud-init-users

What does this script do?

• Creates a backup of the existing sudoers file.
• Generates a new valid sudoers configuration.
• Allows the ec2-user to execute commands using sudo.
• Runs automatically during the next boot through cloud-init.

Note: Replace ec2-user with the appropriate username for your Linux distribution.

Step 4 – Start the EC2 Instance

Save the User Data and start the EC2 instance.

Once the instance is running, connect via SSH.

Step 5 – Verify the Fix

Run the following command:

sudo whoami

Expected output:

root

You can also validate the sudoers configuration using:

sudo visudo -c

If no errors are reported, the recovery was successful.

Step 6 – Review the Original File

The original file is backed up as:

/etc/sudoers.d/90-cloud-init-users.bkp

Review this backup to identify the incorrect entry that caused the syntax error.

Best Practices

To avoid this issue in the future:

• Always edit the sudoers file using visudo.
• Take an AMI or snapshot before modifying system configuration.
• Test changes in a non-production environment.
• Keep a backup of the original configuration.
• Validate the configuration using visudo -c before logging out.

Conclusion

A corrupted sudoers file can completely block administrative access to an AWS EC2 instance, but it doesn’t always require detaching the root EBS volume. By using an EC2 User Data script, you can quickly restore a valid sudoers configuration during boot and regain access to the server.

After recovering the instance, always review the original configuration, validate it with visudo, and use visudo for all future changes to avoid similar issues.