18

I entered chmod -R 777 /usr/bin and now sudo is not working.

It says sudo must be setuid root.

Some advice online said to run chown root:root /usr/bin/sudo chmod 4755 /usr/bin/sudo.

On entering chown root:root /usr/bin/sudo it shows an opened in readonly mode error.

3
  • 1
    You must be root to run those commands
    – Mat
    Apr 27, 2012 at 13:44
  • Manoj Kumar: Did the pkexec method in my answer (which you've marked as accepted) solve this problem for you? I've become convinced that, as Damien Roche and Oli have commented, this method does not actually work after a sudo chmod -R 777 /usr/bin command has successfully completed. Like sudo, pkexec has to be setuid root to work. (I'm not sure why, as it uses the polkit service, but it does.) However, I think I've heard other people say this has worked for them, which is curious! Had you pressed Ctrl+C before the 777 chmod command finished? Aug 23, 2014 at 1:10
  • Hello. This method actually has worked for me after I accidentally successfully ran sudo chmod -R 777 /usr/bin, but only after logging into the root account.
    – iHowell
    Mar 14, 2017 at 6:00

6 Answers 6

11

Accepted status notwithstanding, I'm now convinced this answer is wrong. (I hope to improve it soon, after consulting with the OP about the accept.) I think I recall others saying this worked, but I believe their problems were at least slightly different. The method described herein remains valuable for some situations where chmod -R 777 /usr/bin is interrupted with Ctrl+C or otherwise does not complete. But once it does, pkexec is un-setuid'd too and it won't work any better than sudo, as Damien Roche and Oli have rightly commented.

On an Ubuntu desktop system, PolicyKit is installed, so pkexec can be used to repair a broken sudo executable or sudoers file. You do not need to boot into recovery mode and you do not need to boot from a live CD. You don't even need to reboot.

In this case, run the following commands:

pkexec chown root:root /usr/bin/sudo
pkexec chmod 4755 /usr/bin/sudo

See this question for more information.

6
  • 10
    pkexec must be setuid root! What a nightmare!
    – Damien
    Aug 23, 2013 at 14:26
  • 1
    As Damien points out, the problem with this approach is pkexec is in exactly the same predicament as sudo. It's normally setuid and lives in /usr/bin. I've tested it and this just doesn't work after chmod -R 777 /usr/bin.
    – Oli
    Jul 3, 2014 at 16:39
  • @DamienRoche, Oli: I'm sorry for not fixing this way sooner! You're both right. I'm unsure why pkexec has to be setuid root to work (doesn't it work through the polkit daemon like other non-setuid processes?), but it does need that. I've commented on the question to see if the OP (who accepted this) can shed light on what, if anything, is right or helpful about this answer. And I've added a temporary banner to the top of this post so I don't further mislead. If this answer continues to exist, its improved form will probably incorporate some info currently in that banner. Aug 23, 2014 at 1:34
  • You could just use su, which is located under /bin
    – THC
    Jul 11, 2017 at 14:46
  • @FliiFe Fixing the permissions (or ownership) of files in /usr/bin requires root privileges, but you cannot su to root on most Ubuntu systems because root logins are disabled by default. Unlike sudo and pkexec, when you use su to get a root shell or to run a command as root, you have to provide root's password, not your own. But root has no password by default in Ubuntu (which is to say that password-based authentication for root will always fail, not that entering a blank password would work). See RootSudo for details. Jul 11, 2017 at 14:53
4

Even when running from the live CD / Pendrive, you must prefix your chmod command with sudo. So your steps will be like the following:

  1. boot from a live CD / Pendrive
  2. check whether your disk was already automounted (and where to). If not, mount it (see below)
  3. use sudo chmod 0755 <path> to adjust the permissions

How to figure out where your disk is mounted: from a terminal window, run mount (without arguments). This will list up all mounted devices. Check for the type listed -- you can skip everything not using a "real file system" (your disk probably uses either ext3 or ext4 -- you can for sure skip things like proc, sysfs and the like). If something sounds promising (looking like /dev/sda1 on /media/sda1 type ext3), check its contents using ls /media/sda1 to see if it's that.

If it is not mounted, you can check with the /dev entries where the disk could be (using ls /dev/ |grep '/dev/sd to check for available devices; your disk should look like /dev/sdaX, /dev/sdbX or the like -- with X being a number). Compare this with the list of mounted devices. If it's not there, try to mount it and check its contents (as shown above). To mount it, first create a mountpoint, e.g. sudo mkdir /mnt/mydisk, then try to mount the device using mount /dev/sda1 /mnt/mydisk and check its contents using ls /mnt/mydisk.

Once you get the right disk there, you can go to change the permissions back on your usr dir: sudo chmod 0755 /mnt/mydisk/usr.

Now you still might be in trouble if you originally ran the chmod command recursively, using the -R parameter. In that case you can either try to fix each entry manually -- or you can go straight for a fresh install...

2
  • I tried to create mount point, but I got an error which read mount point mnt/mydisk does not exists is mydisk to be replaced with some thing and just for the record i wrote mount /dev/sda /mnt/mydisk from root@Ubuntu:/dev#
    – vin
    Jul 9, 2012 at 15:30
  • You did a) create that mount point (directory) before issuing the mount command (as described) and b) took care for the leading slash as well? Try mkdir -p /mnt/mydisk && mount /dev/sda1 /mnt/mydisk (I don't think you have no partitions on /dev/sda, so you must have missed the partition number as well. Make sure you specify the correct device (or mount will fail).
    – Izzy
    Jul 9, 2012 at 16:05
1

I think Mat's correct, you must be root to add the bit to /usr/bin, but of course sudo is broken. If you have a root password you can use that to logon as root and then fix the permissions with the above command. If you don't, however, (and I don't either) it would probably be best to:

  • boot from a Linux live CD
  • become root there
  • mount the partition with the above system
  • then straighten out the permissions on that file system using a terminal.

Root is always user number 0 so root on any system can make changes allowed to root on other file systems.

1

I don't have much knowledge. But these steps solved my problem even without restarting my machine. Follow these steps:

su root
<enter root password>
cd /usr
chmod -R 755 *
3
  • 1
    You are missing at least a "cd" command. If you do it like this you are doing the "chmod" on the home dir for root. That will make things worse.
    – Rinzwind
    Mar 27, 2015 at 9:01
  • thaks... edited my answer... i was in /usr folder
    – Manu Mohan
    Mar 27, 2015 at 11:09
  • 2
    This only works, if a password is set for root, which is not the default configuration of Ubuntu. Nov 10, 2015 at 12:13
1

In an attempt to set permissions for my local scripts, I broke the sudo permission and changed ownership, by mistake. I was able to change back the ownership of sudo to root by doing the following:

Step 1: Switch to ubuntu recovery mode. If you are unaware of the process, you can refer an answer here: https://askubuntu.com/a/172346/223901

Step 2: Once in recovery mode, select root - Drop to root shell prompt

Step 3: Do the following commands

mount -o remount,rw /
chown root:root /usr/bin/sudo
chmod 4755 /usr/bin/sudo
reboot

Wait for your system to boot normally and you will see the ownership of sudo back to root.

0

ramsudharsan is quite right ...
In my case Ubuntu 20.04

Step 1: Switch to ubuntu recovery mode. If you are unaware of the process, you can refer an answer here: https://askubuntu.com/a/172346/223901
My machine → reboot and [Esc] after splash screen. A little tricky, but after a few attemps GRUB show up ...

Step 2: Once in recovery mode, select root - Drop to root shell prompt

Step 3: Do the following commands

# mount -o remount,rw / → on my machine works without! 

chown root:root /usr/bin/sudo 

chmod 4755 /usr/bin/sudo 

reboot

Step 4: After normal reboot/system start

sudo chmod 4755 /usr/bin/[files from the list below]

also the other files (no complet list):
/usr/bin:

  • -rwsr-xr-x 1 root root 84K Jul 15 2021 chfn*
  • -rwsr-xr-x 1 root root 52K Jul 15 2021 chsh*
  • -rwsr-xr-x 1 root root 39K Mär 7 2020 fusermount*
  • -rwsr-xr-x 1 root root 87K Jul 15 2021 gpasswd*
  • -rwsr-xr-x 1 root root 310K Okt 11 2019 info*
  • -rwsr-xr-x 1 root root 55K Jul 21 2020 mount*
  • -rwsr-xr-x 1 root root 44K Jul 15 2021 newgrp*
  • -rwsr-xr-x 1 root root 67K Jul 15 2021 passwd*
  • -rwsr-xr-x 1 root root 31K Mai 26 2021 pkexec*
  • -rwsr-xr-x 1 root root 67K Jul 21 2020 su*
  • -rwsr-xr-x 1 root root 163K Jan 19 2021 sudo*
  • -rwsr-xr-x 1 root root 39K Jul 21 2020 umount*
  • -rwsr-xr-x 1 root root 26K Jan 11 2021 xdg-open*
  • -rwsr-xr-x 1 root root 30 Nov 12 2017 xlinks2*

/usr/sbin/:
-rwsr-xr-x 1 root dip 386K Jul 23 2020 pppd

/usr/lib/policykit-1/:
-rwsr-xr-x 1 root root 23K Mai 26 2021 polkit-agent-helper-1

Thanks to the recovery mode, there is no need for a reinstallation! ...

You must log in to answer this question.

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