Linux Users, Groups and Permissions

Every command runs with an identity. Linux uses that identity to decide which files the command may open and which settings it may change. A user account can represent a person or a service running in the background.

The number behind the name

The kernel identifies an account by its user ID (UID). Names such as alice make the number easier to recognize, but permissions follow the number. The root account has UID 0 and its home directory is /root. An account with another name and UID 0 has the same superuser power.

A regular user is a person's everyday account. On most distributions regular UIDs start at 1000; UID_MIN in /etc/login.defs sets that boundary. A regular user can change their own files and any other files the permissions allow. Changing protected system settings needs elevated rights.

A system account gives a service its own limited identity. Most have UIDs below 1000 and a shell such as /usr/sbin/nologin. The special account nobody commonly has UID 65534, so the range alone does not identify every service account. Debian and Ubuntu use www-data for web services; an SSH service may use sshd.

Read your current identity

Run whoami for your user name or id for the numbers and groups. For example:

uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo),1005(developers)

Read the output in three parts. Alice's UID is 1001. Her primary group is alice, GID 1001. Her group list also includes sudo and developers. She is a regular user, not root: the sudo group can authorize elevated commands, but her current shell still runs as Alice.

Many shells display # for root and $ for a regular user. A prompt can be customized, so inspect id when the identity matters. The first account created during installation is often a regular account with sudo access, including on Ubuntu; being created first does not make it root.

Check login sessions

These commands answer a different question from whoami: they report sessions, not just the identity of your shell. Debian 13 is one system that uses wtmpdb for its history.

Separate identities support least privilege, accountability and isolation. A web service can read the files it serves without getting every user's private documents. Logs can show which account acted. If the service is compromised, the attack begins with that service account's rights. Root can bypass ordinary file read and write restrictions, so a second UID 0 account is a serious security concern.

Sharing a file with a team is easier when the team has a group. Assign the file to that group, give the group the needed permissions, and manage membership as people join or leave.

One primary group, extra memberships

A group has a name and a numeric group ID (GID). Each user has one primary group, stored as a GID in /etc/passwd. A new file normally takes the creating process's primary group. Later, an SGID directory will provide another rule for assigning a new file's group.

Users can also have several supplementary groups. Those memberships add group identities to their processes; the user does not need to switch primary groups each time they open a different team's file. Both primary and supplementary groups count when Linux checks whether the user belongs to a file's group.

Most distributions create a user private group alongside each regular user. Alice may have user name alice, UID 1001, primary group alice and GID 1001. These are still separate user and group identities even when their names and numbers match. A file assigned to Alice's private group is not shared with the whole team.

Inspect a membership

Use groups for your own group names. groups bob and id bob query Bob's memberships; id -Gn prints the current process's group names without numbers. A group lookup might show:

getent group developers
developers:x:1005:alice,bob

The group is named developers, its GID is 1005, and Alice and Bob are listed as supplementary members. An account whose primary GID is 1005 belongs to the group too, even if its name is absent from that final list. To check a person's full membership, use id with their name instead of relying on that list alone.

Apply a group's permissions

Suppose plan.txt belongs to bob:developers and has mode rw-r-----. Alice is not Bob, but she belongs to developers. She therefore uses the middle permission triplet, r--: she can read the plan but cannot change its contents. Chen belongs to neither the owning user nor the group, so he uses the final triplet, ---.

Changing the group name attached to a file does not create permissions by itself. If its group triplet is ---, members still receive no access through that class. Group ownership identifies the team; the permission bits specify what the team can do.

Recognize powerful groups

Some memberships grant much more than access to a project folder. Debian and Ubuntu commonly authorize the sudo group for administrative commands; Fedora and Red Hat Enterprise Linux commonly use wheel. On Debian and Ubuntu, adm allows access to many system logs. The docker group controls the Docker service and effectively provides root-level control.

Before adding someone to a group, identify what it can reach. A project group can be a narrow way to share work, while an administrative group can grant control over the whole machine.

Linux keeps public account details separate from password data. Reading the field order helps you explain an account's identity, login setup and password policy without changing the files by hand.

