Linux File Permissions: Chown Pitfall Breaks Nginx Workers

Every production outage story that starts with 'well, someone accidentally deleted...' or 'the web server suddenly couldn't read its own config...' has file permissions somewhere near the root cause. Linux file permissions aren't just a theoretical concept buried in a sysadmin handbook — they're the first line of defence between a running application and chaos. Misconfigure them and you've either locked your own service out of its data, or handed a malicious actor a skeleton key to your entire system.

The permission system exists because Linux was designed from day one as a multi-user operating system. Unlike early personal computers where one person owned everything, Unix-descended systems needed a way to let dozens of users share the same machine without stepping on each other's work — or worse, each other's secrets. The read/write/execute model, combined with user/group/other ownership, solves that problem elegantly with just nine bits of information per file.

By the end of this article you'll be able to read any permission string at a glance, write chmod commands in both symbolic and octal notation without guessing, set up group-based access patterns for real team deployments, understand the dangerous-but-useful setuid/setgid/sticky bits, and diagnose permission-related errors before they become production incidents.

What Are Linux File Permissions?

Linux file permissions are a set of rules that determine who can read, write, or execute a file or directory. Every file and directory is owned by a user and a group. Permissions are defined for three categories: the file owner, the owning group, and everyone else (others). The permissions themselves are three bits: read (r), write (w), and execute (x). For directories, read lets you list contents, write lets you create/delete files inside, and execute lets you enter the directory.

The classic permission string looks like this: -rwxr-xr--. The first character is the file type (- for regular file, d for directory, l for symlink). The next nine characters are three triples: owner, group, others. The example above means the owner can read, write, and execute; group members can read and execute; everyone else can only read.

Chances are you've seen Permission denied when trying to access a file you know exists. That's the permission system doing its job — blocking access that wasn't explicitly granted. Understand these nine bits and you'll stop guessing why your app can't read its config.

#!/bin/bash
ls -la /var/log/auth.log
# Output example:
# -rw-r----- 1 root adm 12345 Mar 06 10:00 /var/log/auth.log
# Owner: root (rw-), Group: adm (r--), Others: --- (-)
# So only root can write; root and adm group members can read; nobody else can access

Changing Permissions with chmod (Symbolic and Octal)

chmod is your tool to modify permissions. Two modes: symbolic and octal. Symbolic uses letters: u (owner), g (group), o (others), a (all), combined with + (add), - (remove), = (set exactly). Example: chmod u+x script.sh adds execute for the owner. Octal mode uses a three-digit number (0-7) where each digit represents the sum of r=4, w=2, x=1. So 754 means owner=rwx (7), group=rx (5), others=r (4).

Which should you use? Symbolic is clearer for one-off changes like 'add execute for owner.' Octal is more reliable for scripts because it's unambiguous — you set the exact permissions regardless of the current state. Use octal in deployment pipelines.

A common mistake: chmod 777 to 'fix' a permission problem. Don't. It's lazy and dangerous. Always figure out the minimum permissions needed. For directories, note that execute is required to enter — so web apps often need 755 on public directories.

#!/bin/bash
# Symbolic: add execute for owner
chmod u+x deploy.sh

# Symbolic: remove write for group and others
chmod go-w config.yml

# Symbolic: set exactly rwx for owner, rx for group, nothing for others
chmod u=rwx,g=rx,o= config.yml

# Octal: set to 755 (rwxr-xr-x)
chmod 755 app.sh

# Octal: set to 644 (rw-r--r--)
chmod 644 index.html

# Recursive: change all files inside directory (be careful!)
chmod -R 755 /var/www/html

Changing Ownership with chown and chgrp

chown changes the owner and/or group of a file. chgrp changes only the group. The syntax: chown newowner:newgroup file — if you omit the group, the file's group stays unchanged; if you omit the owner, you must include a colon: :newgroup. Common scenario: after deploying code with a build tool (like Jenkins running as jenkins user), the files end up owned by jenkins:jenkins. But your web server runs as www-data. The server can't read the files. The fix: chown -R www-data:www-data /var/www/app or better, chown -R www-data:appgroup /var/www/app and use group permissions.

Important: only root can change file owners. However, the owner of a file can change its group to any group they belong to (with chgrp). So if an app runs as a non-root user but needs to share files with a team, the user can chgrp the files to a common group.

A tricky edge case: symbolic links. By default, chown and chgrp follow symlinks — they change the target, not the link itself. To change the link's ownership, use chown -h. This catches many admins off guard.

#!/bin/bash
# Change owner only
chown alice report.txt

# Change owner and group
chown alice:developers report.txt

# Change group only (alternatives)
chown :developers report.txt
chgrp developers report.txt

# Recursively change owner and group (common deployment)
chown -R www-data:www-data /var/www/app

# Change symlink ownership directly (not target)
chown -h bob link_to_report.txt

# Find files owned by a specific user and fix them
find /var/www -user jenkins -exec chown www-data: {} +

Special Modes: setuid, setgid, and the Sticky Bit

Beyond the basic nine bits, Linux provides three special permission modes that change how executables and directories behave:

