How to Fix “Permission Denied” in Bash

Running a simple shell script shouldn't feel like hacking into your own system. And yet, how many of us have hit this roadblock?

 ./deploy.sh: Permission denied

Whether you’re deploying to a fresh server, configuring CI pipelines, or onboarding new team members — permission issues in bash scripts are a common and frustrating blocker. This blog breaks down the causes, solutions, and real-world cases in a way that's practical, professional, and easy to follow.

🧩 The Real Problem: Why "Permission Denied" Happens

Let’s say you wrote a deploy.sh script:

#!/bin/bash
echo "Starting deployment..."

You run:

./deploy.sh

But get hit with:

 ./deploy.sh: Permission denied

🔍 Root Cause:

In Linux, files must explicitly be given execution rights — ownership alone isn’t enough. This is part of the system's core security design.

✅ Solution: Grant Executable Permission

Use chmod to make the script executable:

chmod +x deploy.sh

Then execute it:

./deploy.sh

Verify it with:

ls -l deploy.sh
# -rwxr-xr-x

This ensures the script is now executable for you, your group, and others.

🧠 What is 4-2-1 Rule ?

Linux uses a numeric system to set file permissions — and this is where 777, 755, and 644 come in.

Each digit represents permissions for:

• Owner (you)

• Group (your dev team maybe)

• Others (everyone else)

Each digit is made by adding:

• 4 for read

• 2 for write

• 1 for execute

So:

• 7 = 4 + 2 + 1 → read + write + execute

• 6 = 4 + 2 → read + write

• 5 = 4 + 1 → read + execute

Here’s how it breaks down:

💡 Pro Tip: Use chmod 755 script.sh for most executable scripts. Avoid 777 unless you're debugging — it's like giving every stranger the keys to your house.

Scenario 2: Script Fails with sudo

You must try:

sudo ./deploy.sh

And if you get:

sudo: ./deploy.sh: command not found

📌 Why This Happens:

When using sudo, your script is run in a new shell with a limited environment, possibly missing the current directory (./) from the PATH.

✅ Fixes for Sudo Issues:

1. Run the script explicitly via bash:

    sudo bash ./deploy.sh
   

2. Or use the absolute path:

    sudo /home/ubuntu/scripts/deploy.sh
   

3. Alternatively, update your $PATH, but that’s not ideal for quick scripts.

Use Case: CI/CD Script Failing in GitHub Actions or Jenkins

Here’s a real issue I faced:
In a Jenkins job, the pipeline failed with:

./setup.sh: Permission denied

After investigation, I realized Git had not preserved the executable permission.

✔️ Fix:

chmod +x setup.sh
git add setup.sh
git commit -m "Make setup.sh executable"
git push

💡 Tip: Git tracks file permissions for executables, but only if they change after being staged.

🔒 Understanding File Permissions (Briefly)

A quick primer on Linux permission structure:

-rwxr--r-- 1 user user 123 May 1 12:00 deploy.sh

This means:

• rwx — Owner can read, write, and execute

• r-- — Group can only read

• r-- — Others can only read

Use chmod, chown, and ls -l to manage and inspect permissions properly.

Bonus Tips for Bash Script Hygiene

1. Line endings: Scripts edited on Windows can break on Unix. Convert them:

    dos2unix script.sh
   

2. Correct interpreter: Always specify #!/bin/bash at the top — not /sh, especially if using Bash-specific syntax.

3. Avoid hidden directory issues: Running from /tmp, /mnt, or mounted folders may restrict execution.

🧠 Developer Wisdom

Permission errors may seem trivial, but in DevOps pipelines, production environments, and automation scripts, they can cause critical downtime. Building the habit of checking and granting permissions properly saves time and builds robust workflows.

TL;DR

• chmod +x yourscript.sh to fix basic permission errors

• Use sudo bash script.sh if sudo ./script.sh fails

• For Git-tracked scripts, ensure permissions are committed

• Validate with ls -l, and watch out for platform differences

✨ Final Thoughts

If you've struggled with “Permission denied” while trying to automate or deploy something — you're not alone. These little roadblocks are a rite of passage for DevOps and backend developers. The good news? Once you understand them, they’re easy to prevent and quick to resolve.

Sharing these learnings helps others skip the frustration, and builds a stronger developer community — which is what learning in public is all about.