bash: ./script: Permission denied

Fix 'bash: ./script: Permission denied' on Linux

EP
Erropedia Team
📅 August 27, 2026 📅 Updated Sep 12, 2026 👁 20 views Linux & Unix Beginner
When you get 'Permission denied' running a script, it's usually the missing execute bit, not sudo. Check permissions with ls -l and chmod +x.

You just wrote a shell script, made it executable with chmod +x, and ran ./myscript.sh. Instead of running, you get bash: ./myscript.sh: Permission denied. This pops up on Ubuntu 22.04, Debian 11, CentOS 7—any Linux box really. The trigger is almost always the same: you're trying to execute a file that doesn't have the execute bit set for your user.

What's actually happening here is that the kernel checks the file's permission bits before it even thinks about bash or python or whatever interpreter you're using. If the execute bit is missing, the kernel refuses to load the file at all. That's why you see Permission denied and not a syntax error or "command not found."

The reason step 3 works is that chmod +x adds the execute bit, which directly tells the kernel "this file is allowed to run." And before you reach for sudo, stop. sudo runs the command as root, but if the file isn't executable, root can't run it either. You'll just get the same error with a different user prefix.

Root Cause

Every file on Linux has a set of permission bits: read (r), write (w), and execute (x). These are defined for three classes—owner, group, and others. When you create a new file, the default permissions often include read and write but not execute. Text editors like nano or vim create files with 644 by default (-rw-r--r--). That means the owner can read and write, but nobody can execute.

The kernel's execve() system call checks the execute bit on the file before passing it to the interpreter. If it's not there, you get EACCES (Permission denied). This is a security measure—you don't want random files to be executable by default.

The Fix

Here's the exact sequence to get your script running.

  1. Confirm the permissions. Run ls -l myscript.sh. Look at the first column. If you see -rw-r--r-- or -rw-rw-r--, there's no x in the owner position. That's your problem.
  2. Add the execute bit. Run chmod +x myscript.sh. This adds execute permission for all users—owner, group, and others. If you want only the owner to execute, use chmod u+x instead.
  3. Run the script again. ./myscript.sh should now work. If you get a different error like bash: ./myscript.sh: No such file or directory, check if the script has a shebang line (#!/bin/bash) at the top—that's a separate issue.
  4. If you're on a mounted filesystem. Sometimes the problem isn't the file itself but the mount options. Check with mount | grep /path/to/dir. If you see noexec in the options, that's blocking execution. You'll need to remount with mount -o remount,exec /path (requires root).

That last step is a trap. I've seen people waste an hour on chmod when the real culprit was a noexec mount on /tmp or a USB drive. If your script lives on /tmp or an external drive, always check the mount flags first.

Still Failing?

If chmod +x didn't fix it, check these things in order:

  • Are you on a filesystem that doesn't support execute? FAT32 and NTFS mounts often have noexec by default. Move the script to your home directory and try again.
  • Does the script have a shebang? If the first line isn't #!/bin/bash (or #!/usr/bin/env python3 for Python), the kernel doesn't know which interpreter to use. You'll sometimes get a different error, but it's worth confirming.
  • Is the file owned by someone else? If you're not the owner and you don't have execute permission for your group or others, chmod +x might fail (you can't chmod a file you don't own). Use sudo chmod +x—but only if you can't change ownership.
  • Check for ACLs. Extended ACLs can override the standard bits. Run getfacl myscript.sh. If there's a line like user:someuser:rwx that doesn't include you, that's the issue. You may need to setfacl to grant yourself execute.

The good news is this error is almost always the missing execute bit. It's a five-second fix once you know what to look for. The ls -l command is your friend—it tells you everything you need to know about permissions at a glance.

One last thing: if you're tempted to run bash myscript.sh instead of ./myscript.sh, that works around the issue because you're invoking the interpreter directly, bypassing the kernel's execute check. But that's a workaround, not a fix. You're masking the permission problem, and it'll bite you again when you try to call the script from another script or cron job. Better to fix the permission and use the ./ form.

Related Errors in Linux & Unix
Sudo Command Not Found on Fresh Linux Install? Fix It Now Fix 'Permission denied' on Linux when running shell scripts Fix SSH Permission Denied with Public Key Authentication SSH Permission Denied: Fix Public Key Authentication
bash permission denied chmod +x execute permission linux script not executable permission denied running script fix permission denied bash linux file permissions ls -l chmod 755 sudo doesn't fix permission denied

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.