Study guide
13.3 Diagnose and Correct File Permission Problems
Red Hat Certified System Administrator RHCSA
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy
2 Essential Tools: Shell, Redirection & Text Analysis
2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis
3 Essential Tools: Remote Access, Users & Text Editing
3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files
4 Essential Tools: Files, Links & Archives
4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2
5 Essential Tools: Permissions & System Documentation
5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc
6 Manage Software: RPM and Flatpak
6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages
7 Create Simple Shell Scripts
7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts
8 Operate Running Systems: Boot and Recovery
8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access
9 Operate Running Systems: Processes and Tuning
9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles
10 Operate Running Systems: Logs, Services & File Transfer
10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems
11 Configure Local Storage: Partitions and LVM
11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes
12 Configure Local Storage: Mounting and Expansion
12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively
13 Create and Configure File Systems: Local FS and Permissions
13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems
14 Create and Configure File Systems: NFS and autofs
14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs
15 Deploy and Maintain: Scheduling, Services & Targets
15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target
16 Deploy and Maintain: Time, Software Updates & Bootloader
16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader
17 Manage Basic Networking
17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd
18 Manage Users and Groups
18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access
19 Manage Security: Firewall, umask & SSH Keys
19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH
20 Manage Security: SELinux Modes and Contexts
20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts
21 Manage Security: SELinux Ports and Booleans
21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings
13.3 Diagnose and Correct File Permission Problems
Key Takeaways Explain This Topic AI
Diagnose with ls -l, ls -ld for directories, namei -l for path components, id/groups for the acting user, and optional getfacl when ACLs are in play.
Correct mode bits with chmod (symbolic ugoa±rwx or octal) and ownership with chown/chgrp; fix directories and files deliberately—recursive -R only when intended.
Permission failures are often on a parent directory (missing execute/search) even when the leaf file mode looks correct—namei reveals which path element blocks access.
Separate DAC (ugo/rwx, owner, group) from SELinux denials; if modes look right but access still fails, check ausearch/journal and contexts in security objectives—still fix wrong chmod/chown first when ls shows the problem.
Exam success is the required user can read/write/execute as specified after your diagnosis—not a blind chmod 777 on the whole tree.
Last updated: August 2026
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:
If UID matches file owner , use owner rwx triad.
Else if any process GID matches file group , use group triad.
Else use other triad.
ACLs (if present) can add per-user/per-group entries—check with getfacl when ls -l shows a + .
SELinux may still deny after DAC allows—different layer.
Directories interpret bits differently:
- Bit on directory Meaning
- r List names ( ls )
- w Create/delete entries (with x)
- x Search/traverse —enter path, access known child names
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
- Field Meaning
- First char - file, d directory, l symlink
- rwx triads owner, group, other
- . or + SELinux mark ( . ) / ACL ( + ) on many RHEL listings
- owner / group chown / chgrp targets
- 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
- Symptom Likely cause
- Permission denied on open file File mode or ownership
- Permission denied on path Parent without x
- Can ls but not cd Directory has r without x (or opposite confusion)
- Can read but not write Missing w on file or on directory for create
- Root works, user fails Expected DAC; fix mode/owner/group—not “bug”
Modes look open, still denied SELinux, immutable attr ( lsattr ), wrong user/namespace 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
- Octal digit rwx
- 7 rwx
- 6 rw-
- 5 r-x
- 4 r--
- 0 ---
- 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)
- Bit Octal Effect
- setuid 4xxx Run file as owner (binaries)
- setgid 2xxx Run as group; on dirs, new files inherit group
sticky 1xxx On /tmp -like dirs, only owner deletes own files 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
Identify user who must succeed ( id , task text).
Reproduce with sudo -u user ... .
Inspect leaf ls -l and path namei -l / ls -ld on each directory.
Decide: owner , group , mode , ACL , or other layer (SELinux/attr).
Apply minimal chown / chgrp / chmod (setgid share dirs when collaboration required).
Re-test as the user.
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
Fixing only the file when a parent lacks x .
Testing only as root — root bypasses DAC for most file modes.
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).
Forgetting re-login after group add so new GID is active—or use sg / newgrp in shell tests.
chmod without chown when ownership is the real bug.
Recursive 777 as a reflex.
Ignoring + ACL lines when basic ugo cannot explain access.
Treating SELinux denial as chmod problem forever—if modes are correct, pivot to contexts.
Making directories 644 — directories normally need x to be usable.
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.