I have configured the /etc/sudoers file to include all files in the /etc/sudoers.d folder.

This seems to be working just fine. But every so often, the server forgets and the script cannot execute and I get this error: "no tty present and no askpass program specified"

A short while later WITHOUT ANY CHANGES (on my part) the server remembers and the scripts start working again.

Here you can see that the file I have allowed hasn't been modified in quite some time:

-rw-r--r-- 1 root root  67 Jul 27 20:34 admin-tools

Yet once a day or so and only for a short time (usually between 20 and 90 minutes), the script won't run and that error comes up. The script is triggered by a specific web page and runs as the www-data user every 10 minutes. When it fails, it will fail 2 to 9 times thus my time estimate.

Can anyone think of anything that could cause the server to forget what is in the sudoers.d folder like this?

If you need to know what is in my config file, here it is:

www-data ALL = NOPASSWD: [PATH TO MY SCRIPT]/file-copy.sh
  • Where is sudo storing the timestamp files? (sudo sudo -V |grep "timestamp dir" should do it)
    – Jeff Schaller
    Oct 11, 2021 at 19:40
  • Is there a command in the file-copy.sh that requires user input? E.g. something using sudo or a cp or mv that might request confirmation before overwriting a file? If that happens a tty is required which might explain the error you get. If possible share the contents of file-copy.sh
    – Bram
    Oct 12, 2021 at 13:27
  • Path to authentication timestamp dir: /run/sudo/ts Oct 12, 2021 at 17:12
  • Oh.... I hadn't considered that a confirmation could be causing the message. There are both "cp" and "mv" and even "rm" being used in the script. I would have ASSUMED that since the script is running with the sudo command that there wouldn't be any cases where it would prompt. Especially since I can run the same script from a different server (same script and everything) and it will do the copy/move/delete as expected. It only happens on this one server. I will dig deeper into that line though. Oct 12, 2021 at 17:15

1 Answer 1


Found the problem!

It turned out that the script was mounted on an NFS share and the route to that share changed randomly for some unknown reason.

I will narrow that down later, but because the permission's file in the /etc/sudoers.d folder only expected the script to exist based on one path, it would fail when it shifted to the other mapping.

So for now, I have the two possible paths included in the sudoers file.

Now... Off to figure out why the mapping is shifting!!!

You must log in to answer this question.

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