This content originally appeared on DEV Community and was authored by Sheersh Sinha
In Part 2 I explored the Linux file system and system logs. But very soon, I hit another roadblock:
Permission denied.
If you’ve ever worked on Linux, you’ve probably seen those dreaded words. At first, I thought it was just me typing the wrong command. But as I dug deeper, I realized it’s actually one of the most important safeguards in Linux — permissions and ownership.
And soon after that, I discovered another layer of control that keeps systems safe: package managers.
Users, Groups & Permissions — The Basics
- User (Owner) → The account that creates or owns the file. By default, the creator becomes the owner.
- Group → A collection of users with shared permissions (like a project team).
- Permissions → Define who can read (r), write (w), and execute (x) a file or directory.
Example from ls -l:
-rwxrw-r-- 1 sheersh devops 0 Sep 9 12:00 demo.txt
Breakdown:
- sheersh → owner (user)
- devops → group
- rwx → owner permissions (full access)
- rw- → group permissions (read/write)
- r– → others permissions (only read)
- This matches 764 in octal form.
My Hands-On Assignment
- I was asked to create a file /home/demo.txt and assign permissions so that:
- Owner → read, write, execute
- Group → read, write
- Others → read
Here’s what I did:
Step 1: Create the file
Step 2: Change permissions
Step 3: Verify
Output:
Perfect! The file now matches the required permissions.
Ownership in Action
Permissions don’t mean much if the wrong user owns the file. Ownership decides who can exercise those permissions.
Key Commands:
ls -l → shows file ownership (user & group).
chown newuser:newgroup file.txt → changes ownership.
chgrp groupname file.txt → changes group only.
This is crucial in DevOps because files often get created by root, but need to be used by app users or CI/CD pipelines.
Real-World Troubleshooting Story
The Scenario:
We deployed a simple shell script for rotating logs in /var/log/app/. The script worked perfectly in development. But in staging, developers kept reporting:
bash: ./logrotate.sh: Permission denied
At first, I thought it was missing execute permission (x). But after checking, I found something else.
The Investigation:
Check file permissions & ownership:
ls -l logrotate.sh
Output:
-rwxrwxr-- 1 root root 120 Sep 9 10:00 logrotate.sh
File was owned by root.
Developers were in the dev group, but since the file belonged to root:root, they had no control.
Even though permissions looked fine, the ownership was wrong.
The Solution:
Change ownership to the correct user and group:
sudo chown dev:dev logrotate.sh
Now:
-rwxrwxr-- 1 dev dev 120 Sep 9 10:00 logrotate.sh
Verify developer access:
su - dev
./logrotate.sh
Script runs fine.
Lesson Learned
- Permissions control what actions are allowed.
- Ownership controls who applies those permissions.
- A file owned by the wrong user/group can be just as problematic as missing x.
Package Managers — The Next Layer of Control
Once I got comfortable with users, groups, and permissions, I realized something:
“Permissions decide who can use files, but package managers decide who can install and update software on the system.”
On Linux, package managers are the tools that handle software installation, updates, and dependency management.
Common Package Managers
APT (Advanced Package Tool) → Used in Ubuntu/Debian.
Example:
sudo apt update
sudo apt install nginx
YUM/DNF → Used in CentOS, Fedora, RHEL.
Example:
sudo dnf install nginx
Zypper → Used in openSUSE.
Example:
sudo zypper install nginx
Pacman → Used in Arch Linux.
Example:
sudo pacman -S nginx
Package Managers + Permissions
- Only users with sudo/root privileges can install or update packages.
- This prevents ordinary users from accidentally (or intentionally) breaking the system.
- In DevOps, package managers are often automated via Ansible, Puppet, Dockerfiles, or CI/CD pipelines — but under the hood, it’s the same mechanism.
Troubleshooting Example
I once tried installing Nginx as a normal user:
apt install nginx
And got:
E: Could not open lock file /var/lib/dpkg/lock-frontend - Permission denied
The fix? Run with sudo:
sudo apt install nginx
Because installing software changes system-wide directories (like /usr/bin, /etc/nginx), Linux protects it by requiring elevated privileges.
Lesson: Just like ownership protects files, package managers + permissions protect the whole OS.
Key Takeaways from Part 3
- Users, groups, and permissions protect files.
- Ownership decides who controls those files.
- Package managers control software installation — only privileged users (or automated DevOps pipelines) can use them.
- Real-world troubleshooting often comes down to a mix of permissions, ownership, and package manager access.
What’s Next (Part 4)
Now that I’ve explored permissions, ownership, and package managers, the next step is to dive into the day-to-day toolkit of a Linux system administrator.
In Part 4, I’ll cover:
- Archiving and compressing files (tar, gzip, zip)
- Automating tasks with cronjobs
- Security basics and system administration
- Remote access with SSH & SCP
- Creating VMs on VirtualBox or equivalent
- Generating SSH Key Pairs for passwordless logins
This is where Linux starts feeling like a real DevOps playground.
Over to You
Have you ever faced a “Permission denied” while installing software or running a script? Was it due to permissions, ownership, or missing sudo? Share your experience below 
This content originally appeared on DEV Community and was authored by Sheersh Sinha