Resolving ‘Permission Denied’ Errors for Bash Scripts on Ubuntu 22.04 LTS

Fix 'Permission denied' when running shell scripts on Ubuntu 22.04. Learn to correct file permissions, ownership, and common execution issues quickly.

When managing servers or developing applications on Ubuntu 22.04 LTS, encountering a "Permission denied" error while attempting to execute a shell script is a common hurdle. This issue typically indicates that the operating system is preventing your user account from running the script due to insufficient file permissions. Understanding the underlying causes and applying the correct resolution steps is crucial for maintaining a smooth and secure system operation. This guide will walk you through diagnosing and fixing such permission errors for bash scripts.

Symptom & Error Signature

When you try to run a shell script from your terminal, you will typically see one of the following error messages:

$ ./my_script.sh
bash: ./my_script.sh: Permission denied

Or, if the script is located in a directory not in your $PATH and you don't specify the full path:

$ my_script.sh
my_script.sh: command not found

(Note: while "command not found" is different, it can sometimes be confused with permission issues if the user expects it to run directly. Our focus is primarily on "Permission denied").

Root Cause Analysis

The "Permission denied" error when executing a script on a Linux system like Ubuntu 22.04 LTS primarily stems from a mismatch between the desired action (execution) and the permissions granted to the file for the user attempting the action. Here are the most common root causes:

1. Missing Execute Permission Bit: Linux file permissions are divided into read (r), write (w), and execute (x) for three categories of users: the file owner, the group owner, and others. For a script to be executable by the system directly (e.g., ./script.sh), it must have the execute permission bit set for the user or group attempting to run it. By default, new files created through text editors often only have read and write permissions (rw-).
2. Incorrect File Ownership or Group Membership: While less common for direct "Permission denied" errors (unless others permissions are missing), if a script is owned by a different user and its permissions only grant x to the owner, other users (even those in the same group, if group x is missing) will be denied. Similarly for group permissions.
3. noexec Mount Option: A critical security feature in Linux allows file systems to be mounted with a noexec option. This option explicitly prevents any file on that particular mount point from being executed, regardless of its individual file permissions. This is often used for partitions like /tmp or /var/www/uploads to prevent malicious scripts from running.
4. Incorrect Shebang Line: While not a direct "Permission denied" cause, an incorrect or missing shebang (#!) line at the beginning of a script can lead to command not found or bad interpreter errors. If the interpreter specified (e.g., /bin/bash) itself is not found or is not executable, it can indirectly lead to execution failures that might be misconstrued as general permission problems.

Step-by-Step Resolution

Follow these steps to diagnose and resolve the "Permission denied" error for your bash scripts.

1. Verify File Permissions

The first step is to inspect the current permissions of the script file using the ls -l command.

ls -l my_script.sh

Expected Output Example (without execute permission):

-rw-r--r-- 1 user user 1234 Sep  3 10:00 my_script.sh

In this example, -rw-r--r-- indicates:

• -: It's a regular file.
• rw-: The owner (user) has read and write permissions.
• r--: The group (user) has read permission.
• r--: Others have read permission.

Notice the absence of x (execute) in any of the permission sets. This is the most common reason for "Permission denied".

2. Grant Execute Permissions with chmod

Once you've confirmed that the execute permission bit is missing, you can grant it using the chmod command.

Always ensure you understand the implications of the permissions you are setting. Granting execute permissions to world-writable files (chmod 777) is a severe security risk and should be avoided in production environments.

a. Grant Execute Permission for the Owner (Common)

This is the most common fix, making the script executable only by its owner.

chmod u+x my_script.sh

After this, verify with ls -l:

ls -l my_script.sh
# Expected output: -rwxrw-r-- 1 user user 1234 Sep  3 10:00 my_script.sh

b. Grant Execute Permission for Owner, Group, and Others (755)

For scripts that need to be run by any user on the system (e.g., global utilities, web server scripts), chmod 755 is a standard and secure practice. This grants read/write/execute for the owner, and read/execute for the group and others.

chmod 755 my_script.sh

After this, verify with ls -l:

ls -l my_script.sh
# Expected output: -rwxr-xr-x 1 user user 1234 Sep  3 10:00 my_script.sh

c. Grant Execute Permission for the Group

If the script needs to be executable by users within a specific group, and others shouldn't have execute permissions:

chmod g+x my_script.sh
# or, for a common web server scenario, `chmod 775` (owner rwx, group rwx, others rx)
# chmod 775 my_script.sh

3. Verify the Shebang Line (If issue persists)

While not a direct "Permission denied" cause, an incorrect or missing shebang can lead to failures after granting execute permissions, presenting as "bad interpreter" or "command not found". If chmod didn't fully resolve the issue, check the first line of your script.

head -1 my_script.sh

Expected Output Example:

#!/bin/bash

Ensure the path to the interpreter (e.g., /bin/bash, /usr/bin/python3) is correct and that the interpreter itself exists and is executable. If you're unsure of the path, you can often find it using which bash or which python3.

4. Check File System Mount Options

If the script still refuses to run with "Permission denied" even after setting correct execute permissions, the underlying filesystem might be mounted with the noexec option.

a. Identify the Mount Point:

First, determine which filesystem your script resides on.

df -h my_script.sh

This will show you the filesystem and its mount point (e.g., /dev/sda1 mounted at /home).

b. Check Mount Options:

Then, use the mount command to inspect the options for that mount point.

mount | grep "/path/to/mountpoint"
# Example: mount | grep "/home"

Expected Output Example (with noexec):

/dev/sda1 on /home type ext4 (rw,noexec,relatime)

If you see noexec in the output, it means the filesystem explicitly disallows execution.

Modifying mount options, especially on critical system partitions, requires caution and root privileges. Incorrect changes can render your system unbootable or inaccessible.

c. Resolution for noexec:

• Move the script: The simplest solution is to move your script to a filesystem that is not mounted with noexec (e.g., /usr/local/bin, /opt, or a user's home directory if it's not noexec).
• Remount the filesystem: If it's absolutely necessary to execute scripts from that location, you can remount the filesystem without the noexec option.

  sudo mount -o remount,exec /path/to/mountpoint
  

  To make this change permanent, you'll need to edit /etc/fstab and remove noexec from the relevant line, then run sudo mount -a.

5. Verify Script Ownership and Group (If necessary)

In rare cases, if you're trying to execute a script that has specific owner/group permissions set, and you're not the owner or in the group, Permission denied can occur.

ls -l my_script.sh

If the owner or group isn't what you expect, and the permissions for others don't include execute (x), you might need to change ownership.

# Change owner to 'newuser'
sudo chown newuser:newgroup my_script.sh

# Or, if you just want to change the group
sudo chgrp newgroup my_script.sh

6. Executing the Script Correctly

Finally, ensure you're attempting to execute the script in a way that respects its permissions.

• Direct Execution (requires execute permission):

  ./my_script.sh
  

  This method requires the script to have the x (execute) permission set.

• Execution via Interpreter (does NOT require script execute permission):

  bash my_script.sh
  

  This method tells the bash interpreter to read and execute the script. In this case, only the bash interpreter needs to be executable, and the script itself only needs read (r) permission for the user. This can be a useful workaround if you cannot set execute permissions (e.g., on a noexec mount, though still not ideal).

By systematically following these steps, you should be able to diagnose and resolve the "Permission denied" error for your bash scripts on Ubuntu 22.04 LTS efficiently.