What does chmod 755 mean in Linux?

Mode 755 gives the owner read, write and execute permissions. Group members and other users receive read and execute permissions but cannot modify the file.

What is the difference between chmod and chown?

`chmod` changes a file's permission bits, such as read, write and execute. `chown` changes the user owner, group owner or both.

Why does a user get permission denied when the file is readable?

The user may lack execute permission on a parent directory, or an ACL mask may restrict access. A read-only mount, SELinux policy or application control can also cause the denial.

What permissions should an SSH private key have?

An SSH private key should normally use mode `600`, allowing only its owner to read and modify it. The user's `.ssh` directory is commonly set to `700`.

What is the difference between 644 and 755 permissions?

Mode 644 gives the owner read and write access while everyone else receives read access. Mode 755 also adds execute permission for the owner, group and others, making it suitable for many executable files and traversable directories.

Why should chmod 777 usually be avoided?

Mode 777 allows every local user to read, modify and execute the target. It weakens least-privilege controls and often hides an underlying ownership, group membership or service configuration problem.

Linux File Permissions and Ownership Explained

Linux controls access to files and directories through ownership and permission rules. Understanding these rules is essential when administering servers, securing application files, deploying code or troubleshooting services.

These skills are regularly used in cloud and automation roles. For example, learners in an AWS DevOps course must manage SSH keys, deployment scripts, log directories, configuration files and service accounts without granting unnecessary access.

What are Linux file permissions?

Linux file permissions determine who can read, modify or execute a file. Every file and directory has an owner, a group owner and permission settings for the owner, group members and everyone else.

The three basic permissions are:

Permission	Symbol	Numeric value	Meaning for files	Meaning for directories
Read	`r`	4	View file contents	List directory entries
Write	`w`	2	Modify file contents	Create, delete or rename entries
Execute	`x`	1	Run the file as a program or script	Enter and traverse the directory

A useful diagram-in-words is:

File or directory
|
+-- Owner: the user who owns it
|   +-- read, write, execute
|
+-- Group: users belonging to its assigned group
|   +-- read, write, execute
|
+-- Others: all remaining users
    +-- read, write, execute

Linux evaluates the matching class. If you own the file, the owner permissions apply. Linux does not fall through to group permissions just because the owner permissions are more restrictive.

How do you read permission output from ls -l?

The ls -l command displays the file type, permission bits, owner and group. Its first field can be divided into one file-type character followed by three permission groups.

Run:

ls -l deploy.sh

Example output:

-rwxr-x--- 1 arun devops 842 Sep  8 10:30 deploy.sh

Read the important fields from left to right:

-  rwx  r-x  ---   arun   devops   deploy.sh
|   |    |    |      |       |
|   |    |    |      |       +-- Group owner
|   |    |    |      +---------- User owner
|   |    |    +----------------- Others permissions
|   |    +---------------------- Group permissions
|   +--------------------------- Owner permissions
+------------------------------- File type

In this example:

- means it is a regular file.
rwx allows the owner, arun, to read, write and execute it.
r-x allows members of devops to read and execute it.
--- denies access to other users.

Common file-type characters include:

Character	File type
`-`	Regular file
`d`	Directory
`l`	Symbolic link
`b`	Block device
`c`	Character device
`s`	Socket
`p`	Named pipe

Use stat when you need a more detailed view:

stat deploy.sh

Typical fields include the numeric mode, user ID, group ID and access, modification and metadata-change timestamps.

What do permissions mean on a directory?

Directory permissions control access to directory entries rather than the contents of one ordinary file. Read, write and execute therefore behave differently on directories.

Consider a directory named /srv/app:

Read permission allows a user to list its filenames.
Write permission allows a user to create, delete or rename directory entries.
Execute permission allows a user to enter the directory and access entries by name.

A user with read but no execute permission may see names with ls, but cannot reliably inspect or open the entries. A user with execute but no read permission cannot list all names, but may access a known filename if that file's own permissions allow it.

Deletion is controlled mainly by permissions on the parent directory. A user may be able to delete a read-only file if the user has write and execute permission on its parent directory, unless protections such as the sticky bit apply.

How do you change Linux file permissions with chmod?

Use chmod to modify permission bits. Permissions can be expressed with symbolic notation for readable changes or octal notation for setting a complete mode.

