13.3 Diagnose and Correct File Permission Problems

13.3 Diagnose and Correct File Permission Problems

Quick Answer: Reproduce the failure as the right user, inspect with ls -l, ls -ld, and namei -l, fix with chmod / chown / chgrp, then re-test. Parent directories need execute (search) to reach files. Prefer least privilege over chmod -R 777.

Official skill

Under Create and configure file systems, Red Hat expects you to diagnose and correct file permission problems. Exam-style prompts:

• “User alice cannot write to /data/shared/reports; fix permissions so her group can write.”
• “The application user cannot traverse /srv/app/config; correct directory permissions.”
• “Only bob should own /home/bob/bin/tool and it must be executable by the owner.”

Related skills elsewhere: default umask, ACLs in depth, and SELinux contexts. This section focuses on diagnosis and DAC fixes (owner/group/mode) you apply under time pressure.

How Linux decides access (quick model)

For a process with a given UID/GIDs:

1. If UID matches file owner, use owner rwx triad.
2. Else if any process GID matches file group, use group triad.
3. Else use other triad.
4. ACLs (if present) can add per-user/per-group entries—check with getfacl when ls -l shows a +.
5. SELinux may still deny after DAC allows—different layer.

Directories interpret bits differently:

A file mode rw-rw-rw- is useless if a parent is d--------- or lacks x for that user.

Diagnostic toolkit

ls -l and ls -ld

ls -l /data/shared/reports/file.txt
ls -ld /data /data/shared /data/shared/reports
ls -la /data/shared/reports

Sample line:

-rw-r-----. 1 root appgrp 4096 Aug 5 10:00 file.txt
drwxr-x---. 2 root appgrp 4096 Aug 5 10:00 reports

namei — the exam superpower for path issues

namei -l /data/shared/reports/file.txt

Walks each component with its owner/mode so you see which level denies traverse or read. Fix the component that fails—often /data/shared missing group x, not the leaf file.

Identity of the actor

id
id alice
groups alice
sudo -u alice id

You cannot fix “alice cannot write” while only testing as root. After changes:

sudo -u alice test -w /data/shared/reports && echo writable
sudo -u alice touch /data/shared/reports/t
sudo -u alice cat /data/shared/reports/file.txt

ACLs when you see +

getfacl /data/shared/reports
# setfacl -m u:alice:rwx /data/shared/reports   # when task wants ACL semantics

If the task only mentions owner/group/mode, stick to chmod/chown. Use ACLs when group ownership alone cannot express the requirement.

Hidden culprits checklist

lsattr /path/to/file    # look for immutable i
sudo ausearch -m avc -ts recent   # SELinux hints if DAC is fine

Correcting problems: chmod

Symbolic

chmod u+x script.sh
chmod g+w file.txt
chmod o-r file.txt
chmod u=rwx,g=rx,o= dir
chmod a+X dir           # add x only if file is dir or already executable—useful carefully

Octal

chmod 755 /usr/local/bin/tool    # rwxr-xr-x
chmod 640 /data/app.conf         # rw-r-----
chmod 770 /data/shared           # rwxrwx---
chmod 600 /home/bob/.ssh/id_rsa

Recursion

chmod -R g+w /data/shared

Dangerous if it makes every file executable or world-writable. Prefer:

find /data/shared -type d -exec chmod 2775 {} \;   # example policy
find /data/shared -type f -exec chmod 664 {} \;

Only when the task needs a whole tree policy.

Special bits (recognition)

chmod 2775 /data/shared    # setgid directory for group collaboration
chmod 1777 /data/tmp

Shared project directories often need setgid + group write + group execute so new files stay in appgrp.

Correcting problems: chown and chgrp

sudo chown alice file.txt
sudo chown alice:appgrp file.txt
sudo chown -R alice:alice /home/alice/project
sudo chgrp appgrp /data/shared
sudo chgrp -R appgrp /data/shared

Ownership mistakes:

• Service runs as nginx but files owned root:root mode 600 → web cannot read.
• User’s home owned by root after botched copy → login quirks; restore chown -R user:user.

You generally need root for chown to another user.

Worked diagnosis scenarios

Scenario A — Group write on shared directory

Problem: alice and bob in group staff cannot create files in /data/team.

id alice
ls -ld /data/team
# drwxr-xr-x root root  → group has no write
sudo chgrp staff /data/team
sudo chmod 2775 /data/team
sudo -u alice touch /data/team/a

Scenario B — Parent path blocks access

Problem: ls -l /srv/app/config/app.conf as root shows -rw-r--r-- app app, but user app gets permission denied reading via the app path.

namei -l /srv/app/config/app.conf
# /srv may be drwx------ root root
sudo chmod 755 /srv
sudo chmod 755 /srv/app
sudo -u app cat /srv/app/config/app.conf

Fix search bits on parents; do not chmod 777 the config file only.

Scenario C — Script not executable

ls -l /usr/local/bin/backup.sh
# -rw-r--r--
sudo chmod 755 /usr/local/bin/backup.sh
# or chmod u+x

Scenario D — Wrong owner after unpack

sudo tar -C /opt -xf app.tar
ls -ld /opt/myapp
sudo chown -R myapp:myapp /opt/myapp

Scenario E — World-readable secret

Problem: Task says private key must not be group/other readable.

ls -l /home/bob/.ssh/id_rsa
sudo chmod 600 /home/bob/.ssh/id_rsa
sudo chown bob:bob /home/bob/.ssh/id_rsa

SSH itself rejects overly open keys—permissions are functional, not cosmetic.

Systematic exam procedure

1. Identify user who must succeed (id, task text).
2. Reproduce with sudo -u user ....
3. Inspect leaf ls -l and path namei -l / ls -ld on each directory.
4. Decide: owner, group, mode, ACL, or other layer (SELinux/attr).
5. Apply minimal chown/chgrp/chmod (setgid share dirs when collaboration required).
6. Re-test as the user.
7. Confirm you did not break other requirements (e.g., still not world-writable if forbidden).

chmod 777: when it is wrong

chmod -R 777 /var/www “fixes” many denials and fails real exams that expect controlled group access, breaks security assumptions, and may still fail under SELinux. Use 775/770 + correct group, or ACLs, matching the prompt.

Tie-in to file system creation

New ext4/XFS mounts are often owned root:root with 755. After mount, application tasks may require:

sudo mkdir -p /data/project
sudo chown alice:dev /data/project
sudo chmod 2775 /data/project

Creating the FS (13.1) and extending LVs (13.2) do not replace permission configuration for multi-user data directories.

Common traps

1. Fixing only the file when a parent lacks x.
2. Testing only as root — root bypasses DAC for most file modes.
3. Wrong group membership — user not in the group you chmod’d for; use usermod -aG / gpasswd when the task allows group changes (users/groups objectives).
4. Forgetting re-login after group add so new GID is active—or use sg/newgrp in shell tests.
5. chmod without chown when ownership is the real bug.
6. Recursive 777 as a reflex.
7. Ignoring + ACL lines when basic ugo cannot explain access.
8. Treating SELinux denial as chmod problem forever—if modes are correct, pivot to contexts.
9. Making directories 644 — directories normally need x to be usable.
10. Breaking root-owned service files with careless chown -R on /etc.

Section checkpoint

You should reproduce access as the affected user, read modes and ownership with ls -l/ls -ld, walk components with namei -l, correct issues with targeted chmod and chown/chgrp (including setgid shared directories when appropriate), re-test without relying on root success alone, and escalate to ACL or SELinux tools only when DAC looks correct. That is the EX200 standard for diagnosing and correcting file permission problems on RHEL 10.