Read an account record

/etc/passwd has seven colon-separated fields:

name:password:UID:GID:comment:home:shell
alice:x:1001:1001:Alice Moreau:/home/alice:/bin/bash

Alice's UID and primary GID are both 1001. The comment, also called the GECOS field, gives her full name. Her home is /home/alice, and her login shell is Bash. The x points to password data in /etc/shadow; it does not mean that her password is empty.

Ordinary users can read /etc/passwd, normally mode 644. Programs need its public details to turn stored UIDs into names. Keeping password hashes in a separate protected file prevents every local user from reading them.

Read password data

/etc/shadow has nine fields: name, password hash, last-change day, minimum age, maximum age, warning days, inactivity days, account-expiration day and a reserved field. Root can read it; some systems also grant access to the shadow group.

A password hash is a one-way result, not reversible encryption. At login the system applies the stored method and salt to the submitted password, then compares the result with the stored hash. A random salt makes the hashes differ even when two users choose the same password. SHA-512 crypt records use $6$salt$hash, optionally with a rounds=N field; yescrypt uses $y$parameters$salt$hash.

A leading ! locks the password while retaining the hash. A field containing only !, !! or * has no usable password. Other login methods, such as SSH keys, may still work with a locked password.

Work out the dates

Consider this shortened hash record:

alice:$y$j9T$...:20514:0:90:7:::

Dates count days since January 1, 1970, UTC. Day 20514 is March 2, 2026. A minimum age of 0 allows an immediate password change; a maximum of 90 means expiration on May 31, 2026. The seven-day warning begins May 24. Empty inactivity and account-expiration fields set neither limit. A last-change value of 0 forces a change at next login; a maximum of 99999 is effectively a very long password lifetime. Password expiration and account expiration are separate fields.

Read group records safely

/etc/group uses name:password:GID:members. In developers:x:1005:alice,bob, the final field lists supplementary members. Primary members are found through the GID in their passwd records. Protected /etc/gshadow stores group password and administrator data.

Use getent passwd alice or getent group developers for lookups. getent consults configured account sources as well as local files. cut -d: -f1,3 /etc/passwd displays local names and UIDs. Change records with account commands such as usermod and passwd; if direct editing is unavoidable, vipw and vigr lock the files during the edit.

Administrative tasks need more access than everyday work. Keep your usual shell under your own account, and raise privileges for the action that needs them. Files created by an elevated command can belong to root even when they are inside your home directory.

Choose sudo or su

A login shell loads the target user's login environment, including the home directory and startup files. Use exit to leave a shell started by su. sudo -i opens a root login shell; sudo -s opens a root shell. These are useful for a series of related administrative tasks, but every command in that shell has elevated power until you exit.

Sudo checks its policy before running the command and records the attempt. Logs may go to the system journal, /var/log/auth.log on Debian-family systems, or /var/log/secure on Red Hat-family systems. sudo -l shows the commands your account may run. Permission to use sudo is a policy decision, not a result of knowing somebody else's password.

Understand authentication

By default, sudo asks for the invoking user's password, not root's. Policy can change that behavior. Upstream sudo's authentication timestamp lasts five minutes by default; distribution settings can use another value, such as 15 minutes. The timestamp normally applies within that terminal. Run sudo -k to invalidate it when you finish.

Ubuntu normally starts with no usable root password and puts the installation user in sudo. Fedora and Red Hat-family systems commonly use wheel. A denied attempt can report that the user is not in the sudoers file; the attempt is logged.

Put the write operation under sudo

This command fails when your ordinary account cannot write /etc/hosts:

sudo echo "192.0.2.10 test.local" >> /etc/hosts

Your current shell opens the file for >> before sudo runs. Only echo receives root rights, and echo is not the program opening the destination. Give the writing job to an elevated process:

echo "192.0.2.10 test.local" | sudo tee -a /etc/hosts

Here tee opens the protected file as root. Its -a option appends; leaving that option out would replace the file's contents. For an interactive edit, sudoedit /etc/hosts, also written sudo -e /etc/hosts, runs your editor as you and handles the protected-file update.

