Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

I need to run something as sudo without a password, so I used visudo and added this to my sudoers file:

MYUSERNAME ALL = NOPASSWD: /path/to/my/program

Then I tried it out:

$ sudo /path/to/my/program
[sudo] password for MYUSERNAME: 

Why does it ask for a password? How can I run/use commands as root with a non-root user, without asking for a password?

share|improve this question
I generalized this somewhat so an older question could be merged into it –  Michael Mrozek Aug 17 '11 at 0:26

8 Answers 8

up vote 32 down vote accepted

You have another entry in the sudoers file which also matches your user. The NOPASSWD rule needs to be after that one in order for it to take precedence.

Having done that, sudo will prompt for a password normally for all commands except /path/to/my/program, which it will always let you run without asking for your password.

share|improve this answer
would this still work if the /path/to/my/program was a python script? –  sadmicrowave Mar 3 '14 at 20:29

In some distros, Manjaro in my case, there is a file that overrides the /etc/sudoers file

sudo cat /etc/sudoers.d/10-installer
  • the ONLY way to see it is under root privilegies, you cannot list this directory without it.

There you will find something like this:

youruser ALL=(ALL)

You can delete that file, and will use cfg in /etc/sudoers file


In the sudoers file you must put something like:





youruser ALL=(ALL) NOPASSWD: /path/to/executable

I hope this helps somebody :).

share|improve this answer

Complete Solution: The following steps will help you achieve the desired output:

  1. Create a new script file (replace with your desired script name):

    vim ~/

    The script will be created in the user’s home directory

  2. Add some commands that only a root or sudo user can execute like creating a folder at the root directory level:

    mkdir /abc

    Note: Don’t add sudo to these commands. Save and exit (using :wq!)

  3. Assign execute permissions to it using:

    sudo chmod u+x
  4. Make changes so that this script doesn’t require a password.

    1. Open the sudoers file:

      sudo visudo -f /etc/sudoers
    2. Add the following line at the end:

      ahmad ALL=(root) NOPASSWD: /home/ahmad/

      Replace ahmad with whatever your username is. Also make sure this is the last line. Save and exit.

  5. Now when running the command add sudo before it like:

    sudo ./

    This will run the commands inside the script file without asking for a password.

Follow the easy steps mentioned here

share|improve this answer
It would be better if you provided the relevant steps here and used the link as a backup for more detailed information. That way your answer retains possible value even if that link would not be valid anymore. –  Anthon Sep 14 '13 at 5:37
@Anthon Made the changes. Thanks! –  M. Ahmad Zafar Sep 14 '13 at 7:49
This advice is insecure. The sudo part of sudo chmod u+x is unnecessary as the user has (presumably) ownership over his/her home dir. Since the user can write to, you have effectively given a free root shell to that user. –  Lekensteyn Jul 19 '14 at 8:36

Verify that sudo is not aliased. Run like this

/usr/bin/sudo /path/to/my/program

For example a shell alias like this one:

alias sudo="sudo env PATH=$PATH"

may cause this behaviour.

share|improve this answer
You are right, my comment was out of order here, sorry for that. Nevertheless I'm intrigued - how do you expect aliasing to change the processing of sudoers by sudo. Or are you talking about redirecting sudo to something that always prints this error message to scoop passwords? That is unlikely the case here... –  peterph Jul 19 '14 at 8:18
I was having the same problem as the OP. It turned out to be caused by having alias sudo="sudo env PATH=$PATH" in my ~/.bashrc. Rather than just solving it for myself and blindly just going about my business, I submitted my answer as a possible solution for anyone else that comes along this thread. –  Sepero Jul 19 '14 at 22:50
That's fine, but when it is not obvious (which in this case isn't at least to some people) it is good to put an explanation into the answer to provide some context and prevent people from blindly using magic incantations. +2 (-(-1) + +1). :) –  peterph Jul 24 '14 at 22:45

This solved the issue for me (also tried some of the other answers, that might have helped):

The script I was calling was in /usr/bin, a directory that I don't have write permissions to (though I can usually read any files there). The script was chmodded +x (executable permisison), but it still didn't work. Moving this file to a path in my home directory, instead of /usr/bin, I was finally able to call it with sudo without entering a password.

Also something I doubted about (clarifying for future readers): You need to run your script as sudo. Type sudo when calling the script. Don't use sudo for the command inside your script that actually needs root (changing keyboard backlight in my case). Perhaps that also works, but you don't need to, and it seems like a better solution not to.

share|improve this answer
The second paragraph had the answer to my problem –  M. Ahmad Zafar Sep 13 '13 at 8:02
@MuhammadAhmadZafar Glad it helped! –  Luc Sep 13 '13 at 10:53
Actually using sudo inside of a script is perfectly fine provided you have the appropriate rights (set in sudoers) to run the command in question without a password. It makes things a bit more secure. –  peterph Jul 19 '14 at 8:21

If there are multiple matching entries in /etc/sudoers, sudo uses the last one. Therefore, if you can execute any command with a password prompt, and you want to be able to execute a particular command without a password prompt, you need the exception last.

myusername ALL = (ALL) ALL
myusername ALL = (root) NOPASSWD: /path/to/my/program

Note the use of (root), to allow the program to be run as root but not as other users. (Don't give more permissions than the minimum required unless you've thought out the implications.)

Note for readers who aren't running Ubuntu or who have changed the default sudo configuration (Ubuntu's sudo is ok by default): Running shell scripts with elevated privileges is risky, you need to start from a clean environment (once the shell has started, it's too late (see Allow setuid on shell scripts), so you need sudo to take care of that). Make sure that you have Defaults env_reset in /etc/sudoers or that this option is the compile-time default (sudo sudo -V | grep env should include Reset the environment to a default set of variables).

share|improve this answer
ex to go root from jhon with sudo su an no pass -----> john ALL=(ALL) NOPASSWD: /bin/su –  bortunac Jul 13 '14 at 14:05
@adrian If you want to allow arbitrary commands as root, make that john ALL=(ALL) NOPASSWD: all. There's no point in going via su. –  Gilles Jul 13 '14 at 14:08

When you execute your script you need to run it as sudo /path/to/my/script.

Edit: Based on your comment to another answer, you want to run this from an icon. You will need to create a .desktop file that executes your program with sudo, just like on the terminal.

You could also consider using gtk-sudo for a visual password prompt.

You should probably consider the idea that you shouldn't be running things as root and that changing the system farther down the road so that you don't need root permissions at all would be a better way to go.

share|improve this answer
Do not make shell scripts setuid. See Allow setuid on shell scripts. –  Gilles May 12 '11 at 11:38
I considered not even mentioning it because it's such a bad option. I just deleted it because I'm worried this asker might use the advice even with the warning that it was bad advice! –  Caleb May 12 '11 at 11:41

I think your syntax is wrong. At least I use the following which works for me:

myusername ALL=(ALL) NOPASSWD: /path/to/executable
share|improve this answer
The (ALL) part is optional, leaving it out has exactly the same effect. Having (root) would be better though, but its absence doesn't explain the problem. –  Gilles May 12 '11 at 11:39
+1 for sudo for this command and nothing else! No reason to break the entire system... –  Johan May 12 '11 at 11:40
@Johan: That was already in the question. –  Gilles May 12 '11 at 12:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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