wEEK 3
File Permissions and Defaults
Last week, you learnt some foundations of working in the terminal: finding your way, seeing what’s around, interacting with files, and chaining commands.
But sooner or later, you’ll run into a wall:
“Why can’t I edit this file?”
“Why does my program run fine on my machine but fail on the server?”
“Why can’t my teammate open the shared dataset?”
There’s a wide range of problems that can cause situations like these, but one of the most common culprits is permissions. If you don’t understand how Linux decides who can read, change, or run a file, you’ll often find yourself blocked in ways that look mysterious at first.
And before we dive into this week’s topic—permissions and defaults—I want to start with something just as important: troubleshooting skills and knowing where to look for answers. We’ll spend more time on this later in the course, but it’s worth introducing now because having the right troubleshooting approach can save you a lot of time and frustration.
Note: This class isn’t about memorizing every command. But it’s about learning how to think through problems, pick the right strategy, and use the resources available to you. If you build that mindset early, you’ll feel much more confident when you run into new errors.
Troubleshooting and References
When you encounter problems, the most important skill is not memorizing commands but knowing where and how to find solutions.
Start with the tools built into Linux itself. The man pages are your most reliable source of information:
man chmod,
man umask,
man ls.
Scroll with arrows or space bar, quit with q.
Beyond man pages, you’ll often turn to official documentation, community resources like Stack Overflow or Linux forums, and AI tools such as ChatGPT—especially once you already understand the problem/project. And of course, in this class you can always bring your questions to me if you get stuck.
Keep in mind: employers look for people who can solve problems at scale. That means going beyond just “fixing it” to actually understanding why a solution works and whether it will keep working in the future. Building that foundation now will make you a stronger problem-solver—and ultimately more valuable in the workplace.
Back to the main topic of this week:
File Permissions and Defaults
What They are
Permissions are rules that decide who can read, change, or run a file. Every file has:
- An owner (usually the creator).
- A group (a set of users with shared access).
- Others (everyone else on the system).
Each can be allowed to:
- Read (r) – open or view.
- Write (w) – modify or add/remove.
- Execute (x) – run (if file) or enter (if directory).
Why This Matters
Think about joining a company as a new employee. You’ll likely be working with a codebase that dozens of other developers also use. The company doesn’t want you—or anyone else—accidentally deleting critical files or changing production scripts. Instead, permissions are set so you can read and run the code, but only senior engineers or automated deployment tools can write to those files.
The same applies to data. Maybe your team has access to customer logs for debugging. Everyone should be able to read the logs to diagnose issues, but only the system itself should be able to write new entries. That way, the data stays trustworthy.
Permissions are how companies protect their systems while still letting teams collaborate productively.
P.E.R.M.I.T.S. Framework
To remember how permissions work and how to practice them, we’ll use P.E.R.M.I.T.S.
Each step asks a question, explains what it means, why it matters in real-world programming, and how to use it.
P
Permission Snapshot
What do the permissions look like right now?
E
Explain Who & What
Who owns this file, and what’s my role?
R
Read/Write/Execute (symbolic changes)
How do I adjust permissions step by step?
M
Modify with Numbers (octal)
How do I set all permissions at once with precision?
I
Inheritance via Defaults (umask)
What happens when I create a new file?
T
Try Directory Execute
What does “execute” mean for a directory?
S
Set Recursively & Summarize
Can I set permissions for everything in a folder?
There is a lot to take in this week if you’re not familiar with file permissions, but the table below summarizes the key points from the lecture. Let’s start with that summary table.
| Permission | On File – What You Can Do | On File – What You Cannot Do | On Directory – What You Can Do | On Directory – What You Cannot Do | Notes / Common Cases |
|---|---|---|---|---|---|
| Read (r) | View file contents (cat, less). | Cannot modify or run the file. | List directory entries (ls). | Cannot enter directory, cannot open files inside. | Read alone = look but not touch. |
| Write (w) | Modify file contents. | Cannot view if no r; cannot run if no x. | Create, delete, or rename entries in directory. | Cannot list or enter directory if no r/x. | On directories, write = change listing, not edit files themselves. |
| Execute (x) | Run the program/script if valid. | Cannot view/modify content if no r/w. | Enter/traverse directory (cd), open files if you know the name. | Cannot list names without r. | For directories, x = traverse/enter. |
| Read + Write (rw) | View and edit the file. | Cannot run if no x. | List contents and add/remove/rename files. | Cannot cd in without x. | Common for editable documents. |
| Read + Execute (r+x) | View file and run if executable. | Cannot modify without w. | List directory entries and open files inside. | Cannot add/remove files. | Most typical for shared directories. |
| Write + Execute (w+x) | Modify file if you already know how (e.g., overwrite with redirect). | Cannot view contents without r. | Enter directory and add/remove/rename files. | Cannot list names without r. | Dangerous on directories: can delete blindly. |
| Read + Write + Execute (rwx) | Full control: view, edit, run. | — | Full control: list, enter, add/remove/rename. | — | “777” = everything allowed. |
| No permissions (—) | Nothing — file is inaccessible. | Everything. | Directory is completely inaccessible. | Everything. | Appears as ---------- or d---------. |
Remember:
To list contents of a directory → need
r.To enter/traverse a directory → need
x.To open a file inside a directory → need
xon the directory plusron the file.To delete or rename a file → need
w+xon the directory (not the file itself).To run a file → need
xon the file (plusrif it’s a script you want to read).
P – Permission Snapshot
What do the permissions look like right now?
What this means:
When you log into a Linux system, every file and directory has a status that describes who owns it and what actions are allowed. This status is shown as a series of letters (like -rw-r--r--) that represent read, write, and execute rights for the file’s owner, its group, and everyone else.
Taking a “snapshot” of permissions means running ls -l to see the current state before doing anything else. Think of it like checking a car’s dashboard before driving: if the fuel gauge is empty, the problem isn’t that the car won’t start—it’s that it has no fuel. Similarly, if you can’t edit a file, the problem might not be your code but that you don’t have write permission.
Why this matters:
- Many “broken” programs fail simply because the file they need isn’t accessible. Checking permissions first saves hours of wasted debugging.
- At companies, junior developers often spend time onboarding. When they run into errors, team leads expect them to check basics (permissions, ownership) before escalating.
- Permissions snapshots are how system admins confirm that sensitive data isn’t accidentally exposed.
- Building the habit early means when something fails in production, you’ll check environment causes (like access) before assuming it’s a code bug.
How to use it (troubleshooting steps example):
Navigate to the directory where the issue is happening.
Run: ls -l
This prints a list of files with their permissions, owners, and groups.Focus on the leftmost column (e.g.,
-rw-r--r--). Break it into three sets:Owner (
rw-)Group (
r--)Others (
r--)
4. Compare this against what you’re trying to do.
If you need to edit but see only
r--, that’s the issue.If you need to run a script but don’t see
x, it won’t execute.
5. Cross-check the owner/group with id to confirm if you’re the intended user or part of the right team.
Real-world scenario:
You’re a new hire at a software company. On your first week, you’re asked to update a configuration file. You try opening it but get a “Permission denied” error. Instead of assuming the editor is broken or the server is down, you run ls -l and see the file is -r--r----- root ops config.yaml. You realize:
Owner is
root, not you.Group is
ops, which you don’t belong to yet.Permissions show only read access for the group, none for others.
You now know the correct next step: request to join the ops group or ask a teammate with access to make the change. You’ve saved yourself (and your manager) hours of confusion by taking a simple snapshot.
E – Explain Who & What
Who owns this file, and what’s my role?
What this means:
Every file belongs to two “identities”: a user (the account that owns it) and a group (a collection of accounts). Groups exist so multiple people can share access without exposing the file to everyone.
On your system, you are a specific user with a user ID (UID). You also belong to one or more groups, which are listed in your group IDs (GID). The system checks these IDs to decide if you get access.
Why this matters:
- You might think “I should have access—it’s my team’s file,” but if you’re not in the right group, Linux will block you.
- Businesses control access by groups—Finance, DevOps, Data Science—so that employees only see what they need for their work.
- Knowing ownership prevents you from carelessly giving “world access” when you really should just adjust the group.
- Understanding who owns a file helps you know whether to fix permissions yourself or request a teammate/administrator to do it.
How to use this (troubleshooting steps example):
- Run
idto see who you are and what groups you belong to. Example output:uid=1001(jdoe) gid=1001(jdoe) groups=1001(jdoe), 1200(devteam) Use
ls -l filenameto check the file’s owner and group.Compare:
If you are the owner, check your section of the permissions string.
If you’re in the group, check the group section.
If you’re neither, you fall into the others category.
Decide the right fix:
If you should be in the group, request access.
If you own the file, adjust with
chmod.If neither, escalate to an administrator.
Real-world scenario:
You’re assigned to run analytics on a shared dataset. You try to open sales.csv and fail. Checking ownership shows it belongs to the data-team group, but your account is only in devteam. The solution isn’t to hack permissions—it’s to file an access request with IT to be added to data-team. You now understand the what and who of the problem.
R – Read/Write/Execute (symbolic changes)
How can I adjust permissions?
What this means:
Linux lets you grant or remove specific rights using symbolic mode with chmod. Instead of resetting all permissions at once, you carefully add (+) or remove (-) rights for u (owner), g (group), and o (others).
Why this matters:
- Lets you fix one issue without accidentally exposing files.
- You often need to give a coworker access to a single file without opening it to the whole system.
- Symbolic changes make you think about exactly what you’re granting or removing.
- Many security incidents come from overly broad permissions.
How to use this (troubleshooting steps example):
Identify the problem: coworker can’t read, script won’t run, etc.
Decide who needs access:
u = the owner (you)
g = your group (project team)
o = everyone else
Apply changes:
Add group read:
chmod g+r file.txtRemove world read:
chmod o-r file.txtAllow owner execute:
chmod u+x script.sh
Verify with
ls -lto confirm the change.
Real-world scenario:
You push a script to the repo, but your teammate can’t run it. Instead of opening it to everyone, you add execute rights just for the group.
M – Modify with Numbers (octal)
How do I set all permissions at once?
What this means:
Octal values (like 640 or 755) describe permissions for owner, group, and others in a single step.
Unlike a graphical interface, which opens a file in a separate window, the terminal allows you to quickly inspect the contents of any text-based file—including large files, system logs, code, and configuration files—without opening a full editor.
Why this matters:
- Many important files in Unix-based systems—like logs, settings, and scripts—are plain text. Being able to view them without editing or formatting is a practical and efficient skill.
- On remote or minimal systems, there may be no text editor installed or no graphical way to open files.
- Viewing files from the terminal allows you to filter, search, or scroll through content without changing it.
- This is often the first step in diagnosing a problem, verifying whether a tool worked, or reviewing changes made by a program or process.
How to use this:
1. To view the full contents of a file immediately
You can run a basic instruction that prints the entire file to the screen.
This is useful for small files like notes, short logs, or plain text outputs.
If the file is long, the output may scroll off the screen—so this method is best for quick checks.
Commands:
– cat filename
– nl filename # same as cat, but numbers the lines
– sed -n ‘1,200p’ file # print only the first 200 lines (avoids flooding)
2. To scroll through a large file one section at a time
If you expect a long file (like a system log or dataset), you can use a tool that lets you scroll, move up and down, and quit when you’re done.
This is useful when you’re looking for a pattern, a timestamp, or the general structure of the content.
Commands (use q to quit):
– less filename # scroll with ↑/↓, PgUp/PgDn; search with /pattern
– less +G filename # jump to end on open (handy for logs)
– more filename # simpler pager
3. To read just the beginning or end of a file
You may only need the first few lines (to see the header or config) or the last few lines (to check the most recent update or error).
This helps you quickly focus on relevant parts without reading the whole file.
Commands:
– head filename # first 10 lines
– head -n 50 filename # first 50 lines
– tail filename # last 10 lines
– tail -n 50 filename # last 50 lines
4. To monitor a file that is still being updated
Some files grow over time, like log files that collect error messages or activity records.
You can use a tool that watches the file in real time and shows new lines as they are added.
This is useful for watching server traffic, installation progress, or application output as it happens.
Commands (stop with Ctrl+C):
– tail -f filename # follow new lines as they are written
– tail -F filename # like -f, but resilient to log rotation
– less +F filename # follow mode in less; press Ctrl+C to stop following, then q to quit
Examples of when this comes up:
- You’re troubleshooting a system error and want to see what the latest log entries say.
- You need to verify that a file was generated correctly—by checking its structure or first few lines.
- You’re trying to understand how a program was configured, and need to read its settings file.
- You’re observing the output of a script or process to confirm that it’s still running and producing data.
- You’re comparing versions of a file to determine what changed and when.
I — Stack and Redirect Commands
What happens when I create a new file?
What this means:
Whenever you create a file or directory in Linux, it doesn’t just appear with random permissions. Instead, the system uses a setting called umask (short for user mask).
Think of umask as a filter: it takes the system’s full set of possible permissions and subtracts some of them for safety. For example, files are never created with execute permission by default, because that would make every new text file potentially runnable as a program.
With a umask of 022, new files are created with
rw-r--r--. That means the owner can read/write, while group and others can only read.With a umask of 027, new files become
rw-r-----, so the group can read, but others can’t access them at all.
Directories follow the same idea but include execute (x) because you need that to enter them.
Why this matters
- Files aren’t created wide open, which avoids leaks on shared systems.
- If a coworker says “I can’t read the files you just generated,” it may not be your program—it may be your umask.
- When programs generate logs, reports, or datasets, their default accessibility is entirely shaped by umask.
- Many IT departments enforce umask values to meet security standards (e.g., HIPAA, PCI compliance).
How to use this:
1. Check your current umask
Run the `umask` command.
– This shows the mask currently applied on your account.
– For example, 0022 means new files will be created as rw-r–r–.
2. Test with a new file and directory
Create a file and a folder:
touch f1.txt
mkdir d1
ls -l f1.txt
ls -ld d1
– This lets you see how the umask actually shapes permissions in practice.
– Files won’t have execute by default, but directories will include execute so you can enter them.
3. Temporarily adjust the umask
Change the mask to something more restrictive, like 027:
umask 027
touch f2.txt
mkdir d2
ls -l f2.txt
ls -ld d2
– Now new files are owner rw-, group r–, others —.
– Directories are owner rwx, group r-x, others —.
– This shows how umask directly controls collaboration defaults.
4. Restore your original value
Put things back to normal with:
umask 0022
– Always reset after testing.
– In production environments, leaving an overly strict or loose umask can cause major workflow problems.
Examples of when this comes up:
- Your code writes logs, but coworkers can’t open them because your umask makes them private.
- A script generates CSVs for analysis. If umask is wrong, only the script’s owner can read them, blocking the rest of the team.
- New build artifacts (like binaries or config files) are created unreadable by the web server account, breaking the application until permissions are fixed.
- A grad student runs an analysis pipeline, but outputs are restricted to their account, so other researchers can’t access results.
- IT enforces `umask 077` on production systems so no new files are group- or world-readable, reducing the risk of leaking customer data.
- Files uploaded to shared cloud directories inherit permissions from umask, which decides whether other team members can see or edit them.
T - Try Directory Execute
What does “execute” mean for a directory?
What this means:
On a file, execute (x) means “run this program.” On a directory, execute has a different meaning: it controls whether you can enter/traverse that directory.
• No x on a directory: you cannot cd into it or open files inside it. If you do have r without x, you may see the list of names, but you still can’t open any of them.
• r but no x: you can list the directory’s names, but you cannot open those entries or cd into the directory. (Even ls -l won’t show full metadata without x.)
• x but no r: you can enter the directory and open files if you already know their names, but you cannot list the contents.
Rule of thumb: to both list and access what’s inside a directory, you generally need r + x on that directory (and the usual permissions on the files themselves).
Why this matters
This separation lets you share spaces safely. For example, you can allow students to run a program in a class folder (x) without browsing everything in it (no r), or let them see what’s there (r) without letting them open anything (no x). It’s fine-grained access control that’s very practical in multi-user Linux environments.
- Prevents unauthorized browsing: protects sensitive directories from being explored casually.
- Common way companies separate access: finance, HR, and security logs often restrict “entering” directories to authorized groups.
- Helps diagnose odd errors: “I can see the file name but still can’t open it” is usually a missing `x` on the parent directory.
- Enables secure sharing: you can allow colleagues to run programs in a folder without letting them edit or list everything inside.
How to use this:
1. Check the directory permissions
Run:
ls -ld directoryname
– This shows the read (r), write (w), and execute (x) bits for the directory.
– Focus on whether `x` is set for you (owner, group, or others).
2. Test behavior with missing execute
– Remove execute:
chmod a-x testdir
– Try entering:
cd testdir
– You’ll get “Permission denied” even if you own files inside.
3. Add execute back safely
– Restore execute for yourself or the right group:
chmod u+x testdir # owner only
chmod g+x testdir # group only
– Now you can `cd` into it again.
4. Experiment with read vs. execute
– Try removing just read but keeping execute:
chmod a-r testdir
– You can enter the directory, but `ls` won’t show contents.
– This is useful when people should be able to run known programs but not explore everything else.
Examples of when this comes up:
- Onboarding as a new employee: You see that the company’s finance folder exists, but you can’t `cd` into it because execute is blocked for your group. This isn’t a bug—it’s intentional security.
- Shared project folders: Your team shares a folder of compiled tools. You’re allowed to execute them, but you can’t list the entire folder because management doesn’t want you browsing unrelated files.
- Web server logs: The logs directory may be world-readable but not world-executable, meaning outsiders can’t even enter it even if they guess its name.
- Research labs: Professors allow students to run specific analysis scripts inside a results folder but block directory listing so raw data remains private.
- Software deployment: A production server has a directory of configuration files. Developers know the exact file names to edit, but they cannot list the directory because that would reveal sensitive settings.
- Incident response: Security teams intentionally remove execute from suspicious directories so malware cannot run or spread further.
S – Set Recursively & Summarize
Can I apply permissions to everything in a folder?
What this means:
Changing permissions one file at a time works for small fixes, but in real projects you often need to adjust dozens or even thousands of files at once.
The `-R` (recursive) option with `chmod` allows you to apply changes to a directory and *everything inside it*—all files, all subdirectories, all at once.
This is a powerful tool, but it also requires care. A single recursive command can open or lock down an entire project, so it’s critical to double-check before running it.
Why this matters
- Ensures consistency across large codebases, datasets, or project folders.
- Saves huge amounts of time compared to setting each file individually.
- Used in professional environments when preparing shared workspaces for new employees.
- Common in deployment pipelines to make sure scripts are executable and data files are readable in the right way.
- Mistakes can cause security risks (e.g., accidentally making private files world-readable) — so knowing how to use it responsibly is an employable skill.
How to use this:
1. Check what you’re about to change
– Run:
ls -lR project/
– This lists permissions for all files and subfolders.
– Make sure you understand the current state before making changes.
2. Apply recursive changes carefully
– Run:
chmod -R 755 project/
– This sets owner rwx, group r-x, others r-x for every file and directory.
– Use numbers (octal) for consistency in team settings.
3. Verify the results
– Run:
ls -lR project/
– Confirm that changes applied as expected across all files.
– Spot-check sensitive files to ensure they aren’t accidentally exposed.
4. Summarize the environment
– After changes, document what permissions were applied and why.
– Companies value clear documentation so teammates know what was set and don’t repeat mistakes later.
Examples of when this comes up:
- Onboarding a new hire: You prepare the team’s shared project folder. Instead of fixing each file manually, you apply `chmod -R 755` so scripts are executable for everyone and data is readable.
- Deployment scripts: Before pushing code to production, the CI/CD pipeline runs a recursive permission reset to ensure all shell scripts are runnable and configs are protected.
- Data science projects: A large dataset of CSVs and analysis scripts is moved to a shared server. Recursive changes ensure the group can read everything, but only the owner can write.
- Research collaborations: Professors create project directories for each lab group and use recursive permissions to set clear boundaries between teams.
- Incident response: After discovering a misconfigured directory, sysadmins apply recursive changes to lock down sensitive files quickly.
- Archiving projects: Before packaging old code for backup, recursive permissions are standardized so files remain accessible later without confusion.
This concludes Lecture 3. Please return to Blackboard to access the Week 3 materials.