Notice root-owned work

After sudo mkdir ~/project, inspect the result with ls -ld ~/project. The directory is in your home, but it was created by root. Its owner permissions therefore apply to root, while your account may have only read and execute access. Restore the intended owner with sudo chown alice: ~/project when Alice owns the project. The trailing colon also selects Alice's login group. Ordinary editing and file creation can then run under Alice's account.

A sudo rule decides who may run an action, on which host, and under which identity. Giving a team one administrative action can meet its needs without granting unrestricted control over the machine.

Read the parts of a rule

The basic pattern is who where = (as_whom) what. For example:

alice ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL

The first rule lets Alice run any command on any host as any user and group. The second grants the same rights to the sudo group; % marks a group name. A common Red Hat-family rule is %wheel ALL=(ALL) ALL.

To make Alice a full administrator through an existing distribution rule, run sudo usermod -aG sudo alice on Debian or Ubuntu, or use wheel on Fedora and related systems. Alice needs a new login for the membership to reach her session. The -a matters: without it, -G replaces her other supplementary groups.

Edit and check the policy

The main file is /etc/sudoers; additional rules can live in /etc/sudoers.d/. Use sudo visudo or a focused file:

sudo visudo -f /etc/sudoers.d/webteam

visudo locks the policy file during editing and checks its syntax before saving. A broken policy can leave administrators unable to use sudo. Name the file webteam, not webteam.conf: sudo's included-directory handling skips names containing a dot or ending in ~.

Files in the included directory are read in name order. When several rules match, the last matching rule controls the result; the most specific-looking rule does not necessarily win. The include is normally near the end of the main policy, so an extra file can affect a rule written earlier.

Grant one exact action

A team that maintains a web service might receive:

%webteam ALL=(root) /usr/bin/systemctl restart nginx

A member can run sudo systemctl restart nginx. The rule specifies the full command path and its arguments. It does not authorize systemctl stop nginx or bash. Check effective permissions with sudo -l; an administrator can inspect Bob's policy with sudo -l -U bob.

The allowed program also matters. A root shell can do anything. Editors and pagers may start shells, and unrestricted cp or tee can overwrite protected configuration. An apparently short command list can therefore grant full control.

Decide whether a password is needed

NOPASSWD: removes the authentication prompt for a matching command:

backup ALL=(root) NOPASSWD: /usr/local/bin/backup.sh

This can support an automated job. The script must be controlled by root: if backup can rewrite it, the account can replace its contents with any root command. Keep the permitted action narrow as well as protecting the script.

Defaults lines change policy settings. Defaults timestamp_timeout=10 sets a ten-minute authentication timestamp; Defaults logfile=/var/log/sudo.log selects an additional log file. These settings control sudo's behavior, while command rules control the actions it authorizes.

Creating an account sets up an identity, a login environment and often a home directory. Choosing the options explicitly makes the result predictable across distributions.

Build a regular account

Suppose the group developers already exists. Create Priya's account and set her password in two commands:

sudo useradd -m -s /bin/bash -c "Priya Shah" -G developers priya
sudo passwd priya

-m creates /home/priya and copies the initial files from /etc/skel. -s /bin/bash selects Bash as the login shell, and -c supplies the comment. -G developers adds a supplementary membership; several group names form a comma-separated list without spaces. The account normally also receives a private primary group.

The first command adds account records to /etc/passwd and /etc/shadow, and group records as needed to /etc/group and /etc/gshadow. Its initial password field is locked, often ! or !!. The account exists before it has a usable password. passwd priya sets that password; its prompt keeps the password out of the command line.

Understand distribution defaults

useradd is the low-level account creation command used across Linux distributions. Debian and Ubuntu also provide an interactive adduser script that asks for details and creates a home. On Red Hat-family systems, adduser is another name for useradd, so it does not provide the same interactive workflow.

Without explicit options, useradd depends on local defaults. Red Hat-family defaults commonly create a home; Debian and Ubuntu defaults do not unless -m is supplied. The default shell may also differ. Inspect useradd -D for defaults such as the home base and shell. /etc/default/useradd and /etc/login.defs provide settings including UID ranges, private groups and password aging.