Symbolic mode

The symbolic classes are u for owner, g for group, o for others and a for all classes.

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

The operators have specific meanings:

Operator	Action
`+`	Add a permission
`-`	Remove a permission
`=`	Replace the selected class's permissions

For example, this grants group read and execute permission without changing owner or other permissions:

chmod g+rx deploy.sh

Octal mode

Octal notation adds the values for each permission class:

read    = 4
write   = 2
execute = 1

The common combinations are:

Number	Permissions	Meaning
7	`rwx`	Read, write and execute
6	`rw-`	Read and write
5	`r-x`	Read and execute
4	`r--`	Read only
0	`---`	No permission

Therefore, chmod 640 report.txt produces:

Owner: 6 = read + write
Group: 4 = read
Others: 0 = no access

Run:

chmod 640 report.txt
ls -l report.txt

Expected result:

-rw-r----- 1 arun finance 1250 Sep  8 11:00 report.txt

Typical modes include 600 for private files, 644 for non-executable documents, 700 for private scripts or directories, and 755 for publicly traversable directories and executable programs. These are conventions, not universal rules; choose permissions according to the required access.

How are default permissions calculated with umask?

The umask removes permissions from the base mode used when a process creates a file or directory. Regular files normally start from 666, while directories start from 777 because directories need execute permission for traversal.

Check the current value:

umask

If the result is 0022, the common defaults are:

Files:       666 with mask 022 removed = 644
Directories: 777 with mask 022 removed = 755

With a more restrictive 0027 mask:

Files:       640
Directories: 750

Set a mask for the current shell with:

umask 027

A common mistake is treating the calculation as normal arithmetic subtraction in every case. The accurate model is bit removal: any permission selected by the mask is cleared from the base mode.

Services may define their own UMask setting, and applications can request explicit modes. When troubleshooting defaults, check the shell profile, service configuration and application behaviour rather than assuming the interactive shell's mask applies everywhere.

How do Linux file ownership commands work?

Every file has one user owner and one group owner. Use chown to change ownership and chgrp to change only the assigned group.

View the current values:

ls -l app.conf

Change both owner and group:

sudo chown appuser:devops app.conf

Change only the owner:

sudo chown appuser app.conf

Change only the group:

sudo chgrp devops app.conf

Apply ownership recursively only when the entire directory tree should have the same ownership policy:

sudo chown -R appuser:devops /srv/app

Changing a file's user owner normally requires root privileges or the relevant capability. A file owner may be allowed to change its group to a group of which that user is a member, depending on system rules.

Avoid applying recursive commands to broad system paths. Before running chown -R or chmod -R, verify the target with pwd, realpath and ls.

How do special permission bits work?

Linux provides setuid, setgid and sticky bits for specific access requirements. These bits should be assigned only after understanding their security effect.

Special bit	Numeric prefix	Typical purpose
setuid	4	Run an executable with the file owner's effective user ID
setgid	2	Run with the file's group ID, or inherit a directory's group
sticky	1	Restrict deletion within a shared directory

setuid

An executable with setuid runs with the effective user ID of its owner:

chmod 4755 program

The owner execute position appears as s:

-rwsr-xr-x

Setuid creates security risk if the executable is vulnerable. Linux also commonly ignores setuid on shell scripts.

setgid on shared directories

Setgid is especially useful for team directories because new entries inherit the directory's group:

sudo chown root:devops /srv/app
sudo chmod 2770 /srv/app

The result resembles:

drwxrws--- root devops /srv/app

New files created inside /srv/app inherit the devops group. Their final permission bits still depend on the creating process and its umask.

Sticky bit

Shared writable directories such as /tmp use the sticky bit:

chmod 1777 shared-directory

Users can create files, but they cannot normally delete or rename another user's entries. The other execute position appears as t, as in drwxrwxrwt.

When should you use Linux ACLs?

Access Control Lists provide permissions for additional named users or groups without changing the file's primary owner and group. They are useful when the standard owner-group-others model cannot express a legitimate access requirement.

Grant user meera read access:

setfacl -m u:meera:r report.txt
getfacl report.txt

Remove that ACL entry:

setfacl -x u:meera report.txt

Set a default ACL for new entries in a directory:

setfacl -m d:g:devops:rwx /srv/app

