What does permission denied mean when running a shell script?

The message has three distinct causes that look nearly identical, and knowing which one you have saves a great deal of guessing.

The first and most common is that the file is not marked executable. Creating a script with an editor produces an ordinary file, and the system refuses to run it directly. Adding the execute permission fixes it. Listing the file permissions shows whether the execute bit is set for the user you are actually running as, which is worth checking rather than assuming.

The second is that the file is executable but the interpreter named on the first line is wrong. The shebang tells the kernel what to run the file with, and if that path does not exist the resulting error is confusing because it appears to blame the script rather than the missing interpreter. This happens frequently with scripts written on one system and run on another where the interpreter lives elsewhere. Referencing the interpreter through the environment lookup rather than a hardcoded path is more portable.

The third is that the filesystem itself forbids execution. Some mounts, notably removable media and certain temporary or network locations, are mounted with execution disabled as a security measure. The permissions on the file look correct and it still will not run. Moving the script somewhere ordinary confirms this quickly.

A related case worth mentioning is a script saved with Windows line endings. The carriage return becomes part of the interpreter path, which then does not exist, producing an error naming an interpreter that looks correct because the invisible character does not print. Converting line endings resolves it.

Running the script by passing it to an interpreter explicitly sidesteps the execute bit entirely, which is a useful way to distinguish a permission problem from a content problem in one test.