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
  • Also, if it complains about not being able to remount /dev/whatever because it's write protected, you will need to make sure your remount command tells it to mount RO (e.g. mount -o remount,exec,ro) – tanantish Jan 19 '20 at 15:29

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
  • This worked perfectly for me when I edited a bash file in my Google Collab workspace and tried to run it. Thanks! – Pe Dro Feb 25 '20 at 11:53

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.

  • This doesn't solve the problem, you are still not able to run it as an executable. You are running bash as an executable which reads the information from the .sh file. – Dvij D.C. Feb 9 at 8:06
  • The mechanism is to execute the commands in the current shell, not using the *.sh as if it is executable. Agree, not the true solution. – Kemin Zhou Feb 9 at 21:08

Just mount the extensions ISO file as a "virtual" CD.

In the guest I run, I cd to the appropriate mount point, such as cd '/media/some_username/VBox_GAs_6.1.18' (name is dependent on version number)

Then run sudo sh ./VBoxLinuxAdditions.run

Restart the VM to make it work properly.


I had exactly the same problem installing Guest Additions on my copy of Debian Buster in Virtual Box.

As a work-around I simply copied the file VBoxLinuxEditions.run to the home directory of Debian and ran it from there using sudo. This not the solution as to why the script could not be run, but at least I was able to install Guest Additions.

Interestingly, I had no problem installing Guest Additions on my version of MX Linux which I have installed in Virtual Box, despite the fact that MX Linux is based on Debian.

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.