• setuid (octal 4000 or u+s): When set on an executable, the process runs with the file owner's privileges, not the user who launched it. Classic example: /usr/bin/passwd — it's owned by root and has setuid, so normal users can change their own password (which writes to /etc/shadow that only root can write to).
• setgid (octal 2000 or g+s): On executables, the process runs with the group of the file. On directories, new files created inside inherit the directory's group, not the creating user's primary group — incredibly useful for shared team directories.
• Sticky bit (octal 1000 or o+t): On directories, only the owner of a file can delete or rename that file. Most commonly used on /tmp — everyone can write to /tmp, but only the file owner can remove what they created.

Setuid is powerful and dangerous. A bug in a setuid binary can give an attacker root privileges. That's why Linux ignores setuid on scripts (shebangs) for security reasons — but it still works on compiled binaries. Use setuid sparingly and audit it regularly.

Setgid on directories is a safe and effective pattern for collaborative workspaces. Example: chmod g+s /shared/project; chown :projectteam /shared/project.

#!/bin/bash
# View special bits in permission string
ls -l /usr/bin/passwd
# -rwsr-xr-x  — the s in owner's execute slot indicates setuid

# Set setuid on a compiled binary (must be root or owner)
chmod u+s mybinary
# Alternative octal: chmod 4755 mybinary

# Set setgid on a directory for team collaboration
chmod g+s /shared/teamdata
chown :developers /shared/teamdata
# Now new files get group 'developers' automatically

# Set sticky bit on a shared directory
chmod +t /shared/upload
# Only file owners can delete their files

# Check all setuid binaries on the system (security audit)
find / -type f -perm -4000 2>/dev/null

Real-World Patterns for Team Access

In production, it's rare to find a machine with only one user. You have deployment users, application users, monitoring agents, and human admins. The trick is to set up permissions so that every process gets exactly what it needs and nothing more.

Pattern 1: The Deploy User + Web Server User - Code is delivered by a deploy user (e.g., jenkins or deploy). The web server runs as www-data. - Best approach: make both users part of a common group like appgroup. Set files to 750 and directories to 755, owned by deploy:appgroup. The deploy user writes, the web server reads.

Pattern 2: Shared Project Directory - Team members need to edit files in /home/projects/foo. Each member has their own login. - Create a group fooproj, add all members. Set ownership nobody:fooproj (or any user, doesn't matter as long as group exists). Use setgid on the directory: chmod g+s /home/projects/foo; chmod 2775 /home/projects/foo. Now every file created inside automatically gets group fooproj and group-write permission.

Pattern 3: Locking Down Sensitive Config - Configuration files for a service (e.g., database credentials) should be readable only by the service user and root. Set chmod 600 or 640 if group needs read. Use chown root:servicegroup. - For log files, use 640 with owner being the service user and group being a monitoring group. Add the monitoring tool's user to that group.

These patterns avoid the 'chmod 777 everything' anti-pattern and keep your system secure.

#!/bin/bash
# Pattern: Deploy + Web Server
mkdir -p /var/www/app
chown deploy:www-data /var/www/app
chmod 2775 /var/www/app   # setgid ensures new files inherit group
# Files: deploy writes, www-data reads
find /var/www/app -type f -exec chmod 640 {} \;
find /var/www/app -type d -exec chmod 2755 {} \;

# Pattern: Shared project with setgid
mkdir -p /shared/project
chown :projectgroup /shared/project
chmod 2775 /shared/project
# New files created by any team member will be group-writable

# Pattern: Config lockdown
# Presume service runs as 'myservice', monitoring as 'monitor'
cp config.prod.yml /etc/myapp/
chown root:myservice /etc/myapp/config.prod.yml
chmod 640 /etc/myapp/config.prod.yml
usermod -aG myservice monitor  # add monitor user to group

Debugging Permission Errors in Practice

When you hit a permission error, don't guess. Follow a systematic approach:

1. Identify the process user: ps aux | grep service-name – that user is who needs access.
2. Check the file's permissions and ownership: ls -la /path, stat -c '%a %U %G' /path.
3. Check the path: A directory in the path may lack execute permission. Use namei -l /full/path.
4. Check groups: id $service_user — is the service user in the group that owns the file?
5. Check for ACLs: getfacl /path — ACLs override basic permissions.
6. Check for mount options: mount | grep /path — the filesystem may be mounted with noexec or nosuid.

Most permission bugs are simple: missing execute on a directory, wrong group membership, or an accidental chmod 000 from a script. But sometimes the problem is subtle — like a SELinux or AppArmor policy that denies even though file permissions look correct. Always check dmesg or ausearch for AVC denials if you're on an SELinux-enabled system.

#!/bin/bash
# Step 1: Find which user is running the process
SERVICE=$(systemctl show -p MainPID nginx.service | cut -d= -f2)
USER=$(ps -o user= -p $SERVICE)
echo "Process runs as: $USER"

# Step 2: Check file and path
FILE="/var/www/app/index.php"
ls -la "$FILE"
namei -l "$FILE"

# Step 3: Check user's groups
echo "User groups:"
id "$USER"

# Step 4: Check if ACLs are involved
getfacl "$FILE"

# Step 5: Check mount options for noexec
echo "Mount options for parent directory:"
stat -f -c '%T %O' "$FILE"