Running a fresh install of Ubuntu server 16.04.1, I tried to add a file in /etc/sudoers.d/ to give one user root privileges for a certain command.

I added the file /etc/sudoers.d/servicetest with the following content:

servicetest ALL = (root) NOPASSWD: /bin/systemctl status *

The file /etc/sudoers is left untouched. It contains #includedir /etc/sudoers.d as the last line. This setup is unfortunately not working, when executing an appropriate command with sudo as the user servicetest, I am still asked for the password. However, if I move the content of the file /etc/sudoers.d/servicetest to the end of /etc/sudoers, everything is working as expected.

What could be the cause of this issue? How can I get files in /etc/sudoers.d/ working?

  • 2
    Maybe sudo doesn't accept files with the wrong permissions for security reason (just a guess). What are the /etc/sudoers.d/servicetest permissions?
    – IanC
    Oct 27, 2016 at 21:48
  • 3
    ^^^ +1 in fact the /etc/sudoers.d/README file says "all files in this directory should be mode 0440" Oct 27, 2016 at 22:58

5 Answers 5


In my CentOS 7, the system would not recognize the file if it had a dot in its name. For instance:

/etc/sudoers.d/user.perms                  # This file doesn't work
/etc/sudoers.d/userperms                   # This file does
  • 3
    I've run into the same issue on Ubuntu 18.04, removing the dot and ensuring permissions were set to 0440 and all is well.
    – Joe
    Dec 30, 2019 at 14:21
  • 9
    This is also the case on Ubuntu 20.04. Confusingly the OS adds a file "/etc/sudoers.d/99-snapd.conf" , so goodness knows how that has any affect on sudo!
    – David
    Jul 16, 2020 at 12:53
  • 1
    In Debian 8 (jessie), the system would not recognize the file if it had a dot in its name too.
    – MSDIsatis
    Sep 28, 2020 at 6:48

Apparently, the files that are included in the /etc/sudoers file must have 0440 permissions for security reasons. That way only root can edit the file and only the owner and members of the owner group can read it, making it less likely that the file will be used as an attempt to escalate privileges.

You can check the requirements on the included file on /etc/sudoers.d/README, but two other requirements are that the filename shouldn't start with a . (hidden files) or end with a ~ (convention for backup files).

Credits to @steeldriver for confirming the theory and finding the /etc/sudoers.d/README file!

  • 2
    And that's why one should use visudo -f /etc/sudoers.d/foo while editing files in /etc/sudoers.d.
    – muru
    Oct 28, 2016 at 4:26
  • 1
    Thanks! I did not consider the permission checks to be that harsh (especially since the README says should be and not must be). root:root 0440 and root:root 0640 doesn't make a difference for me, but it looks like it does for sudo ;)
    – Cybran
    Oct 28, 2016 at 5:57
  • 1
    Unfortunately, that was not the cause. I just tested it with corrected permissions (root:root 0440) and have the same problem as before.
    – Cybran
    Oct 28, 2016 at 12:06
  • sudo still need to be used in the cli for the new privileged user, otherwise, password will be asked to enter Jan 15, 2020 at 9:01

The problem was not, as answered by IanC, caused by the file permissions (sudo happily accepts a file owned by root:root 0644, as I can confirm now, although it should of course be root:root 0440 for security reasons!), but by a newline at the end of the file which was preceded by a windows-style line ending (\r\n).

sudo only accepts \n as line endings.

  • 1
    Nice that you solved your problem! Did you edit the file in windows? Was curious on how you ended up with the windows newline!
    – IanC
    Oct 28, 2016 at 15:55
  • Yes, I edited a template for the sudoers file in Windows and transferred it via ssh to the Ubuntu machine. And, of course, forgot to convert line endings before doing so. My own stupidity :(
    – Cybran
    Oct 28, 2016 at 16:04
  • You should always edit or at least check the file after editing (but before overwriting the original) using the visudo tool. Otherwise in certain situations you can lose root access after a wrong edit! Sep 15, 2020 at 14:36

I met the same issue with @Guillermo Prandi on Ubuntu 20.04.

If I create a file which has .conf extension, it does not work. But, if .conf is removed, it works well.

I doubt that 99-snapd.conf file works well.

As /etc/sudoers.d/README, it says, "that do not end in '~' or contain a '.' character."

@IanC wrote, "that the filename shouldn't start with a . (hidden files)", but I guess it may have been updated in the new version.


My sudoers.d directory seemed not working, so i have spend hour trying to figure out why. During that time i have tried:

  1. Checking if filename "sudoers.d/rpcuser" contains dot or tilda
  2. Setting perfect 0440 root root permissions on that file
  3. Viewing all hidden characters and replicating tabs and spaces in my "rpcuser ALL=(ALL) ALL" as in original "root ALL=(ALL) ALL" line
  4. Logging in and out with rpcuser after each modification
  5. Checking if it relates to some os system reserved status of user "rpcuser"

Nothing helped, at desperation i looked at "# includedir /etc/sudoers.d" line and it appedared i have added extra space between "#" and "include", so that was the problem.

You must log in to answer this question.

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