DEV Community

Cover image for 🔐 My DevOps Journey: Part 3 — Linux Users, Groups, Permissions & Package Managers
Sheersh Sinha
Sheersh Sinha

Posted on

🔐 My DevOps Journey: Part 3 — Linux Users, Groups, Permissions & Package Managers

#devops #linux #discuss #career

In Part 2 I explored the Linux file system and system logs. But very soon, I hit another roadblock:

Permission denied.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Output: 

-rwxrwxr-- 1 root root 120 Sep  9 10:00 logrotate.sh
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Now:

-rwxrwxr-- 1 dev dev 120 Sep  9 10:00 logrotate.sh
Enter fullscreen mode Exit fullscreen mode

Verify developer access: 

su - dev
./logrotate.sh
Enter fullscreen mode Exit fullscreen mode

✅ 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
Enter fullscreen mode Exit fullscreen mode

YUM/DNF → Used in CentOS, Fedora, RHEL.

Example:

sudo dnf install nginx
Enter fullscreen mode Exit fullscreen mode

Zypper → Used in openSUSE.

Example:

sudo zypper install nginx
Enter fullscreen mode Exit fullscreen mode

Pacman → Used in Arch Linux.

Example:

sudo pacman -S nginx
Enter fullscreen mode Exit fullscreen mode

🔐 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
Enter fullscreen mode Exit fullscreen mode

And got:

E: Could not open lock file /var/lib/dpkg/lock-frontend - Permission denied
Enter fullscreen mode Exit fullscreen mode

The fix? Run with sudo:

sudo apt install nginx
Enter fullscreen mode Exit fullscreen mode

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 👇

Top comments (1)

Collapse
 
prime_1 profile image
Roshan Sharma •

Great post! Really clear and practical, makes Linux permissions and package management much easier to grasp.