Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
In brief: Linux permissions assign read, write, and execute/search rights separately to the owner, group, and everyone else. chmod changes permissions that already exist; umask removes bits when new files or directories are created. Thus chmod 755 gives an object owner full access while group and others can read and search, and umask 0022 normally creates files as 0644 and directories as 0755. Setgid directories preserve a shared group, sticky directories protect users from deleting one another’s files, and every directory in a path must grant search permission before a service can reach a readable file.
The Linux permission model
Every filesystem object has mode bits divided into three classes: owner, group, and others. Each class has read (r), write (w), and execute (x) bits. For a regular file, read opens its contents, write changes its contents, and execute allows it to be run as a program (subject to the interpreter, mount options, and other security controls). For a directory, the same letters have different practical meanings.
Recommended Free Tools
| Bit | Regular file | Directory |
|---|---|---|
| Read (4) | Read file contents | List names in the directory |
| Write (2) | Change file contents | Create, remove, or rename entries (usually also requires search) |
| Execute (1) | Run the file | Search or traverse; access a known name and pass through the directory |
Directory execute is often called search. A process can know a file name and still receive “Permission denied” if it lacks search permission on any parent directory. Conversely, read permission on a directory permits listing names but does not by itself permit opening those files.
Reading a mode such as 0755
A long listing such as -rwxr-xr-x starts with a file-type character, followed by three permission triplets. The first triplet belongs to the owner, the second to the group, and the third to others. In octal notation, read is 4, write is 2, and execute/search is 1; add the values within each triplet.
| Octal digit | Bits | Meaning |
|---|---|---|
| 0 | — | No permission |
| 1 | –x | Execute/search |
| 2 | -w- | Write |
| 3 | -wx | Write and execute/search |
| 4 | r– | Read |
| 5 | r-x | Read and execute/search |
| 6 | rw- | Read and write |
| 7 | rwx | Read, write, and execute/search |
Therefore 0755 means owner rwx, group r-x, and others r-x. On a directory, the owner can list, create, remove, rename, and traverse; group and others can list and traverse but cannot create or remove entries.
#1 Best Overall
What chmod changes
chmod changes mode bits on existing files and directories. The command does not change ownership, group membership, ACL entries, or a process’s supplementary groups.
Common numeric commands
chmod 0644 filegives the owner read/write and gives group and others read-only access.chmod 0755 directorygives the owner full directory access and gives group and others read/search access.chmod 0700 private-directoryrestricts a directory to its owner.
A leading zero makes the four-digit layout explicit. The first digit is reserved for special bits; the remaining three digits are owner, group, and others.
Symbolic mode changes
Symbolic notation identifies the class and operation, which is useful when you want to preserve unrelated bits. For example, chmod u+x script.sh adds execute for the owner, chmod g-w file removes group write, and chmod o-r secret removes read permission for others. The GNU chmod manual describes rwxXst as the selectable mode letters; X adds execute only to directories and to files that already have an execute bit.
Special bits in numeric modes
The special-bit digit uses setuid 4, setgid 2, and sticky 1. Thus chmod 2755 directory sets setgid in addition to 0755. Special bits affect privilege or inheritance and should be applied only after checking who can write the object and its parent. A recursive command can unintentionally expose an entire tree or alter executable privilege boundaries.
Recursive changes without flattening a tree
chmod -R 0755 tree applies the same mode to every descendant, which is usually wrong for a project containing scripts, data, and secrets. When directories and files need different modes, target them separately:
find /srv/app -type d -exec chmod 0750 {} +
find /srv/app -type f -exec chmod 0640 {} +Review the result with find, ls -ld, and stat before changing production content. Preserve execute bits on scripts that truly need them, rather than granting execute to every regular file.
How umask determines new permissions
umask is a process setting used at creation time. The Linux umask(2) definition is precise: permission bits present in the umask are turned off from the mode requested by open(2) or mkdir(2). It is a bit mask, not ordinary decimal subtraction, and it can remove bits but cannot add permissions.
Most programs request 0666 for a regular file and 0777 for a directory, leaving the final decision to the umask. With umask 0022:
| Object | Requested mode | Bits removed by 0022 | Typical result |
|---|---|---|---|
| Regular file | 0666 | Group and others write | 0644 |
| Directory | 0777 | Group and others write | 0755 |
That is why a newly created file commonly appears as -rw-r--r-- while a new directory appears as drwxr-xr-x. The application may request a more restrictive mode, so the result is not guaranteed to be exactly those values.
Inspecting and setting the current umask
Run umask in a shell to display the current mask, normally in octal. umask 0022 changes it for that shell and processes it launches. A setting in an interactive shell does not automatically change an already-running service; configure the service’s own execution environment when a daemon needs a different policy.
Choosing a VPS umask
- 0022: a conservative general default. New files are normally owner-writable and readable by group and others; new directories are searchable by them.
- A group-collaboration mask: when a trusted team works through a shared group, use a mask that does not remove group write (commonly
0002) together with a setgid directory. Verify that other users should not receive the same access. - A private service mask: choose a mask that removes group and other access when the process handles secrets. Also check the application’s requested mode; a permissive umask cannot force a program to create files with permissions it never requested.
Do not treat umask as a complete security boundary. Ownership, directory modes, ACLs, application behavior, and the service account’s supplementary groups all matter.
Why a service can read a file but not enter its directory
To open /srv/app/config/settings.ini, the service must have search permission on /srv, /srv/app, and /srv/app/config, as well as read permission on the file. Read permission on settings.ini alone is insufficient. A parent directory can also block access even when the file’s mode looks correct.
Trace the path one component at a time
- Identify the service account with
ps, the service manager, or its unit configuration. - Inspect each component:
ls -ld /srv /srv/app /srv/app/config /srv/app/config/settings.ini. - Check the account’s groups with
id service-user; group permission applies only when the process is actually a member of that group. - Test as that identity, without changing ownership:
sudo -u service-user -- cat /srv/app/config/settings.ini. - Grant the narrowest missing search or read bit, then retest. Avoid making every parent directory world-searchable just to fix one service.
A directory can intentionally grant search without read, allowing access to a known path while hiding its name listing. This is useful in some deployments but should be documented because it can surprise operators.
Rank #4
Setgid directories for shared project files
Setgid on a directory makes newly created entries inherit the directory’s group instead of the creator’s primary group. It solves the recurring problem where two collaborators create files that are owned by different groups. Setgid does not make files group-writable by itself; the requested mode and umask still decide the group’s read/write bits.
Configure a shared project directory
- Create or choose a dedicated Unix group and add only the required users.
- Set the directory’s group ownership, for example
chgrp project-team /srv/project. - Apply setgid and suitable directory permissions:
chmod 2775 /srv/project. - Use a group-friendly umask for processes that create shared files, commonly
0002, and confirm that those processes run with the project group. - Create a test file as each relevant account and verify ownership and mode with
ls -landstat.
The 2 in 2775 is setgid; 775 gives the owner and group read/write/search and gives others read/search. Choose a more restrictive final digit when outsiders should not browse the project.
Sticky directories and safe shared-write areas
The sticky bit is different from setgid. On a writable directory, sticky limits rename and deletion: a file can be removed or renamed only by the file owner, the directory owner, or a privileged process. The Linux inode(7) documentation defines this protection explicitly.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitcheschmod 1777 /srv/drop creates a world-writable, world-searchable directory with sticky protection. Users can create entries, but they cannot delete or rename another user’s entries solely because the directory is writable. Sticky does not prevent a user from modifying a file that the file’s own mode grants them write access to, and it does not hide names. Use 1777 only for a deliberately public drop area; a private group directory is usually safer.
When ACLs override the simple umask calculation
Access control lists add entries for named users and groups and can include a default ACL on a directory. A parent default ACL changes the inherited permissions for new children, so the familiar “requested mode minus umask” calculation may not describe the final result. If a file’s mode appears inexplicable, inspect ACLs as well as mode bits.
Use getfacl path to display access and default ACL entries. An ACL’s mask entry limits effective permissions for named users, named groups, and the owning group; the mode shown by ls -l may therefore be only a summary. Change ACLs deliberately with tools such as setfacl, document why they exist, and retest as the actual service account.
Best Value
Practical permission patterns for VPS administration
| Situation | Directory approach | File approach | Key check |
|---|---|---|---|
| Private application data | Owner-only or owner/group search, such as 0700 or 0750 | Owner read/write, group read only where needed, such as 0600 or 0640 | The service account is in the intended group |
| Static web content | Usually searchable by the web-service account; avoid granting write to it | Readable by the web-service account, commonly 0644 when public exposure is intended | Uploads and secrets are outside the published tree |
| Trusted shared project | Setgid directory such as 2775, with a restricted group | Group-write modes plus a group-friendly umask when collaboration requires it | New entries retain the project group |
| Multi-user drop area | Sticky shared-write directory such as 1777 only when necessary | Per-file ownership and modes still control reading and writing | Users cannot remove one another’s entries |
These are starting points, not universal prescriptions. The correct mode depends on who must read, modify, execute, create, and delete data. Keep secrets outside publicly searchable paths, and grant access to a service group rather than making files world-writable.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Troubleshooting checklist
- New files are 0644 instead of group-writable: inspect the creator’s umask and the application’s requested mode; setgid changes group ownership, not write bits.
- A file is readable but the service gets “Permission denied”: check search permission on every parent directory and verify the service account’s groups.
- Collaborators create files with inconsistent groups: set the shared directory’s group and setgid bit, then verify group membership.
- Users delete one another’s files: apply sticky to the shared writable directory and ensure the directory itself is not unintentionally owned by an overly privileged account.
- Modes do not match the umask formula: inspect default and access ACLs with
getfacl, and check whether the program requested a restrictive mode. - A recursive fix caused outages: restore from a known-good permission manifest or backup, then apply separate file and directory modes instead of one blanket
chmod -R.
Security boundaries to verify before changing permissions
Ask which identities can reach the path, which identities can modify data, and whether a compromised account could replace configuration, scripts, or symlinks. Removing write permission from group and others is often more important than making a file executable. Review special bits separately, because setuid and setgid can cross privilege boundaries when an attacker can alter the executable or its containing directory.
After every change, test both the intended account and an account that should be denied. Record the owner, group, mode, ACLs, and umask used by automated jobs so a later deployment does not silently recreate weaker permissions.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