An ACL-enabled file normally shows a plus sign after its mode:

-rw-r-----+ 1 arun finance 1250 Sep 8 11:00 report.txt

Check the ACL mask when an entry appears correct but effective access is restricted. In getfacl output, the mask limits the effective rights of named users, named groups and the owning group.

ACLs support least-privilege administration, an important topic in the Cybersecurity and SOC course. They are generally safer than opening a file to all users with mode 777.

How can you build a shared project directory?

A secure shared directory needs a dedicated group, controlled membership, setgid inheritance and suitable default permissions. The following lab allows team members to collaborate without making the directory public.

Create the group and add an existing user:

sudo groupadd devops
sudo usermod -aG devops arun

Create and configure the directory:

sudo mkdir -p /srv/app
sudo chown root:devops /srv/app
sudo chmod 2770 /srv/app
ls -ld /srv/app

Expected mode:

drwxrws--- 2 root devops 4096 Sep 8 12:00 /srv/app

The user must start a new login session or run newgrp devops before the new supplementary group is available. Confirm membership with:

id arun

For collaborative files that should remain group-writable, users can use umask 002 or the administrator can define suitable default ACLs. Test access as the actual service or application account rather than testing only with sudo.

For a wider Linux administration study sequence, see the RHCSA syllabus and realistic study plan.

How do you troubleshoot permission denied errors?

Start by identifying the process user, checking every directory in the path and confirming ACLs. If Unix permissions are correct, investigate read-only mounts, SELinux policy and application-specific restrictions.

Step 1: Confirm the active identity

whoami
id

A recently added group may not appear until the user starts a new session.

Step 2: Inspect the target and full path

ls -l /srv/app/config.yml
namei -l /srv/app/config.yml

namei -l displays permissions and ownership for every path component. Missing execute permission on any parent directory can block access even when the file itself is readable.

Step 3: Check ACLs

getfacl /srv/app/config.yml

Look for named entries and the ACL mask. A displayed effective: value shows when the mask reduces an entry's permissions.

Step 4: Test as the service account

sudo -u appuser cat /srv/app/config.yml

This is more reliable than testing as root because root can bypass many discretionary permission checks.

Step 5: Check the filesystem and SELinux

findmnt /srv/app
getenforce
ls -Z /srv/app/config.yml

A read-only mount prevents writes regardless of chmod. On SELinux-enabled systems, a wrong security context can deny access even when standard Linux file permissions appear correct; inspect audit logs before changing or disabling policy.

Common mistakes

Problem	Likely cause	Corrective action
Script returns permission denied	Execute bit missing or filesystem mounted `noexec`	Add execute permission if appropriate; inspect mount options
User cannot enter a directory	Execute permission missing on a path component	Use `namei -l` and correct the required directory mode
Group access does not work	Old login session or wrong group ownership	Verify with `id`, re-login and inspect `ls -l`
New team files are not group-owned	setgid missing on the parent directory	Apply setgid to the shared directory
ACL entry seems ineffective	ACL mask is restrictive	Review and adjust the mask with `setfacl`
Write fails despite `rwx`	Read-only mount, SELinux or application control	Check `findmnt`, contexts and logs

Linux permission best practices

Use the least access required for the task. Avoid chmod 777 as a quick fix because it gives every local user permission to modify the target and can hide the real ownership or service configuration problem.

Additional good practices include:

Keep SSH private keys at mode 600 and the .ssh directory at 700.
Do not make configuration files executable unless execution is required.
Use groups for team access instead of assigning unrelated users as owners.
Use setgid directories or default ACLs for controlled collaboration.
Review recursive changes before executing them.
Run application services under dedicated non-root accounts.
Record ownership requirements in deployment automation.
Test access as the account that runs the process.

Summary

Linux file permissions combine read, write and execute bits across owner, group and other classes. chmod changes modes, chown and chgrp manage ownership, umask influences defaults, and ACLs handle access requirements beyond the basic model.

When access fails, inspect the complete path rather than changing only the final file. Confirm the process identity, group membership, directory traversal rights, ACL mask, mount options and security controls before applying a fix.

Reviewed by Network Rhinos Linux and DevOps trainers.

To practise Linux permissions in deployment pipelines, cloud servers and automation labs, enquire about upcoming batch details for the AWS DevOps course.