69

I clean-installed Ubuntu 11.10 today, and then installed VirtualBox. This required me to add myself to the vboxusers group, and since 11.10 seems to no longer have a graphical app to add users to a group, I ran the following command:

sudo usermod -G vboxusers stephane

This is a problem. I now see what I should have run instead is:

sudo usermod -aG vboxusers stephane

The end result is I'm no longer in the groups I should be in. Including whatever group is required to run "sudo". When I run any command as sudo now, I get the following:

$ sudo ls
[sudo] password for stephane: 
stephane is not in the sudoers file.  This incident will be reported.

Is there a way to fix this, or do I need to re-install from scratch again?

0

5 Answers 5

69
  1. During boot, press and hold the left Shift key, and you should see the GRUB menu.

  2. Select the entry containing (recovery mode) and wait.

  3. You should now be presented with a menu. Select:

    remount    Remount / read/write and mount all other file systems 
    

    and wait for your file systems to get mounted with read/write permissions, then press Enter.

    If this option doesn't appear or won't work, you can instead choose the root option and use the following command to mount the system partition:

    mount -o remount /
    

    You can check out which is your system partition with fsck command or by viewing /etc/mtab.

    After successfully running the mount command (i.e. no error messages), proceed directly to step 5 below.

  4. After choosing the remount option, the menu comes up again. Select:

    root       Drop to root shell prompt
    
  5. Now enter one of the following commands to re-add your user to the admin group (for Ubuntu 11.10 and earlier):

    adduser <USERNAME> admin
    

    or to the sudo group (for Ubuntu 12.04 and later):

    adduser <USERNAME> sudo
    
  6. Reboot and you should be able to use sudo again.

3
  • 3
    If you don't see the "remount" menu, you can select "fsck" first, it will remount you filesystem to read/write. After that, you can add your user in root mode. Sep 19, 2013 at 22:59
  • 1
    This worked for me, except I had to mount the filesystem using the command mount -o remount,rw /.
    – Passuf
    Apr 7, 2016 at 16:53
  • This works perfectly. Also, it looks like a big security issue. I guess you should disable this feature on sensible machines? -- When in recovery mode, I am never able to reboot. I always have to use reboot -f. Jun 1, 2018 at 7:38
16

If root login is enabled on your system just drop terminal via Control+Alt+F1 without log in to X. Log in as root and then just add the desired user to admin group (for Ubuntu 11.10 and earlier):

adduser desired_user_name admin

For Ubuntu 12.04 and later, add the user to the sudo group:

adduser desired_user_name sudo

If you did not enable root login just choose recovery mode from Grub and then try root shell.

Root Shell

Mount file system as read-write:

mount -o rw,remount /

After that you can again add your desired user to the admin (or sudo) group.

1
  • But I can't access sudo from my user! Sep 6, 2018 at 15:32
7

I've tried various combinations after doing the same thing as the remount menu option seems not to be in 12.10. I have tried everything else in this post from root. The last was

umount -a
mount -o -w /<path> /

This resulted in the filesystem still being ro due to a setting in fstab to boot ro on filesystem error I think, with it stating it seemed to be ro after mount.

I finally managed it with

mount -o rw,remount /

Although I am not sure how this is different from the previous set of commands.

After applying this variation, adding a user to the admin (11.10 and ealrier) or sudo (12.04 and later) group is done the same way:

adduser username admin    # 11.10 and earlier
adduser username sudo     # 12.04 and later
3

Old question but happened to me too (Ubuntu 14.04).

I was unable to log into recovery mode and gain access to a root shell, as many answers here and elsewhere describe: the root shell access from GRUB seems to be password-protected.

So I solved the problem this way:

  1. boot on a live usb stick
  2. open a shell
  3. access the main HD Linux filesystem (you can find its mounting point in the address bar of the GUI file explorer, usually after CTRL-L). cd into it.
  4. edit the file etc/group (say with nano etc/group or anything else)
  5. find the "sudo" line. Should look like sudo:x:27:admin,bob,alice
  6. add yourself to the sudo line, comma separated

