Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

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
share|improve this answer
  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

  1. Go back to AWS and stop the instance
  2. Detach both the volumes and re-attach old (now fixed) volume as /dev/xvda
  3. Start your instance and now your permissions should be back to what it was
share|improve this answer

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.

share|improve this answer

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.

Hope it helps. :)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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