Permissions and ownership without fear

Goal

Understand Linux permissions well enough to fix "permission denied" problems quickly and safely.

The Mental Model

Every file/folder has:

• an owner (user)
• a group
• permissions for user/group/others

-rw-r--r--  1 ubuntu  ubuntu  1234 Feb 13  file.txt
drwxr-x---  2 root    devops  4096 Feb 13  app/

Read it as:

• first char: file type (- file, d directory, l symlink)
• next 9 chars: permissions in 3 groups: user / group / others

Core Commands

Inspect

ls -l
ls -ld /path/to/dir
id
groups
whoami

Change permissions (chmod)

chmod u+rwx file
chmod g+rw file
chmod o-r file
chmod 640 file
chmod 750 /opt/app

Common safe patterns:

• 644 files: owner read/write, others read
• 755 directories: owner full, others can read + enter

Change owner/group (chown)

chown user:filegroup file
chown -R devops:devops /opt/app

Why Directories Feel "Different"

Directory permissions:

• r: list names (ls)
• x: enter directory (cd) and access files inside
• w: create/delete/rename inside (needs x to be useful)

Example: you can ls but cannot cd if x is missing.

Real DevOps Scenario: App cannot write logs

Symptoms:

• app crashes
• log shows Permission denied

Fix approach:

ls -ld /var/log/myapp
id
sudo chown -R myapp:myapp /var/log/myapp
sudo chmod 750 /var/log/myapp

Special Bits (know they exist)

You will see these in production:

• setuid (u+s): run as file owner
• setgid (g+s): new files inherit group
• sticky bit (+t): only owner can delete (common in /tmp)

chmod g+s /shared/teamdir
chmod +t /tmp

Exercises

Exercise A: Fix "permission denied"

1. Create a directory and remove execute permission:

mkdir -p lab/secure
chmod 600 lab/secure
cd lab/secure   # should fail

1. Fix it using chmod so you can enter.

Exercise B: Group collaboration

1. Create a shared folder and make group-inheritance work:

mkdir -p lab/shared
chmod 2770 lab/shared

1. Verify new files inherit the group.

Troubleshooting Checklist

When something fails:

• check permissions on the directory (not only the file)
• check which user the process runs as
• check group membership (log out/in sometimes required)
• avoid chmod 777 as a "fix" (it is almost always a security problem)

Next Step

Combine this with systemd + logs: most production issues are "wrong user" + "wrong directory permissions".