How do I fix sudo errors on my Amazon EC2 or Lightsail instance when I run the sudo command?

Short description

If you delete or incorrectly configure the /etc/sudoers file, then you might receive the following syntax or sudo errors:

• "sudo: /etc/sudoers is owned by uid 1000, should be 0"
• "sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set"
• "sudo: unable to open /etc/sudoers: No such file or directory"
• "sudo: no valid sudoers sources found, quitting"
• "sudo: error initializing audit plugin sudoers_audit"

If you receive one of these errors, then you can't grant users or user groups access to system resources. To fix the /etc/sudoers and /usr/bin/sudo files on Amazon EC2 or Lightsail, use a user data or launch script to modify the file permissions. Or, attach the root disk to a rescue instance to manually make changes.

Note: If you deleted the /etc/sudoers file, then you must use a user data script to recreate it.

Resolution

Note: If you receive errors when you run AWS Command Line (AWS CLI) commands, then see Troubleshooting errors for the AWS CLI. Also, make sure that you're using the most recent AWS CLI version.

Use a user data or launch script to modify the file permissions

To resolve the "owned by uid 1000" or "must be owned by uid 0" error messages, you must modify the /etc/sudoers and /usr/bin/sudo file permissions.

For Amazon EC2 instances, complete the following steps to use a user data script to modify the file permissions:

1. Open the Amazon EC2 console.

2. In the navigation pane, choose Instances, and then select the EC2 instance.

3. Choose Instance state, and then choose Stop instance.

4. Choose Actions, and then select Instance settings.

5. Choose Edit user data.

6. Enter the following script:

   Content-Type: multipart/mixed; boundary="//"
   MIME-Version: 1.0
   --//
   Content-Type: text/cloud-config; charset="us-ascii"
   MIME-Version: 1.0
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="cloud-config.txt"
   #cloud-config
   cloud_final_modules:
   - [scripts-user, always]
   --//
   Content-Type: text/x-shellscript; charset="us-ascii"
   MIME-Version: 1.0
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="userdata.txt"
   
   #!/bin/bash
   # To fix error sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set. use below commands
   chown -R root:root /usr/bin/sudo
   chmod 4755 /usr/bin/sudo
   
   # to fix below sudo errors:
   #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
   
   chown -R root:root /etc/sudoers
   chown -R root:root /etc/sudoers.d/
   sudo service sshd restart
   --//--

7. Start the instance, and then wait for it to pass its status checks.

8. Connect to the instance, and then run the following command to validate that the permissions of /etc/sudoers and /usr/bin/sudo files are correct:

   sudo ls -la /etc/sudoers
   sudo ls -la /usr/bin/sudo

   The following example output shows the correct permissions:

   $sudo ls -la /etc/sudoers /usr/bin/sudo 
   -r--r----- 1 root root   1714 Jun 25 13:38 /etc/sudoers
   -rwsr-xr-x 1 root root 281624 Jun 27  2023 /usr/bin/sudo

For Lightsail instances, complete the following steps to use a launch script to modify the file permissions:

1. Open the Lightsail console.

2. Choose Snapshots, and then select your instance snapshot.

3. Choose Actions, and then select Create new instance.

4. Under Optional, choose + Add launch script.

5. Enter the following launch script:

   #!/bin/bash
   # To fix error sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set. use below commands
   chown -R root:root /usr/bin/sudo
   chmod 4755 /usr/bin/sudo
   
   # to fix below sudo errors:
   #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
   
   chown -R root:root /etc/sudoers
   chown -R root:root /etc/sudoers.d/
   sudo service sshd restart
   --//--

6. Choose Create instance.

7. Connect to the instance, and then run the following command to check the permissions of the /etc/sudoers and /usr/bin/sudo files:

   sudo ls -la /etc/sudoers
   sudo ls -la /usr/bin/sudo

   The following example output shows the correct permissions:

   $sudo ls -la /etc/sudoers /usr/bin/sudo 
   -r--r----- 1 root root   1714 Jun 25 13:38 /etc/sudoers
   -rwsr-xr-x 1 root root 281624 Jun 27  2023 /usr/bin/sudo

