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.

Improve this question

4 Answers 4

Reset to default
7

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
Improve this answer
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
Improve this answer
1
  • Totally worked, but I had to reattach as /dev/sda1, not /dev/xvda. Thanks!
    – Erik Aronesty
    Nov 3, 2017 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. :)

Improve this answer
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.

Improve this answer

You must log in to answer this question.