Supply a different home or identity

Useful options describe separate parts of the account:

A home path in the record does not itself create the directory. Combine -d with -m when the new home must be created. On Debian, omitting -m can leave an otherwise valid account with no home directory to use at login.

For a service identity, sudo useradd -r -s /usr/sbin/nologin backupsvc requests a system UID and a noninteractive shell. System accounts have no home by default. The nologin shell prevents an ordinary interactive shell login under that identity.

Verify the setup

Run getent passwd priya, id priya and ls -la /home/priya. Check the home path, shell, primary group, extra groups and copied hidden files. /etc/skel is a template: adding .bash_aliases there affects later home creation, not homes that already exist. Use simple lowercase account names with digits, hyphens or underscores after the initial letter; spaces and unusual names are rejected or mishandled by many tools.

An account can need a new password, a different home, a temporary access block or permanent removal. These operations change different parts of the account, so identify the intended result before choosing a command.

Change or age a password

Run passwd to change your own password, normally after entering the current one. An administrator uses sudo passwd priya to set Priya's password without knowing the old one. Password-quality checks may reject short or simple choices.

sudo passwd -S priya reports password status. sudo passwd -l priya locks the password by placing ! before its hash, and sudo passwd -u priya unlocks it. sudo passwd -e priya expires the password so the user must choose another at the next login. Expiring a password is useful when issuing a temporary one.

Use sudo chage -l priya to inspect aging dates. For example:

sudo chage -M 90 -m 1 -W 7 priya

The maximum age is 90 days, the minimum between changes is one day, and warnings begin seven days before expiration. These values go into /etc/shadow. sudo chage -E 2026-12-31 priya sets the expiration date of the whole account, separately from its password lifetime.

Block access without deleting records

A password lock blocks password authentication. It does not remove SSH keys or stop every other authentication method. To disable a departing user's future account logins, lock the password and set a past account-expiration date, such as sudo usermod -e 1 priya. The value 1 is a day count in January 1970, so that date is already past. This does not terminate processes that are already running; those need separate attention.

Modify an existing account

usermod can change the comment with -c, the shell with -s, and the home path with -d. Combine -d and -m to move home contents, as in sudo usermod -d /data/priya -m priya. -l newname changes the login name, but the home and private group keep their existing names unless changed too. -L and -U lock and unlock the password.

To add a supplementary membership, run sudo usermod -aG developers priya. The -a means append. Without it, usermod -G developers priya replaces Priya's entire supplementary list; a previous sudo membership can disappear. Her primary group is a separate setting controlled by -g.

Remove the account and handle its files

sudo userdel priya deletes the account records but leaves the home. sudo userdel -r priya also removes the home and mail spool. The normal command refuses removal while the user still has running processes.

Files elsewhere retain their numeric owner UID. After account deletion, a listing may show 1003 as owner because no name maps to it. Reusing that UID for a new account gives that account ownership of the old files. Use sudo find / -nouser to locate files with no matching user, then archive or reassign them. For a departure, block future logins first, handle running activity and preserve needed files, then delete the account when those tasks are complete.

A shared folder needs a group, members, and directory permissions that let those members work. The account database and the groups held by an already running shell can temporarily disagree after a membership change.

Create and maintain the group

sudo groupadd developers assigns the next available GID. Add -g 1500 to choose a specific GID or -r for a system group. Check with getent group developers; an empty final field means no supplementary members are listed yet.

Add a member with either command:

sudo usermod -aG developers priya
sudo gpasswd -a priya developers

sudo gpasswd -d priya developers removes that supplementary membership. sudo gpasswd -M alice,bob developers sets the entire member list, replacing what was there. Choose append, remove or replace according to the intended change.

Refresh a session's groups

After adding Priya, id priya queries the account database and shows the new membership immediately. Plain id in her existing shell reports the groups that shell is actually using. Those were established when the session began.

A new login loads the new list. newgrp developers offers another route: it starts a new shell with developers as the primary group. Use exit to leave that shell. When diagnosing a denied operation, inspect the identity in the session attempting the operation, not just the database entry.