Attach a root disk to a rescue instance

Configure your instance for a stop and start

Note: When you stop and start an instance, the instance's public IP address changes. It's a best practice to use an Elastic IP address to route external traffic to your instance instead of a public IP address. If you use Amazon Route 53, then you might need to update the Route 53 DNS records when the public IP address changes.

Before you stop and start your instance, take the following actions:

• If your instance uses an instance store, then save the volume data on the instance store to persistent storage. For example, you can save the data to Amazon Elastic Block Store (Amazon EBS) volumes or Amazon Simple Storage Service (Amazon S3) buckets.
  Important: Amazon EC2 deletes instance store data when you stop the instance.
• Create a snapshot of your Amazon EBS volume. If you experience issues, then you can use the snapshot to restore your instance.
• Temporarily remove the instance from its Amazon EC2 Auto Scaling group so that you don't accidentally terminate the instance when you stop it.
  Note: EC2 Auto Scaling might terminate stopped instances in an Auto Scaling group based on your scale-in protection settings. Instances that you launch with Amazon EMR, AWS CloudFormation, or AWS Elastic Beanstalk might be in an Auto Scaling group.
• Set the instance shutdown behavior to Stop to make sure that the instances don't terminate when you stop them.

Attach the root disk to a rescue instance

Complete the following steps:

1. Create a new key pair.

2. Get the volume ID and device name for the original instance's root volume.

3. Stop the original instance.

4. Launch a recovery instance from an Amazon Machine Image (AMI) with the same Linux operating system (OS) version in the same Availability Zone.

5. Detach the root volume from the original instance, and then attach it to the recovery instance as a secondary volume.

6. Connect to the recovery instance with your new SSH key pair.

7. Run the following command to change to the root user:

   sudo su

8. To identify the blocked device name and partition, run the following command from the recovery instance:

   lsblk

   Example output

   [root ~]$ lsblk
   NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
   xvda    202:0    0    8G  0 disk
   └─xvda1 202:1    0    8G  0 part /
   xvdf    202:80   0  101G  0 disk
   └─xvdf1 202:81   0  101G  0 part
   xvdg    202:96   0   30G  0 disk

   In the preceding example, the xvda and xvdf volume device names are partitioned volumes, and xvdg isn't a partitioned volume.
   If your volume is partitioned, then run the following command to mount the /dev/xvdf1 partition instead of the /dev/xvdf raw device:

   mount -o nouuid  /dev/xvdf1 /mnt

   If you use an instance that's built on the AWS Nitro System, then the volume device name uses the /dev/nvme[0-26]n1 format. Run the following command to mount the partition at the /mnt directory:

   mount -o nouuid  /dev/nvme1n1p1 /mnt

   Note: Replace /dev/nvme1n1p1 with the device name that you identified with the lsblk command. For more information, see Device names for volumes on Amazon EC2 instances.

9. To copy the /etc/sudoers file from the working instance as a backup, run the following command:

   cp /etc/sudoers /mnt/etc/sudoers.bak

10. To create a chroot environment in the /mnt directory, run the following command:

    for i in dev proc sys run; do mount -o bind /$i /mnt/$i; done; chroot /mnt

    The preceding command bind mounts the /dev, /proc, /sys, and /run directories from the original root file system. This configuration allows processes that run inside the chroot environment to access these system directories.