Of course, this implies that the file etc/sudoers still holds the line

%sudo   ALL=(ALL:ALL) ALL

meaning that all members of the group sudo have total control. First check that.

Worked uneventfully.

2

I made the same mistake adding my account to a group (forgot the -a). I had my system installed with the root login locked, and my account was the only one on the machine.

The accepted answer did not help me. While booting into recovery mode, all I got was an unhelpful message

Cannot open access to console, the root account is locked. See sulogin(8) man page for more details
Press ENTER to continue

After pressing ENTER, the system booted normally: no luck getting root access to fix the problem. I'm leaving this answer in case someone ends up in my shoes by this point. Use the following only if you cannot get to the recovery mode through the Grub menu.

A walkthrough to get the root shell:

  1. Boot into the Grub menu, and highlight (but don't press Enter on!) the normal (default, not a recovery!) boot option.
  2. Press e. Grub will display a command line editor with multiple lines, every one of which may look unfamiliar if not intimidating. Do not worry, any changes you make are not saved permanently.
  3. Find the line that reads linux ... ro .... This is the kernel command line. Replace the ro token with rw, to make the root filesystem read/write, and add another kernel command line parameter, init=/bin/sh. This instructs the kernel to execute sh instead of /sbin/init. In the end, the line should look like linux ... rw init=/bin/sh .... Note: You can get by even with the bare grub> prompt. I'll be happy to explain how, step by step, if all else fails for you; just leave a comment to this answer.
  4. After the change, press F10 to use the commands from the editor to boot the system (or read the instructions how to boot right below the editor window, if your Grub is compiled differently). You'll get the root shell prompt, since the init process runs as PID 1 with the root identity.
  5. Make the change you want to make, for instance usermod -a -Gadm,sudo YOURUSERID. Confirm with id -a YOURUSERID that you've got your sudo membership back. In case you get a "command not found" error, use /sbin/usermod and /bin/id.
  6. You cannot shutdown or reboot the system cleanly at this point. reboot, halt or poweroff won't work, and exit from the shell will lead to a kernel panic, as the PID 1 process is not expected to just exit. So the next two command you must issue are:

    sync
    exec /sbin/init
    

    sync just in case anything goes wrong, to save all changes to disk, and the exec to replace the shell with the real init (which can be systemd, upstart or System V init, but it's always called /sbin/init). The system will most likely continue to boot normally (no recovery mode).

  7. Login and reboot the system once, e. g. sudo reboot--you should have gotten your sudo privilege back. A reboot is recommended, as (although very rarely) init may be passed additional parameters during a normal boot, and that we did not do. In case the exec fails, simply reset the machine and let it boot normally. All modern journaling filesystems like ext4, xfs and btrfs recover themselves quickly (a few seconds for a journal check at most, if synced before the reset), and you'll be all set.

A bit of a background

There was a discussion on the Debian bug report about this very problem, and, as far as understand, this was decided a feature and not a bug, which I judge to have been rather a mistake. Having been in this business for 25 years, I cannot help but entirely disagree with the Michael Biebl's argument in message #31 in that thread:

Consider this: You have a laptop with a locked root account. By default the grub boot loader generates a boot entry for rescue mode. So, even if you lock down the bios to not allow booting from CD-Rom or USB, and you password protect grub, someone could easily get root access if you leave the laptop unattended for a moment.

The correct, IMO, if not general enough, objection was given in message #70 by Felipe Sateler:

For many (most?) computers, physical access means game lost security-wise, as you can just disassemble the box and get the hard drive.

This is true especially for the laptop, mentioned in the Michael's argument: if you leave it unattended for a moment, and someone is after your data, the laptop will be simply gone to never be seen again. And for any machine, not "many" or "most," even those bolted at 8 points into a rack, as soon as the attacker gets physical access to the machine, game is really over.

1
  • This is the solution that worked for me. Thank you for the detailed walk-through and discussion.
    – ali14
    May 1, 2023 at 16:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .