Linux Filesystem and Permissions
Navigate the Linux directory hierarchy and control access with ownership, modes, and special permissions.
- Certification
- CompTIA Linux+
- Recommended study time
- 5h 35m
- Status
- Not started
Recommended study time
About 5h 35m in total, measured from the material on this page. At your session length of 45 minutes that is 8 sittings.
- Read the lesson23 min
About 3,047 words at a careful technical reading pace.
- Second pass with notes14 min
Re-read the harder parts and write your own notes.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice2h 40m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 20m
4 short review sessions spread over the following weeks.
Learning objectives
- Explain the purpose of the main directories in the filesystem hierarchy.
- Set ownership and permissions correctly using symbolic and octal notation.
- Diagnose permission-denied errors with evidence rather than blanket chmod 777.
Start here
About 8 minutes of reading, in 10 short parts.
Every file on a Linux system has an owner, a group, and a set of rules about who may read it, change it, or run it. Beginners often meet this as a wall of "denied" errors, but once you can read a permission string the whole system becomes predictable rather than frightening.
Where you meet it: A developer asks why their deployment script cannot write to a log folder, and the answer is sitting in the output of ls -l.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
Think of a Linux server as a large shared office building. Every drawer, cabinet, and filing folder has a label saying who owns it and who else is allowed to look inside, add papers, or take things out. The building has strict rules: even the cleaning staff (other users) cannot open a locked drawer unless the label specifically permits it. Nobody gets to just 'try the handle' and see what happens; the building enforces the label automatically.
The folder structure itself is also organised by purpose, like different departments in a building. Programs live in one wing, settings live in another, personal files live in individual offices, and temporary scratch paper lives in a shared bin that anyone can use but nobody can steal from. Learning where things live and who is allowed to touch them is most of what makes a Linux system feel less alien.
Key ideas
If you remember nothing else from this topic, remember these.
- Every file carries an owner, a group, and three permission triads that the kernel checks in a fixed order: owner first, then group, then other, and it stops at the first match.
- Execute permission on a directory means traverse, not run, which is why a directory can be locked down to 711 and still let a known path through.
- umask subtracts bits from the default creation mode, so a umask of 022 turns a requested 666 into 644 for new files.
- Special bits change identity or deletion rules rather than basic access: setuid runs a program as its owner, setgid inherits group on new files, and the sticky bit protects one user's files from another in a shared directory.
- SSH refuses to use a private key that is readable by group or other, because a key anyone else can read is not private regardless of intent.
- chmod 777 removes an error message but also removes the entire point of having permissions, so it should never be treated as a fix.
- A permission failure can come from any directory along the full path to a file, not only from the file's own mode bits.
Diagnosing a shared team folder that keeps losing group ownership
A worked example, step by step.
Five developers share /srv/projects/api and keep finding files they cannot edit because a teammate created them with the wrong group.
- 01Inspect the directoryls -ld /srv/projects/api shows drwxrwxr-x 2 alice devteam, confirming group devteam exists but nothing forces new files into it.
- 02List a broken filels -l api/routes.py shows -rw-r--r-- 1 bob bob, meaning bob's personal group owns it instead of devteam, blocking other devteam members from writing.
- 03Check group membershipgroups bob confirms bob is in devteam, so the problem is inheritance, not membership.
- 04Apply setgid to the directorychmod g+s /srv/projects/api makes every new file created inside automatically belong to group devteam.
- 05Fix existing fileschgrp -R devteam /srv/projects/api and chmod -R g+rw /srv/projects/api normalize ownership and access on files already there.
- 06Set a shared umaskAdding umask 002 to the team's shell profile ensures new files default to 664 instead of 644, keeping group write intact.
- 07Verify as a different usersudo -u carol touch api/newfile.py followed by ls -l shows the new file owned by carol but grouped devteam, proving inheritance now works.
- 08OutcomeThe team stops losing write access to each other's files because every new file is created with the correct shared group automatically.
Outcome: Setgid plus a corrected umask eliminates the ownership drift instead of repeatedly chmod-ing individual files after the fact.
Filesystem permission reference
Worth keeping at hand while you work.
- chmod 750 file
- Owner read write execute, group read execute, other nothing.
- chmod u+x, g-w
- Symbolic form: add execute for owner, remove write for group.
- chown user:group path
- Changes both owner and group in one command.
- chgrp group path
- Changes only the group of a file or directory.
- umask 022
- Default new file mode becomes 644, new directory mode becomes 755.
- setuid (4000)
- Program runs with the file owner's identity, used by tools like passwd.
- setgid on dir (2000)
- New files created inside inherit the directory's group.
- Sticky bit (1000)
- In a shared directory like /tmp, only the file's owner or root can delete it.
- namei -l path
- Prints permissions for every component along a full path, useful for tracing denied traversal.
- chmod 600 for SSH private keys
- Anything more permissive causes OpenSSH to reject the key outright.
- .ssh directory mode 700
- Required alongside key file mode or SSH will still refuse to use it.
- /etc, /var, /home, /proc, /sys
- Configuration, variable runtime data, user homes, and virtual kernel/process trees respectively.
Common misunderstandings
What most beginners get wrong here.
chmod 777 is a safe way to make a stubborn permission error go away.
It grants full read, write, and execute to every account on the system, so the correct fix is identifying the exact account that needs access and granting only that.
Read access on a directory lets you open files inside it.
Read only lets you list names; execute (traverse) is what actually lets you access a specific file inside that directory.
Being the file owner and having your group also own it stacks additional privilege.
The kernel evaluates owner, group, then other in strict order and stops at the first match, so owner bits alone decide access for the owner regardless of group bits.
Copying a private key with scp preserves the permissions needed for SSH.
Copy operations often reset mode to the destination default, so the key and its containing .ssh directory need chmod 600 and 700 reapplied afterward.
Deleting old log files in a shared temp directory just requires directory write access.
The sticky bit on directories like /tmp overrides that and restricts deletion to the file's own owner or root.
Exam traps
How the question writers try to catch you out.
- Given an octal mode like 640, expect to translate it correctly into rw-r-----.
- A scenario describing a shared directory where files keep ending up owned by the wrong group is testing whether you know to apply setgid, not just chgrp.
- Questions about SSH connection failures that mention a permissions warning are testing knowledge of the required 600 and 700 modes, not network troubleshooting.
- A question may ask what happens when a directory has execute but not read permission, expecting you to know traversal without listing is possible.
- Umask questions expect subtraction from 666 for files and 777 for directories, not from 777 universally.
Check yourself
Answer in your head first, then reveal. This is not scored.
What does execute permission mean on a directory as opposed to a file?
What mode does umask 002 produce for a newly created file?
Why does OpenSSH reject a private key with mode 644?
What does the setgid bit do when applied to a directory?
If chmod on a file looks correct but access still fails, what should you check next?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
The filesystem hierarchy places binaries in /usr/bin, configuration in /etc, variable data in /var, user data in /home, and runtime pseudo-filesystems in /proc and /sys. Every file has a user owner, a group owner, and read, write, and execute bits for user, group, and others. Special bits add setuid, setgid, and the sticky bit. Umask controls default permissions on creation.
Why It Matters
Web servers, databases, and scripts run as service accounts, not as you. Understanding effective permissions is what lets you grant exactly the access a service needs instead of weakening the system.
How It Works
- The kernel checks user, then group, then other permissions in that order and stops at the first match.
- Directory execute permission controls whether a path can be traversed.
- Umask removes bits from the default 666 for files and 777 for directories.
Where You See It
- Web and database server data directories, SSH keys, log files, shared team storage, and deployment pipelines.
Key Terms
- Octal mode
- Numeric permission form such as 640 or 755.
- Umask
- The mask subtracted from default permissions on file creation.
- setgid
- Bit causing new files in a directory to inherit its group.
- Sticky bit
- Restricts deletion in shared directories such as /tmp.
- Effective permission
- The access a specific process actually has.
Examples
- A private SSH key must be mode 600 or the client refuses to use it.
- A shared team directory with setgid keeps group ownership consistent for all new files.
Common Problems
- Permission denied for a service account
- Wrong ownership after copying as root
- Overly permissive modes
- Full /var from logs
How It Fails
- Files copied as root leave a service unable to write its own data directory.
- World-writable configuration lets any local user alter service behaviour.
- A group-based scheme breaks when new files do not inherit the intended group.
How to Troubleshoot
- Identify the account the process runs as, then test access as that account.
- Check every directory in the path, not only the target file.
- Read the exact errno message; permission and existence errors differ.
Practical Knowledge
- Grant access via groups, never by widening world permissions.
- Use sudo -u to test as the service account rather than assuming.
Exam Coverage
- Filesystem hierarchy standard
- Ownership, modes, and special bits
- Permission troubleshooting
Interview Questions
- What does mode 750 mean for user, group, and others?
- A web app cannot write uploads. How do you diagnose it?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Run ls -l on /etc and interpret three different permission sets.
- 02Create a setgid shared directory and verify inherited group ownership.