Source: https://mayphus.org/systems-linux-files/
Title: Linux — files, users and permissions
Metadata: {"kind":"page","language":"en","route":"/systems-linux-files/","tags":["systems","linux"],"type":"page"}

A file that exists can still be inaccessible. Before changing permissions, identify the path, the object at that path and the account attempting the operation. These are different questions, and answering them separately makes a failure easier to explain.

This chapter belongs to [Understanding computer systems](/understanding-computer-systems/). Its goal is to produce a short, evidence-based explanation of access to an ordinary system file, without changing that file or your account.

## Environment and exercise status

**Proposed exercises, not executed on Ubuntu 24.04 LTS for this guide.** Commands target Ubuntu 24.04 LTS with Bash and GNU coreutils, using an ordinary local account. They inspect metadata and public operating-system identification. Do not add `sudo`, change permissions or post account names and local paths publicly. A restricted container can produce different results from a desktop or virtual machine.

If opening a terminal is new, start with [Ubuntu's command-line tutorial](https://ubuntu.com/tutorials/command-line-for-beginners), which now links to its updated edition. The exercises below do not require the tutorial's file-creation or administrator steps.

## A name, an object and an identity

A pathname is a route through directories. An absolute path starts at `/`; a relative path starts from the current working directory. A symbolic link supplies another path to follow. Consequently, inspecting a link and inspecting its target can answer different questions. The kernel also checks directory search permissions while resolving a path; a readable final file does not overcome an inaccessible directory along the way. [Linux pathname resolution](https://manpages.ubuntu.com/manpages/noble/man7/path_resolution.7.html) describes these steps.

Permissions concern the process attempting access. A person can have several sessions or programs with different effective identities. For this introductory exercise, use the identity of your ordinary terminal session. The `id` command reports user and group identifiers; a numeric identifier and its displayed account name are two representations of identity, not two accounts. See Ubuntu's [`id` reference](https://manpages.ubuntu.com/manpages/noble/man1/id.1.html).

## Exercise 1 — identify the environment and object

Run these separately in Bash on Ubuntu 24.04 LTS:

```sh
cat /etc/os-release
id
ls -ld / /etc /etc/os-release
stat -c '%F | %A | %U:%G | %n' /etc/os-release
stat -L -c '%F | %A | %U:%G | %n' /etc/os-release
```

Confirm that the release identification says Ubuntu and version `24.04` before treating this as the proposed environment. Stop and consult your distribution's documentation if it differs.

`ls -d` inspects the named directories themselves instead of listing their contents. GNU `stat` prints the object type, readable permission notation, owner/group and pathname. The second invocation follows a symbolic link with `-L`. If `/etc/os-release` is a link, the two results can describe different object types. If it is an ordinary file, matching results are expected. These options are documented in [`ls`](https://manpages.ubuntu.com/manpages/noble/man1/ls.1.html) and [`stat`](https://manpages.ubuntu.com/manpages/noble/man1/stat.1.html).

Record a sentence rather than a screenshot: “The release file is a ___, owned by ___, and the link-following inspection reports ___.” There is no prescribed owner string or inode number to reproduce. The point is to interpret your own observation, not match a fabricated transcript.

## Exercise 2 — predict access, then compare

Still on Ubuntu 24.04 LTS, inspect directory metadata without enumerating your personal files:

```sh
ls -ld / /etc "$HOME"
```

In ordinary permission notation, the first character describes the object type. The next groups describe owner, group and other permissions. For a regular file, reading concerns its contents; for a directory, reading concerns listing names, while search permission permits looking up entries. Directory write permission concerns changes to directory entries. It is not equivalent to permission to rewrite every file below that directory. The [pathname-resolution permission discussion](https://manpages.ubuntu.com/manpages/noble/man7/path_resolution.7.html) explains why these distinctions matter.

Compare your session's groups with the displayed owner and group. Predict whether you can traverse `/etc` and read the release file. You already attempted the latter with `cat`; compare that observation with the prediction. Do not create an artificial failure by changing a system directory's permissions.

## What this does not establish

Permission bits are only an introductory model. Access-control lists, security policy, mount state and process privileges can change an access decision. A metadata listing alone does not prove every possible operation will succeed. If prediction and observation disagree, preserve the exact error privately and investigate the additional constraint instead of broadening permissions.

Next, follow the identity into a running program in [processes, services and logs](/systems-linux-processes/), then connect software to its installed package and network boundary in [networking and packages](/systems-linux-networking/). My [Linux disk investigation](/linux-disk/) supplies a separate storage case study; permission inspection here is not a disk-repair procedure.

Official references checked on 2026-10-08. Expected observations above are teaching expectations, not a recorded test run.