You just spent time writing an automation or deployment script. You try to execute it, and your terminal hits you with a familiar blocker:

bash: ./deploy.sh: Permission denied

Running sudo chmod 777 deploy.sh will bypass the error, but it creates a massive security hole by opening your file up to any user or process on the system.

Here is how to quickly read the Linux permission matrix and fix access issues safely.

Prerequisites: Setting up Your Sandbox

To practice managing system flags safely, create an isolated directory and an empty script file inside your terminal workspace:

mkdir chmod-blog-post && cd chmod-blog-post
touch deploy.sh

Step 1: Read the Terminal Matrix (ls -l)

Before changing any permissions, you need to audit the file's current state. Run the list command with the long-listing flag (-l):

ls -l deploy.sh

Try executing the file right after to observe the default system restrictions:

./deploy.sh

The 10 characters at the far left of the output (e.g., -rw-rw-r--) form a specific security matrix broken down into four distinct pieces:

• Character 1: Denotes the type of file. A hyphen (-) indicates a standard file, while a d represents a directory.

• Characters 2–4 (rw-): Represents User/Owner permissions. The creator can read and write to this file, but cannot execute it.

• Characters 5–7 (rw-): Represents Group permissions. Members of the owner's group can read and write.

• Characters 8–10 (r--): Represents Others/World permissions. Anyone else on the machine or network can only read the file.

Step 2: Modifying via the Symbolic Method (u+x)

The command used to change file access constraints is chmod (short for Change Mode). The quickest way to fix our permission issue is by using math symbols and target letters.

To resolve the execution failure, add (+) the execute (x) flag exclusively to the owner/user (u):

chmod u+x deploy.sh
ls -l deploy.sh

Using this notation gives you highly descriptive control. For instance, if you want to revoke write access from the world, you pass o-w. It functions like basic terminal arithmetic.

Step 3: Managing Security via Octal Notation (600)

While symbols are useful for quick fixes, production DevOps infrastructure relies on absolute numbers (Octal Notation). Each basic permission maps to an explicit numeric value:

• Read (r): 4

• Write (w): 2

• Execute (x): 1

• No Permission (-): 0

To compute a setting, sum the numbers for each role (User, Group, World) independently.

For example, when dealing with sensitive files like cloud server SSH private keys (id_rsa), security compliance dictates that only the owner should access it. Let's create an example key file and give the owner Read (4) + Write (2) = 6, while wiping out group and world access to 0:

touch id_rsa
chmod 600 id_rsa
ls -l id_rsa

The resulting -rw------- output shows that group and world access have been completely revoked. Now, only your specific user account can read or modify your private keys.

Step 4: Configuring Production Web Permissions (755)

What if you are configuring a web server or system application where everyone needs to read and execute the file, but only you should modify it?

Calculating the values:

• User (Full Access): Read (4) + Write (2) + Execute (1) = 7

• Group (Read/Execute): Read (4) + Write (0) + Execute (1) = 5

• World (Read/Execute): Read (4) + Write (0) + Execute (1) = 5

This gives us the classic industry-standard 755 configuration:

chmod 755 deploy.sh
ls -l deploy.sh

The script is now properly configured to run in production without creating unnecessary security vulnerabilities.

Practical DevOps Cheatsheet

Keep this reference guide bookmarked for your everyday deployment workflows:

Conclusion

Understanding chmod removes the guesswork from system debugging. By auditing permissions with ls -l and applying pinpoint modifications using symbolic or numeric modes, you can secure your environments efficiently without resorting to lazy security holes like 777.

This guide covers how to check, create, and merge local branches using the terminal.

Prerequisites

Git requires at least one commit in a repository before it can track or display branches. Run the following commands to create a project directory, initialize Git, and generate a root commit:

mkdir git-blog-post && cd git-blog-post
git init
git branch -m main
echo "Base project structure" > README.md
git add .
git commit -m "Initial commit"

With an established commit history, you can now begin managing branches.

Step 1: Check Your Active Branch

Before running modifications, verify which branch you are currently working on. Run the following command:

git branch

This command lists all local branches in the repository. The branch marked with an asterisk (*) is your active workspace.

Step 2: Create and Switch to a New Branch

To isolate your new workflow, create a separate branch. Run this command to create a branch named feature-test and switch to it immediately:

git checkout -b feature-test

The -b flag is an operational shortcut. It combines two separate steps: creating the new branch (git branch feature-test) and changing your active workspace to it (git checkout feature-test).

Step 3: Stage and Commit Changes

Create a file to simulate a project modification, stage it, and commit it to your active branch history:

echo "This is a new feature test." > sample.txt
git add sample.txt
git commit -m "Testing a new feature"

This commit is now recorded exclusively on the feature-test branch history. Your main branch remains unchanged.

Step 4: Merge Changes Back to Main

Once your feature changes are ready, integrate them back into your primary production branch. First, switch back to your main branch:

git checkout main

Now, pull the history from feature-test into main using the merge command:

git merge feature-test

Because main had no conflicting changes, Git performs a fast-forward merge, directly updating the main branch pointer to match the latest commit from your feature branch.

Conclusion

Isolating your work in branches keeps your primary codebase stable and organizes your development history. With these four foundational commands, you can safely manage local development workflows directly from the terminal.