Rename or delete a group

sudo groupmod -n devteam developers changes the name but keeps the GID. Existing files continue to refer to the same numeric group. In contrast, sudo groupmod -g 1600 developers changes the group's number. Files still carrying the old GID 1005 need attention; locate them with sudo find / -gid 1005, then use chgrp to assign the intended group.

sudo groupdel developers refuses if an existing user still has it as their primary group. Set another primary group with usermod -g before deleting it. Deleting a group name does not erase files carrying its former GID.

Set up a team folder

For Priya and Kenji's web team:

sudo groupadd webteam
sudo usermod -aG webteam priya
sudo usermod -aG webteam kenji
sudo mkdir /srv/web
sudo chgrp webteam /srv/web
sudo chmod 2770 /srv/web

After fresh logins, both users can create files in /srv/web. Mode 2770 gives owner and group rwx, others ---, and sets directory SGID. A new file takes group webteam, even when its creator's primary group is their private group. New subdirectories also inherit SGID.

The directory makes team membership useful and keeps others from entering, but each file still has its own mode. With a usual file request of 666, a creator's umask of 002 gives group write, while 022 leaves the group read-only. If team members need to edit each other's files, check these creation defaults as well as the folder.

A long listing places the information needed for an access decision on one line. Read the owner and group together with the nine permission bits; the bits alone do not tell you which rights a particular person receives.

Decode a long listing

-rw-r----- 1 priya developers 2048 Oct 22 09:15 report.txt

The first field is the file type plus permissions. The following fields give the hard-link count, owning user, owning group, size in bytes, modification time and name. This regular file belongs to Priya and the developers group. The size is 2048 bytes; the displayed time records the last content modification.

The first character is - for a regular file, d for a directory or l for a symbolic link. You may also meet c and b for character and block devices, p for a named pipe, and s for a socket.

Split the next nine positions into three triplets:

Within every triplet, the positions mean read, write and execute, in that order. A dash marks a missing permission, not an empty slot to skip when counting.

Choose exactly one class

For an ordinary permission check, Linux asks:

1. Does the process's user match the file owner? Use the owner triplet.
2. Otherwise, does one of its groups match the file's group? Use the group triplet.
3. Otherwise, use the others triplet.

The classes do not add together. Suppose Priya owns a file whose full type-and-mode string is ----rw-rw-. Her owner triplet is ---, so she cannot read it through the ordinary bits, even though group and others have rw-. As owner she can change the mode. A less restrictive group or others triplet does not override the selected owner's triplet.

Root can bypass ordinary read and write permission checks. To execute a regular program file, even root needs at least one execute bit on it. A mode check therefore needs both the user's identity and the operation being attempted.

Inspect directories and numbers

ls -ld /srv/web lists the directory itself. Without -d, ls -l /srv/web normally lists entries inside it, which can distract you from a restriction on the directory. ls -a includes hidden names, while ls -n displays numeric owners and groups. Files store UIDs and GIDs; if an account or group has been deleted, an ordinary listing can show the remaining number too.

For a compact report, run:

stat -c '%A %a %U %G %n' report.txt

It can show -rw-r----- 640 priya developers report.txt, placing letters and octal digits side by side. A + after the letters signals extra access-control-list entries. A symbolic link commonly displays lrwxrwxrwx; Linux uses the target's permissions for access, not those displayed link bits.

Read, write and execute describe different actions on files and directories. A directory stores names leading to files, so changing a file's contents and removing its name are different permission checks.

Match the bit to the object

A file with write permission but no read permission can be appended to without being read. For example, a shell can open a writable log for echo text >> log.txt even when cat log.txt fails. An editor often needs both read and write because it first loads the existing contents.

A script run as ./backup.sh needs execute permission and must be readable by its interpreter. If the script is readable but lacks execute, bash backup.sh can still read and run it: Bash is the executable program in that command.

Separate listing from searching

Directory read permission lets you see names. Directory execute, also called search permission, lets you reach an entry by name. With read but no execute, ls can show names, while ls -l cannot obtain their details and may display errors and question marks. You cannot open the named files through that directory.

