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 '16 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 '16 at 22:58

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 '19 at 14:21
  • 8
    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 '20 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 '20 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 '16 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 '16 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 '16 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 '20 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 '16 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 '16 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!
    – pabouk
    Sep 15 '20 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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