Part of my #DevOpsFromZero series — documenting real KodeCloud tasks with the commands, the reasoning, the mistakes, and the principles behind every decision.
The Task
Grant executable permissions to
/tmp/xfusioncorp.shon App Server 3. Ensure all users have the capability to execute it.
Simple on the surface. Two layers deep in practice.
Understanding Linux File Permissions
When you run ls -l on a file, the output looks like this:
-rwxr-xr-- 1 root root 40 Jun 21 10:42 xfusioncorp.sh
The first ten characters are the permission string:
- First character: file type (
-for file,dfor directory) - Next 9 characters: three groups of three — permissions for owner, group, and others
Each group has three bits: r (read), w (write), x (execute).
“Others” means any user who is not the owner and not in the file’s group — effectively, everyone else on the system.
Why Does a Backup Script Need Execute Permission?
Imagine a recipe card sitting in a shared kitchen:
- Having the file is like knowing the card exists and where it is.
- Execute permission is like being allowed to ask the kitchen to cook from that card.
- Read permission is like being allowed to open the card and actually read the recipe.
For a compiled program, the kitchen may be able to follow the card without showing you the details. But for a script, Bash has to read the recipe line by line.
So ---x--x--x says “you may ask this to be cooked” — but if nobody is allowed to read the recipe, the attempt fails with Permission denied.
The Infrastructure
| Detail | Value |
|---|---|
| Hostname | stapp03 |
| SSH User | banner |
ssh banner@stapp03
Step-by-Step: What I Did
1. Check the Current Permissions
Before changing anything, check what’s already there:
ls -l /tmp/xfusioncorp.sh
2. Grant Execute Permission to All Users
The chmod command controls file permissions. The a flag means all users — owner, group, and others:
sudo chmod a+x /tmp/xfusioncorp.sh
Why a+x over +x? The a is explicit — it sets execute for all users regardless of the system’s umask. Explicit always beats implicit in ops work.
3. Verify
ls -l /tmp/xfusioncorp.sh
# ---x--x--x 1 root root 40 Jun 21 10:42 /tmp/xfusioncorp.sh
Execute is set for all three groups. ✅ Or so I thought.
The Mistake: Execute Without Read
Running the script as a regular user returned:
bash /tmp/xfusioncorp.sh
# bash: /tmp/xfusioncorp.sh: Permission denied
The permissions showed ---x--x--x — execute was set. But it still failed.
First instinct: maybe /tmp is mounted with noexec, which would block execution regardless of permission bits. Verified with:
mount | grep /tmp
# /dev/md2 on /tmp type ext4 (rw,relatime,idmapped)
No noexec flag. That theory was wrong.
Looked at the permissions again:
---x--x--x
Execute is set. Read is not. And xfusioncorp.sh is a bash script:
sudo cat /tmp/xfusioncorp.sh
#!/bin/bash
echo "Welcome To KodeKloud"
Bash can’t execute what it can’t read. It needs to open the file and interpret it line by line. Without read permission, the attempt fails — even with execute set.
The fix:
sudo chmod a+r /tmp/xfusioncorp.sh
Verified:
ls -l /tmp/xfusioncorp.sh
# -r-xr-xr-x 1 root root 40 Jun 21 11:16 /tmp/xfusioncorp.sh
Tested without sudo:
bash /tmp/xfusioncorp.sh
# Welcome To KodeKloud
Task complete. ✅
chmod vs noexec — Two Different Layers
This task revealed that execute permission operates at two levels:
| Layer | What It Controls | How to Check |
|---|---|---|
| File permissions | r, w, x bits on the file | ls -l |
| Mount options | noexec flag on the filesystem | `mount |
Both can block execution. Check the file first, then the mount if the file looks correct.
Does chmod Require a Service Reload?
No. Unlike sshd_config from Day 3, chmod writes directly to the filesystem. The kernel reads permission bits in real time — no service reload needed. The change is immediate.
Key Concepts Recap
| Concept | What It Means |
|---|---|
chmod a+x | Adds execute permission for all users explicitly |
chmod a+r | Adds read permission for all users |
r + x for scripts | Bash scripts need read to be interpreted; compiled binaries do not |
noexec mount option | Blocks execution of all files in a directory regardless of permission bits |
| `mount | grep |
ls -l | Displays file permissions, ownership, and metadata |
Closing Thought
Day 1: Specify intent explicitly — defaults will betray you. Day 2: No error doesn’t mean correct behaviour — always verify. Day 3: A configuration change is not real until the running service has loaded it. Day 4: Permission problems are layered — test the obvious explanation, then inspect the next layer.
When something fails, your first theory isn’t always right. Test it, rule it out, then go one layer deeper. That’s not just how you debug permissions — that’s how you debug everything.
Part of my #DevOpsFromZero series — documenting real KodeCloud tasks with the commands, the reasoning, the mistakes, and the principles behind every decision.