With execute but no read, the reverse is possible: you can reach notes.txt if you already know its exact name, but cannot list the directory to discover the names. The file's own mode must still allow the requested access.

Trace the whole path

To read /home/priya/notes/public.txt, Kenji needs execute permission on every directory in the path and read permission on the file. If /home/priya is mode 700, its others triplet is ---; Kenji stops there even if public.txt is mode 644. Adding more read permission to the file cannot repair a missing directory search bit above it.

Use ls -ld /home/priya /home/priya/notes to inspect the directories themselves. At each level, choose the class that applies to Kenji and check its execute bit. The relevant class can change from one directory to the next because their owners and groups can differ.

Predict deletion and renaming

Deleting a file removes a directory entry. Kenji needs write and execute on the containing directory, not write on the file. In an ordinary writable directory without the sticky bit, he can remove Priya's read-only file. Conversely, owning a file does not let him delete it from a directory where he lacks write permission.

Removing file write is therefore useful for protecting contents from edits, but it does not protect the name from removal. A directory's sticky bit adds an ownership restriction on deletion and renaming in shared writable folders. File access and directory-entry access answer separate questions.

Use chmod to change the permissions of a file or directory you own. Root can change them too. Having write access through a group lets you change file contents, but does not make you the owner or let you set its mode.

Make a focused symbolic change

A symbolic mode has a class, an operator and bits. The classes are u for owner, g for group, o for others and a for all three. + adds permissions, - removes them and = sets that class exactly.

chmod u+x deploy.sh
chmod go-w notes.txt
chmod u=rw,g=r,o= report.txt

The first command adds only the owner's execute bit. The second removes group and others write while retaining their other bits. The third gives the owner read/write, the group read, and others no permissions: rw-r-----.

Specify the class when you want a precise change. If you omit it, as in chmod +w notes.txt, the umask restricts which class bits are affected. With umask 022, that command adds write for the owner only; chmod a+w notes.txt explicitly includes all three classes.

Convert each triplet to an octal digit

Read has value 4, write 2 and execute 1. Add the values present in each class:

For rw-r-----, split into rw-, r--, ---: the digits are 6, 4, 0. chmod 640 report.txt sets those nine ordinary bits, regardless of the previous ordinary mode. Reverse the process for 750: 7 gives rwx, 5 gives r-x, and 0 gives ---, forming rwxr-x---.

Choose a useful final mode

Mode 600 keeps a file private to its owner. Mode 644 lets other users read an ordinary file. Mode 664 also lets the group edit. Private directories commonly use 700, group-readable directories 750, and group-writable directories 770. Programs or public directories commonly use 755.

The same digits mean different useful actions on different objects. Applying 644 to a directory removes execute from every class. Even its owner can no longer enter it or open files through it. Use a directory mode with search permission for the people who need access.

Apply changes through a tree

chmod -R 755 site/ also makes every ordinary file executable. For a tree containing directories and ordinary documents, use conditional execute:

chmod -R u=rwX,go=rX site/

Capital X adds execute to directories and to files that already have an execute bit. Non-executable files become 644; directories become 755. Existing executable files retain execute access. This keeps traversal possible without marking every document as a program. Special bits are separate: GNU chmod preserves directory SUID and SGID unless you explicitly clear them, such as with chmod g-s site/.

Ownership identifies the user and group whose permission triplets will be checked. Correct ownership can fix a working folder that was accidentally created with sudo, without granting broader access to everybody else.

Read the chown forms

chown can change a user, a group or both:

Numeric IDs work too, as in sudo chown 1002:1005 report.txt. The names are resolved to numbers; the file stores those numbers.

Only root can transfer a file to another owning user. An owner can change their own file's group to a group they belong to. Thus Priya can use chgrp webteam plan.txt if she owns the file and belongs to webteam. Membership in finance would also be required to assign it to that group. Another member's ability to edit the file does not grant the ability to change its owner or mode.

Repair an accidental root-owned folder

Kenji ran a creation command with sudo. The listing is:

