I messed up some permission issues by trying to change permissions on what I thought was just one directory but what turned out to be '/'. Now I am having sudo problems: In the console as a non-root user, when I try to login as root, I get:

sudo su
sudo: unable to stat /etc/sudoers: Permission denied
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

However I can get root terminal access to a directory by using the GUI Nemo file browser then right clicking and clicking 'open as root'. Most of the other posts with similar issues have had this issue be due to having incorrect file/directory permissions but I don't think this is the exact problem because when I do ls -ld /etc/ / ls -l /etc/sudoers I get:

drwxr-xr-x 157 root root 12288 Dec 15 15:36 /etc/
-rw-r--r-- 1 root root 755 Dec 15 15:36 /etc/sudoers

The update system also seems to not work.

I have tried:

apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall sudo

but this does not seem to really do anything productive

This is the contents of sudoers:

# This file MUST be edited with the 'visudo' command as root.
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
# See the man page for details on how to write a sudoers file.
Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d
  • 1
    How exactly did you try to change permissions? what are the permissions and ownership of / itself? Dec 16, 2017 at 3:02
  • 2
    And what is the output of ls -l /usr/bin/sudo ? It should be a setuid executable Dec 16, 2017 at 6:56

1 Answer 1


It is not a problem of the sudoers configuration file. You can check the configuration of your file using visudo -c. If you run against your file, you will check that it is parsed OK. I can't identify the problem with only the info you provided, but here are some things you can try.

  • Make sure that all the path /etc/sudoers is executable
  • Make sure that the / directory is with permissions 755(drwxr-xr-x)
  • Try to reconfigure the package with the default values running dpkg-reconfigure as root

Please provide info about the new permissions on /.

PS: I find weird is that your sudoers file has write permissions, remember you should only edit the sudoers file with visudo.

  • 6
    Thanks, it was a simple miss configuration of /, this did the trick: ors etc # ls -ld / drwx---r-x 23 root root 4096 Dec 12 20:09 / ors etc # chmod 755 / ors etc # ls -ld / drwxr-xr-x 23 root root 4096 Dec 12 20:09 / Dec 17, 2017 at 18:49
  • 1
    I just had this exact problem after a fresh installation of ArchLinux. Except GDM wouldn't show a UI. Running startx worked fine though. It took me 6 hours until I installed sudo to try something with the gdm user. That let me here and fixing those permissions fixed everything. Why gdm couldn't just tell me (or just not care at all like all the other services) is beyond me. Feb 25, 2018 at 1:37
  • 1
    Just had my highly tweaked Ubuntu 14.04 install almost succomb to the same symptom which in the end was due only to / having been set to exclusive access to my user account. It's quite surprising that one can mess up an install so easily by just changing permissions on the root directory, without being able to repair it immediately if you happen not to have a password set for root!!!
    – RJVB
    Apr 24, 2019 at 11:11

You must log in to answer this question.

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