8

I have an Amazon EC2 instance. I can login just fine, but neither "su" nor "sudo" work now (they worked fine previously):

  • "su" requests a password, but I login using ssh keys, and I don't think the root user even has a password.

  • "sudo <anything>" does this:


sudo: /etc/sudoers is owned by uid 222, should be 0 
sudo: no valid sudoers sources found, quitting 

I probably did "chown ec2-user /etc/sudoers" (or, more likely "chown -R ec2-user /etc" because I was sick of rsync failing), so this is my fault.

How do I recover? I stopped the instance and tried the "View/Change User Data" option on the AWS EC2 console, but this didn't help.

EDIT: I realize I could kill this instance and create a new one, but was hoping to avoid something that extreme.

8

In that kind of situation I think you should be able to use a second instance to fix the problem:

  • Detach the EBS disk containing the broken system
  • Create another EC2 instance
  • Attach & mount the disk to the new instance
  • Fix the permissions
  • Umount, detach & reattach to the original instance
5
  1. Stop your current instance
  2. Detach Existing Volume
  3. Create a new Volume
  4. Attach new volume to your instance as "/dev/xvda"
  5. Start your instance
  6. Attach the old volume (one which has sudo privilege issue) back to the instance while it is running as "/dev/sdf"
  7. Login to your instance using putty
  8. Use the lsblk command to view your available disk devices and their mount points (if applicable) to help you determine the correct device name to use.

      ec2-user ~$ lsblk
      NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
      xvdf 202:80 0 100G 0 disk
      xvda1 202:1 0 8G 0 disk /
    

The output of lsblk removes the /dev/ prefix from full device paths. In this example, /dev/xvda1 is mounted as the root device (note the MOUNTPOINT is listed as /, the root of the Linux file system hierarchy), and /dev/xvdf is attached, but it has not been mounted yet.

  1. Use the following command to create a mount point directory for the volume. The mount point is where the volume is located in the file system tree and where you read and write files to after you mount the volume. Substitute a location for mount_point, such as /data.

    sudo su
    cd /mnt
    mkdir other
    mount /dev/xvdf other
    cd /
    chown -R root:root /mnt/other/etc/
    exit
    
  2. Go back to AWS and stop the instance

  3. Detach both the volumes and re-attach old (now fixed) volume as /dev/xvda
  4. Start your instance and now your permissions should be back to what it was
  • Totally worked, but I had to reattach as /dev/sda1, not /dev/xvda. Thanks! – Erik Aronesty Nov 3 '17 at 13:57
1

I was having the same issue and because it was so difficult I made a video to explain the solution. This is pretty much the same thing as Rekee's solution in the form of a video tutorial.

http://youtu.be/gh5CDtRX7Ho

Hope it helps. :)

0

Looks like you've answered this yourself...

I probably did "chown ec2-user /etc/sudoers" (or, more likely "chown -R ec2-user /etc" because I was sick of rsync failing), so this is my fault.

Either way, I don't think you can resolve this without gaining a root shell. (I'm unsure what recovery methods are possible on ec2?)

If you did indeed recursively chown /etc then I think rebuilding the server is the best way to go.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.