I installed Debian in VirtualBox (for various experiments which usually broke my system) and tried to launch the VirtualBox guest addon script. I logged in as root and tried to launch autorun.sh, but I got «Permission denied». ls -l shows that the script have an executable rights.

Sorry, that I can't copy the output -- VirtualBox absolutely have no use without the addon, as neither a shared directory, nor a shared clipboard works. But just for you to be sure, I copied the rights by hands:

#ls -l ./autorun.sh
-r-xr-xr-x 1 root root 6966 Mar 26 13:56 ./autorun.sh

At first I thought that it may be that the script executes something that gave the error. I tried to replace /bin/sh with something like #/pathtorealsh/sh -xv, but I got no output — it seems the script can't even be executed.

I have not even an idea what could cause it.

  • 2
    Looks like it should work. Try running it with bash explicitly: `bash -x ./autorun.sh". Maybe this will give an additional clue. – nobar Aug 24 '14 at 6:08
  • 2
    What is output of mount | grep noexec? – cuonglm Aug 24 '14 at 6:12
  • 1
    @Gnouc, you're right, the mounted «cdrom» have the noexec set. Probably you may post it as an answer; meanwhile I am trying to remount it with an exec rights. Hm, I didn't even knew that the filesystem could have such an attribute. – Hi-Angel Aug 24 '14 at 6:16
  • And if you try to run it via going sh ./autorun.sh what happens? – infixed Apr 5 '16 at 17:34

Maybe your file system is mounted with noexec option set, so you can not run any executable files. From mount documentation:


Do not allow direct execution of any binaries on the mounted filesystem. (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.)


mount | grep noexec

Then check if your file system is listed in output.

If yes, you can solve this problem, by re-mounting file system with exec option:

mount -o remount,exec filesystem
  • That didn't work for me. I had to unmount and then remount normally. Then it worked fine. – datakid Jun 23 '16 at 4:01
  • @datakid: What is your fs? – cuonglm Jun 23 '16 at 4:14
  • I am having this issue with debian 9, some files are permission denied if the scripts is running as root, but it identify as root... like a windows behavior, if i remove & the script worked! =[ – Luciano Andress Martini Dec 14 '17 at 13:07
  • I was getting a very strange message, which turned out to be because of noexec: "sh: 75: script.sh: Permission denied" – tmm1 Oct 3 '18 at 21:03

bash -x ./filename.filetype should work. It worked for me when I got permission denied as a root user.

  • No, as in the end the problem turned out to be the noexec mount option, this won't work, because there could be more files that have to be executed; i.e. the filename.filetype would gasp trying to execute other files from the same filesystem. You can easily check it with a simplified test: create a two line script which prints "hello", then just calls himself again, but do not set executable rights. If you execute it with -x, it would print "hello", but then the recursive call line would trigger an error. – Hi-Angel Apr 6 '16 at 4:33

My solution to this problem is to use source. I was on a storage volume of very important data. This volume is mounted as noexec. I have a simple shell script that is executable but got permission problem.

./fixsamplesheet.sh # this guy is executable
-bash: ./fixsamplesheet.sh: Permission denied

source fixsamplesheet.sh # worked fine

Only tested on my Ubuntu.

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.