11. To edit the /etc/sudoers file, run the following command inside the chroot environment:

    visudo

    Make sure that the file has the following default settings:

    # This file MUST be edited with the 'visudo' command as root.
    
    # Please consider adding local content in /etc/sudoers.d/ instead of
    # directly modifying this file.
    
    # See the man page for details on how to write a sudoers file.
    
    Defaults env_reset
    Defaults mail_badpass
    Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
    # Host alias specification
    # User alias specification
    # Cmnd alias specification
    # User privilege specification
    root ALL=(ALL:ALL) ALL
    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) ALL
    # Allow members of group sudo to execute any command
    %sudo ALL=(ALL:ALL) ALL
    # See sudoers(5) for more information on "#include" directives:
    #includedir /etc/sudoers.d

    Note: The visudo command locks the sudoers file.
    If you receive errors when you run the preceding command, then run the following diff command to compare the /etc/sudoers file with the new file /etc/sudoers.bak:

    diff /etc/sudoers /etc/sudoers.bak

    Note: If you didn't make custom changes before you edited the file, then restore the /etc/sudoers.bak file to /etc/sudoers.

12. To exit the chroot environment, run the following command:

    exit

13. To unmount the root volume, run the following command:

    umount -fl /mnt

14. Detach the root volume that you attached as a secondary volume from the recovery instance. Then, reattach it to the original instance with the device name from step 2.

15. Start the original instance, and then run the following command to confirm that the sudo commands work correctly:

    sudo su

Use user data to modify the file content or recreate the file

Note: To use the following troubleshooting method, you must set a password for the root user.

Recreate the file

To access the instance as a root user so that you can recreate the file, complete the following steps:

1. Open the Amazon EC2 console.

2. In the navigation pane, choose Instances, and then select the instance.

3. Choose Instance state, and then choose Stop instance.

4. Under Stop instance?, choose Stop.

5. Choose Actions, and then select Instance settings.

6. Choose Edit user data.

7. Enter the following script to set a temporary password for the root user:

   Content-Type: multipart/mixed; boundary="//"            
   MIME-Version: 1.0
   
   --//
   Content-Type: text/cloud-config; charset="us-ascii"
   MIME-Version: 1.0
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="cloud-config.txt"
   
   #cloud-config
   cloud_final_modules:
   - [scripts-user, always]
   
   --//
   Content-Type: text/x-shellscript; charset="us-ascii"
   MIME-Version: 1.0
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="userdata.txt"
   
   #!/bin/bash
   chpasswd <<<"root:root"
   --//

   Important: This password uses plain text to pass secrets and isn't secure. Make sure that you remove the temporary password from the root user after you complete the troubleshooting steps.

8. Start the instance, and then log in as ec2-user.

9. To recreate the /etc/sudoers file, run the following pkexec command:

   pkexec /usr/sbin/visudo

10. Enter the root user password, and then modify the /etc/sudoers file with the following values:

    # This file MUST be edited with the 'visudo' command as root.
    #
    # Please consider adding local content in /etc/sudoers.d/ instead of
    # directly modifying this file.
    #
    # See the man page for details on how to write a sudoers file.
    #
    Defaults    env_reset
    Defaults    mail_badpass
    Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    
    # Host alias specification
    
    # User alias specification
    
    # Cmnd alias specification
    
    # User privilege specification
    root    ALL=(ALL:ALL) ALL
    
    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) ALL
    
    # Allow members of group sudo to execute any command
    %sudo   ALL=(ALL:ALL) ALL
    
    # See sudoers(5) for more information on "#include" directives:
    
    #includedir /etc/sudoers.d

11. Run a sudo command to verify that sudo works correctly.

12. Stop the instance.

Delete the user data script

To use the Amazon EC2 console to delete the user data values, including the root user password, complete the following steps:

1. Open the Amazon EC2 console.
2. In the navigation pane, choose Instances, and then select the instance.
3. Choose Actions, and then choose Instance settings.
4. Choose Edit user data, and then delete all user data.

To use the AWS CLI to delete the user data values, including the root user password, run the following modify-instance-attribute command:

aws ec2 modify-instance-attribute --instance-id example-instance-id --user-data Value=""

Note: Replace example-instance-id with your instance ID.

To verify that you removed the user data, run the following describe-instance-attribute command:

aws ec2 describe-instance-attribute --instance-id example-instance-id --attribute userData

Note: Replace example-instance-id with your instance ID.

After you delete the user data, start the instance.

Related information

Why can't I run sudo commands on my EC2 Linux instance?