Take the 2-minute tour ×

I have a script called foo.sh in my home folder.

When I navigate to this folder, and enter ./foo.sh, I get

-bash: ./foo.sh: Permission denied.

When I use sudo ./foo.sh, I get

sudo: foo.sh: command not found.

Why does this happen and how I can fix it?

share|improve this question
add comment

4 Answers

up vote 24 down vote accepted

Permission denied

In order to run a script the file must have an executable permission bit set.

In order to fully understand Linux file permissions you can study the documentation for the chmod command. chmod, an abbreviation of change mode, is the command that is used to change the permission settings of a file.

To read the chmod documentation for your local system , run man chmod or info chmod from the command line. Once read and understood you should be able to understand the output of running ...

ls -l foo.sh

... which will list the READ, WRITE and EXECUTE permissions for the file owner, the group owner and everyone else who is not the file owner or a member of the group to which the file belongs (that last permission group is sometimes referred to as "world" or "other")

Here's a summary of how to troubleshoot the Permission Denied error in your case.

$ ls -l foo.sh                    # Check file permissions of foo
-rw-r--r-- 1 rkielty users 0 2012-10-21 14:47 foo.sh 
 ^^^ | ^^^   ^^^^^^^ ^^^^^
  |  |  |       |       | 
Owner| World    |       |
     |          |    Name of
   Group        |     Group
             Name of 

Owner has read and write access rw but the - indicates that the executable permission is missing

The chmod command fixes that. (Group and other only have read permission set on the file, they cannot write to it or execute it)

$ chmod +x foo.sh               # The owner can set the executable permission on foo.sh
$ ls -l foo.sh                  # Now we see an x after the rw 
-rwxr-xr-x 1 rkielty users 0 2012-10-21 14:47 foo.sh
   ^  ^  ^

foo.sh is now executable as far as Linux is concerned.

Using sudo results in Command not found

When you run a command using sudo you are effectively running it as the superuser or root.

The reason that the root user is not finding your command is likely that the PATH environment variable for root does not include the directory where foo.sh is located. Hence the command is not found.

The PATH environment variable contains a list of directories which are searched for commands. Each user sets their own PATH variable according to their needs. To see what it is set to run

env | grep ^PATH

Here's some sample output of running the above env command first as an ordinary user and then as the root user using sudo

rkielty@rkielty-laptop:~$ env | grep ^PATH

rkielty@rkielty-laptop:~$ sudo env | grep ^PATH
[sudo] password for rkielty: 

Note that, although similar, in this case the directories contained in the PATH the non-privileged user (rkielty) and the super user are not the same.

The directory where foo.sh resides is not present in the PATH variable of the root user, hence the command not found error.

share|improve this answer
+1 for a very comprehensive answer. –  verybadalloc Jul 7 '13 at 17:59
Weird that sudo $PWD/temp.sh doesn't work neither, while sudo echo $PWD shows just what I waited for. (Mac) –  Nakilon Oct 1 '13 at 17:03
@Nakilon if you put that in a question with full details I should be able to troubleshoot it for you further. The issue is likely which shell (your first command shell or the shell launched by sudo) has evaluated $PWD –  Rob Kielty Oct 1 '13 at 21:33
@RobKielty, never mind. I don't remember the exact issue, but probably it was smth like not setting chmod -x for one command in script, and calling script via sudo generated not so understandable error msg. –  Nakilon Oct 3 '13 at 1:33
add comment
  1. Check that you have execute permission on the script. i.e. chmod +x foo.sh
  2. Check that the first line of that script is #!/bin/sh or some such.
  3. For sudo you are in the wrong directory. check with sudo pwd
share|improve this answer
add comment

Check for secure_path on sudo

[root@host ~]# sudo -V | grep 'Value to override'
Value to override user's $PATH with: /sbin:/bin:/usr/sbin:/usr/bin

If $PATH is being overridden use visudo and edit /etc/sudoers

share|improve this answer
add comment

Alternatively, you can try:

. foo.sh
share|improve this answer
That will slurp the script into the currently running shell, but doesn't help with sudo. –  ghoti Oct 21 '12 at 13:48
Yeah, sourcing is just an alternative to spawning a subshell to run the script. The side affect is that you end up with the variables assigned in foo.sh in the currently running shell and you don't get a return value (exit called in foo.sh exits the current shell) - which may or may not be something you want. Aside from that, I am unaware of differences otherwise. –  sampson-chen Oct 21 '12 at 14:03
Don't source scripts that are not designed to be sourced. The only merit of sourcing in this context is that the file merely has to be readable and on $PATH (or specified by absolute or relative name including a slash), rather than being executable too. –  Jonathan Leffler Oct 21 '12 at 14:42
@JonathanLeffler : could you please point me to some reading on this topic so I can understand the rationale? –  sampson-chen Oct 21 '12 at 14:44
I'm not sure whether there is anything to point you at. I learned it before there was much in the way of an internet by osmosis. Many scripts use exit if something goes wrong. If you source a script that exits, you have been undone. Scripts that are designed to be sourced don't use exit. You can see my recent answer to Is unsetting global variables defined in a script good practice? for another statement of some of the why's. –  Jonathan Leffler Oct 21 '12 at 14:57
show 1 more comment

Your Answer


