A script can be readable and still fail with “Permission denied” when you try to run it. Linux treats reading and executing as separate permissions. Start with ls -l script.sh: the output shows the permission bits, owner, and group.
Who gets access?
Every file and directory has an owning user and group. The basic permission model assigns rights to three classes: user (the owner), group (members of the owning group), and other (everyone else). These classes apply to the account trying to access the item. “Other” does not mean anonymous internet users unless a service makes the item accessible to them.
Run id to see your user ID and group memberships, and ls -l notes.txt to inspect a file. An entry such as -rw-r----- 1 maya editors 2400 May 8 10:30 notes.txt identifies maya as the owner and editors as the group. The first character, -, marks a regular file; the next nine show its permissions.
Linux uses numeric user and group IDs internally, though tools usually display names. If you belong to several groups, a file’s owning group may match any one of them. That membership does not give you the owner’s permissions: the group’s own three bits determine your access.
Read the permission string
Split the nine permission characters into three sets of three. In -rw-r-----, the owner has rw-, the group has r--, and others have ---. Each set lists read (r), write (w), and execute (x) in that order. A dash means the bit is absent.
| Bit | On a regular file | On a directory |
|---|---|---|
r |
Read the file’s contents | List names inside the directory |
w |
Modify the file’s contents | Add, remove, or rename entries, when search is also allowed |
x |
Execute the file, if it is a usable program or script | Search or traverse the directory to reach an entry |
Directory permissions are easy to misread. With r but no x, you may see names without being able to access the named files. With x but no r, you may reach a file whose name you already know, subject to that file’s permissions, but you cannot ordinarily list the directory. Creating or deleting an entry generally requires write and execute permission on its parent directory, not write permission on the file. A sticky bit, discussed below, can further restrict deletion.
Parent directories matter for reading, too. To read /home/maya/project/report.txt, you need search permission on every directory in the path, then read permission on the file. A world-readable file can therefore remain inaccessible to another user.
Change permissions with chmod
chmod changes permission bits on files you own, subject to system rules; an administrator can manage them too. In symbolic mode, choose a class—u for owner, g for group, o for other, or a for all three—then an operation. Use + to add bits, - to remove them, or = to set that class’s ordinary permission bits exactly.
chmod u+x script.shadds execute permission for the owner without changing the other bits.chmod go-rwx private.txtremoves all group and other permissions.chmod g=r shared.txtsets the group’s ordinary permissions to read only.chmod o-x projectprevents users in the other class from traversing that directory.
Check the result with ls -l. Be careful with recursive changes: chmod -R 755 project makes regular files executable as well as directories searchable. Inspect the tree first, then handle files and directories separately if they need different modes. Change only paths you own or are authorized to administer.
Numeric mode in three digits
Numeric modes assign one digit to each class. Read is 4, write is 2, and execute is 1; add the values you want and write the owner, group, and other digits in that order. chmod 640 notes.txt gives the owner read/write (6), the group read (4), and others no access (0). With chmod 755 tool.sh, the owner can read, write, and execute, while the group and others can read and execute.
chmod 600 secret.txt is a common choice for a private regular file. chmod 700 private-dir gives its owner full directory access and removes group and other access. Neither mode fixes an unexpected owner or missing search permission higher in the path. Execute permission also does not make arbitrary text runnable: a script needs a suitable interpreter and format.
Ownership, groups, and administrative privilege
chown changes ownership; chgrp changes a file’s group. An authorized administrator might run sudo chown maya:editors report.txt to assign both. On Linux, changing the owning user normally requires elevated privileges. Without them, changing the group is generally limited to files you own and groups you belong to. Check the current state with ls -l first.
Do not use sudo just to silence a permission error. It runs a command with elevated privileges, so a wrong path or recursive change can affect far more than you intended. If a project under your home directory unexpectedly belongs to root, find out why—perhaps an earlier command ran with sudo—then correct only the affected paths with authorization.
For sharing between local accounts, a group is often cleaner than broad access for everyone. Assign files to a shared group and grant only the bits its members need. On a shared directory, group write plus execute lets members create and manage entries; group read lets them list names. New files there may otherwise receive the creator’s default group. Setting the directory’s setgid bit normally makes new entries inherit the directory’s group.
Why new files have different permissions
New permissions depend on the creating program’s requested mode and the process’s umask. A typical regular file starts with a requested mode of 666. With a umask of 022, group and other write bits are filtered out, leaving 644. A typical directory starts from 777, so the same mask leaves 755. This bit filtering does not mean every program creates files with those exact modes.
Run umask to see your shell’s current mask. A more restrictive umask 077 prevents new items from receiving group or other permissions when programs use the usual starting modes. It affects future creations by that shell and its child processes, not existing files. Applications can request different modes or change permissions afterward.
Special bits and ACLs
The familiar nine bits do not tell the whole story. Three special bits can also appear in ls -l. On a directory, setgid helps new entries inherit its group for controlled collaboration. The sticky bit, often used on shared writable directories such as /tmp, generally limits removal or renaming of entries to the entry’s owner, the directory owner, or a privileged process. On an executable file, setuid or setgid can change the effective identity used when it runs. Those executable-file bits have significant security implications; do not add them as a routine fix for access errors.
Access control lists (ACLs) can grant permissions to named users or groups beyond the basic owner/group/other entries. A + after the permissions in ls -l often signals an ACL; where the tools are available, getfacl filename shows its entries. An ACL mask can limit effective permissions for named users and groups, so an entry alone may not explain the access you get. Filesystem settings and mechanisms such as SELinux or AppArmor can impose further restrictions. Ordinary permission bits are a starting point, not a guarantee that an operation will succeed.
Diagnose “Permission denied” without guessing
- Identify the operation. Reading a file, running it, creating a file, and entering a directory require different bits.
- Check your identity. Run
idto confirm your account and the groups in your current session. A newly added group may not appear until you start a new login session. - Inspect the target. Use
ls -ld pathto inspect a directory itself rather than list its contents. Usels -l filefor a file. - Check parent directories. Where available,
namei -l /full/path/to/filedisplays permissions along the path. Otherwise, inspect each component withls -ld. - Look for additional rules. If the basic bits appear sufficient, inspect ACLs with
getfacland consult relevant system logs or an administrator before changing anything.
Suppose report.txt is -rw-r----- maya editors, your account belongs to editors, and opening it still fails. Before changing the file to 644, check search permission on every parent directory. If /home/maya is drwx------, other accounts cannot traverse it to reach the report. For authorized sharing, move the report to a purpose-built shared directory rather than opening up someone’s home directory.
