Bash: /Bin/Myscript: Permission Denied

bash: /bin/myscript: permission denied

You might have forgotten to give your scripts execution permissions:

chmod a+x /path/to/the/script

permission denied in running script

I am running the script in /tmp directory
as you see the result of ls is:

-rwxr-xr-x. 1 root root 1894 Feb  2 01:58 test.sh*

there is . after permissions which indicates that an SELinux security context applies to that file. so I copied test.sh in a directory else...

the problem was solved

ls -l /
drwxrwxrwt.   8 root root  1024 Feb  2 07:44 tmp/

I was in a directory where it might be a bad idea for executables to reside

These may work as well:

setenforce 0 | reboot

OR

echo 0 > /selinux/enforce | reboot

OR:

putting SELINUX=disabled in /etc/selinux/config and reboot (making sure to comment out anything in that file enabling selinux)

SELINUX status: sestatus

Shell script permission denied when conditional test

Parentheses run a subshell. Use brackets for comparisons:

if [ "$VAR1" = "Condition_1" ] ; then
    # do stuff
fi

Using mkdir in my bash script and getting permission denied

Scripts run as the user that runs them; the owner of the file and/or the directory it's in are irrelevant (except that the user needs read and execute permission to the file and directory). Binary executables can have their setuid bit set to make them always run as the file's owner. Old unixes allowed this for scripts as well but this caused a security hole, so setuid is ignored on scripts in modern unixes/Linuxes.

If you need to let regular users run a script as root, there are a couple of other ways to do this. One is to add the script to your /etc/sudoers file, so that users can use sudo to run it as root. WARNING: if you mess up your /etc/sudoers file, it can be hard to recover access to clean it up and get back to normal. Make a backup first, don't edit it with anything except visudo, and I recommend having a root shell open so if something goes wrong you'll have the root access you need to fix it without having to promote via sudo. The line you'll need to add will be something like this:

%everyone ALL=NOPASSWD: /path/to/script

If you want to make this automatic, so that users don't have to explicitly use sudo to run the script, you can start the script like this:

#!/bin/bash

if [[ $EUID -ne 0 ]];
then
    exec sudo "$BASH_SOURCE" "$@"
fi

EDIT: A simpler version occurred to me; rather than having the script re-run itself under sudo, just replace the symlink with a stub script like this:

#!/bin/bash
exec sudo /path/to/real/script "$@"

Note that with this option, the /etc/sudoers entry must refer to the real script's path, not that of the symlink. Also, if the script doesn't take arguments, you can leave the "$@" off. Or use it, it won't do any harm either.

If messing with /etc/sudoers sounds too scary, there's another option: you could "compile" the script with shc (which actually just makes a binary executable wrapper around it), and make that setuid root (chmod 4755 /path/to/compiled-script; chown root /path/to/compiled-script). Since it's in a binary wrapper, setuid will work.

getting permission to execute a bash script

File Permissions

First, make sure that you have the correct file permissions:

chmod +x /var/www/script_name #Gives the current user execute permissions

Executing Your Bash Script

In order to execute your bash script, the easiest option is to just simply call it (without any additional commands) by typing in the relative path to the script:

/var/www/script_name

There are other options for explicitly executing your script from the shell (in your case, use the bash shell to execute your script as a bash script). From TLDP documentation...

A script can also explicitly be executed by a given shell, but generally we only do this if we want to obtain special behavior, such as checking if the script works with another shell or printing traces for debugging:

rbash script_name.sh # Execute using the restricted bash shell
sh script_name.sh # Execute using the sh shell
bash -x script_name.sh # Execute using the bash shell

A Note on File Extensions: "Shebang" line > File extension

It is not an advised practice to use file extensions with your scripts, especially if you think your code may evolve beyond its current functionality.

Just in case you were wondering if the file extension may be your problem... it is not. It is important that you know that the file extension of a script isn't necessary at all. What matter is what you put in the "shebang" line:

To use the sh shell:

#!/bin/sh

To use the bash shell:

#!/bin/bash

It won't matter what file extension you use - the "shebang" line indicates what shell will be used to execute the script. You could save a script with the "shebang" of #!/bin/bash as script_name.py, but it would remain a bash script. If you attempt to execute it, ./script_name.py, it would be executed as a bash script.

As @Arjan mentioned in the comments, using file extensions for your script could lead to unnecessary complications if you decide to change the implementation of your project (i.e., a different shell / language):

I could decide later to shift my project to sh, python, perl, C, etc. Perhaps because I want to add functionality. Perhaps because I want to make it portable to a system without bash. It would be much more difficult if I used the .sh file extension, since then I'd need to change all my references to the script just because I changed its implementation.

permission denied on .gz files on linux

I want to check the location of the files.

You're shebang is incorrect, and several other small strings.

Here is your solution:

$ cat my_script.sh
#!/bin/bash
for item in $(ls ~/Desktop/hawkfiles17/NG*.fq.gz) ; do echo "$item" ; done

bash permission set to 777 but file execution still denied

Not sure what could be the reason but try invoking shell explicitly passing your
script as argument/command to the Shell like sh myscript.sh

---

Related Topics