drwxr-xr-x 2 root root 4096 Oct 22 10:02 /home/kenji/app

He is not the owner and is not using the owning group, so he receives others' r-x. He can inspect and enter the folder, but cannot create entries because write is missing. Making the folder writable by everyone would grant more access than his project needs.

If the project belongs to Kenji, sudo chown -R kenji: ~/app restores his ownership and login group throughout it. His owner triplet is now rwx, so he can create files. Inspect the target path before any recursive ownership command: applying it to /etc or /usr can break system operation. -R means the directory and everything beneath it.

Predict ownership after file operations

A newly created file belongs to the creating process's user. Its group normally comes from that process's primary group, or from an SGID parent directory. Creating an ordinary new copy with cp therefore makes the caller its owner. A same-file-system mv changes the location of an existing file and keeps its owner and group. Copy options that preserve ownership are a separate behavior from an ordinary new copy.

This distinction explains why moving an old file into a shared folder does not apply that folder's group-inheritance rule to it. SGID applies at creation; use chgrp when an existing file's group needs changing.

Combine identity with access

Assigning webteam with chgrp selects who the group class represents. It does not add group read or write. Use chmod to grant the required bits after choosing the group. Changing ownership of an executable can also clear SUID or SGID privileges; inspect its resulting mode when those bits matter.

The permissions on a new file come from two inputs: the mode its creating program requests and the process's umask. The mask removes requested bits; it never adds permissions the program did not ask for.

Start with the creation request

Editors and shell redirection usually request 666, or rw-rw-rw-, for ordinary new files. Directory creation usually requests 777, or rwxrwxrwx. A umask is a set of bits to clear from that request. A bit survives only when the request includes it and the mask does not.

For umask 022, keep all requested owner bits, remove group write, and remove others write. A file becomes 644; a directory becomes 755. Read each digit as bits, not as an ordinary decimal amount.

With 027, the group loses write while others lose all three bits. It is useful when a team should read new files but users outside the team should have no access. With 002, group write remains available; the file's owning group still determines who receives it.

Why subtraction fails

Take the file request 666 and mask 033. Each 3 means write plus execute. But each requested file triplet is rw-: execute is already absent. Clearing write and execute leaves r-- for group and others, so the result is 644. Subtracting digits would produce 633, which wrongly suggests execute bits can appear.

For a directory request of 777, clearing those same bits gives 744. That directory lacks group and others execute, so those classes cannot reach its entries even though they can list names. A mask that gives the desired file mode may have an inconvenient directory result.

Inspect and set your mask

Run umask to see the current setting, often displayed with a leading zero, such as 0022. The leading zero is formatting; Linux uses the nine ordinary permission bits. umask -S prints allowed bits, such as u=rwx,g=rx,o=rx for 022; a program can request a subset of those bits.

umask 027 changes the current shell and is inherited by programs it starts. Existing files keep their modes. Use chmod when an already created file needs different rights.

Choose a persistent default

A line such as umask 027 in ~/.profile or ~/.bashrc can set the value for the shells that read that startup file. System defaults can come from /etc/profile or UMASK in /etc/login.defs. Distribution and account setup determine which files are read and when.

Many systems use 022, while private-group setups often use 002 for regular users. A compiler can request executable output with mode 777; under 022 it becomes 755. A text editor's request of 666 has no execute bits, so writing a script does not itself make that script executable.

Three special bits add behavior beyond the ordinary owner, group and others permissions. Their meaning depends on whether the object is a program or a directory.

Recognize the extra digit

A leading octal digit combines SUID 4, SGID 2 and sticky 1. Mode 4755 is SUID plus ordinary mode 755. Mode 2770 is SGID plus 770. Mode 3770 combines SGID and sticky because 2 plus 1 is 3.

In a long listing, the bits share execute positions. Lowercase s in the owner slot means SUID and owner execute; lowercase s in the group slot means SGID and group execute. A lowercase t in the others slot means sticky and others execute. Uppercase S or T means the special bit is present but execute in that position is absent.

SUID and SGID on programs

SUID lets an executable run with its file owner's effective identity. /usr/bin/passwd commonly appears as -rwsr-xr-x root root: the program can update protected password data while enforcing which user's password the caller may change. Starting it does not give the caller a root shell. Linux ignores SUID on scripts and directories.

SGID on an executable similarly uses the file's group identity. These bits grant program-controlled access, so the program's behavior matters. Never add SUID to a shell, editor or script. An administrator can inventory SUID regular files with sudo find / -perm -4000 -type f 2>/dev/null; use -perm -2000 for SGID files and compare results with the expected system setup.

SGID on a team directory

On a directory, SGID makes new entries take the directory's group, and new subdirectories inherit SGID. Suppose /srv/web belongs to root:webteam, mode 2770, displayed as drwxrws---. Priya has a private primary group but belongs to webteam. When she creates index.html inside this directory, its group becomes webteam.

Its ordinary mode still depends on creation. With a file request of 666 and umask 002, it becomes 664 and Kenji, another team member, can edit it. With 022 it becomes 644, so Kenji has read access only. SGID supplies the group, not an extra write bit.

Sticky directories and deletion

The sticky bit restricts deletion and renaming: with the needed directory access, an entry can be removed by its file owner, the directory owner or root. This makes shared writable directories useful without letting users remove each other's entries. /tmp and /var/tmp commonly use 1777, displayed as drwxrwxrwt. Sticky does not prevent edits to file contents when the file mode permits them. Linux ignores it on regular files.

Set bits with chmod u+s prog, chmod g+s /srv/web or chmod o+t /srv/drop. Clear them with u-s, g-s or o-t. With GNU chmod, chmod 755 /srv/web preserves an existing directory SGID bit; use chmod g-s /srv/web to clear it explicitly.

A "Permission denied" error identifies a failed operation, not necessarily a bad file mode. The block may be your session's groups, a parent directory, the file itself or ownership left by an elevated command.

Trace identity, path, class and operation

Start with plain id in the affected session. If a group was recently added, compare the active list with id username, which queries the database. A fresh login can load the new membership.

Next inspect the entire path:

namei -l /srv/reports/q3.txt

namei -l reports owners, groups and modes along the path. You can also inspect each directory with ls -ld. At every object, select the first matching class: owner, otherwise group, otherwise others. Then ask what the attempted operation needs. Reading needs file r and search permission on all parent directories. Creating, removing or renaming an entry needs w and x on its directory, with sticky restrictions where present.

Find the first blocked operation

Kenji belongs to finance and tries cat /srv/reports/q3.txt. The relevant objects are:

drwxr-xr-x root  root     /srv
drwxr-x--- root  finance  /srv/reports
-rw------- maria finance  /srv/reports/q3.txt

Kenji can pass through /srv using others execute. In /srv/reports, his finance membership selects group r-x, so he can pass through there too. On q3.txt, he is not Maria, and the finance triplet is ---. The missing permission is file group read.

If finance members should read the report, Maria or root can run chmod g+r /srv/reports/q3.txt. The resulting mode is 640. It supplies the missing right without giving the group write or opening the report to others. An administrator can test with sudo -u kenji cat /srv/reports/q3.txt, running the command as Kenji rather than testing it as root.

Choose the smallest repair

A correct fix may be adding a team membership, setting group read, restoring a project's owner or adding directory search for the intended class. chmod -R 777 hands every local account write access throughout the tree and makes ordinary files executable. It also cannot solve every cause of an access failure.

Check common causes before editing a large tree: inactive new membership, missing parent x, root-owned work created with sudo, and new files whose umask removed needed team access. FAT32 and exFAT drives do not store native Linux UIDs, GIDs and modes; mount options supply those values, so per-file chmod or chown can fail or have no effect.

Keep private data private

An SSH private key such as ~/.ssh/id_ed25519 should normally be mode 600; its .ssh directory is usually 700. SSH checks private-key protection and can reject an overly accessible key. /etc/shadow remains inaccessible to ordinary users. Full sudo administrators can bypass ordinary file privacy, so keep that group small and grant specific actions when full administration is unnecessary.