How to Check File Permissions in Linux: A Complete Guide

Linux powers the majority of the world's servers — from VPS Hosting environments to enterprise-grade Dedicated Servers — and for good reason. It is fast, stable, and built with security at its core. One of the most fundamental pillars of that security is the file permission system: a precise, elegant mechanism that controls exactly who can read, modify, or execute any file or directory on the system.

Whether you are a developer deploying a web application, a system administrator hardening a server, or a beginner learning the command line, understanding how to check and interpret file permissions in Linux is a non-negotiable skill. This guide covers everything you need to know — from the basics of the permission model to advanced special bits — with practical commands and real-world examples.

What Are Linux File Permissions?

Every single file and directory in Linux has a set of permissions attached to it. These permissions define what actions are allowed and by whom. There are three core permission types:

These three permissions are applied independently to three distinct user categories:

• Owner (user) — The user who owns the file, typically its creator.
• Group — Any user who belongs to the file's assigned group.
• Others — Everyone else on the system.

This three-by-three matrix of permissions gives Linux administrators granular, powerful control over access to every resource on the system.

How to Check File Permissions: The ls -l Command

The fastest and most commonly used method to check file permissions is the ls -l command (long listing format).

ls -l file.txt

Example output:

-rw-r--r-- 1 alice developers 1024 Aug 16 12:30 file.txt

Let's break down each component of this output:

-  rw-  r--  r--   1   alice   developers   1024   Aug 16 12:30   file.txt
│   │    │    │    │     │          │          │         │             │
│   │    │    │    │     │          │          │         │             └─ Filename
│   │    │    │    │     │          │          │         └─ Last modified
│   │    │    │    │     │          │          └─ File size (bytes)
│   │    │    │    │     │          └─ Group name
│   │    │    │    │     └─ Owner name
│   │    │    │    └─ Number of hard links
│   │    │    └─ Others' permissions
│   │    └─ Group's permissions
│   └─ Owner's permissions
└─ File type (- = regular file, d = directory, l = symlink)

So -rw-r--r-- tells us:

• Owner (alice): Read + Write (rw-)
• Group (developers): Read only (r--)
• Others: Read only (r--)

Checking Permissions for Multiple Files

To see permissions for all files in a directory at once:

ls -la /var/www/html

The -a flag includes hidden files (those starting with a dot). This is especially useful when auditing web server directories on a Shared Web Hosting or VPS environment.

Getting Detailed Permission Information with stat

For a more thorough breakdown — including both symbolic and numeric representations — use the stat command:

stat file.txt

Example output:

  File: file.txt
  Size: 1024            Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 131073      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   alice)   Gid: ( 1000/developers)
Access: 2024-08-16 12:30:00.000000000 +0000
Modify: 2024-08-16 12:30:00.000000000 +0000
Change: 2024-08-16 12:30:00.000000000 +0000

The key line is:

Access: (0644/-rw-r--r--)  Uid: ( 1000/   alice)   Gid: ( 1000/developers)

This gives you:

• Numeric (octal) notation: 0644
• Symbolic notation: -rw-r--r--
• User ID (UID) and Group ID (GID) with their human-readable names

The stat command is invaluable when troubleshooting permission errors on production servers, as it provides all the context you need in a single output.

Understanding Numeric (Octal) Permission Notation

Linux permissions can be expressed as numbers, which is the format used by commands like chmod. Each permission type is assigned a value:

You calculate the permission value for each user category by adding the values together:

A three-digit octal number represents the full permission set:

0644  →  Owner: 6 (rw-)  |  Group: 4 (r--)  |  Others: 4 (r--)
0755  →  Owner: 7 (rwx)  |  Group: 5 (r-x)  |  Others: 5 (r-x)
0700  →  Owner: 7 (rwx)  |  Group: 0 (---)  |  Others: 0 (---)

Checking Permissions on Directories

Directories use the same permission model, but the meaning of each bit is slightly different. Use ls -ld (note the -d flag) to inspect a directory itself rather than its contents:

ls -ld myfolder

Example output:

drwxr-x--- 2 alice developers 4096 Aug 16 12:30 myfolder

The leading d confirms this is a directory. The permissions break down as:

• Owner (alice): rwx — Can list, create/delete files, and enter the directory
• Group (developers): r-x — Can list files and enter, but cannot create or delete
• Others: --- — No access whatsoever

> Important: The execute bit (x) on a directory means the ability to enter it (i.e., use cd). Without x, a user cannot navigate into the directory even if they have read permission. This is a common source of confusion for newcomers.

Special Permission Bits: setuid, setgid, and Sticky Bit

Beyond the standard nine permission bits, Linux supports three special permission bits that provide advanced access control:

1. setuid (s on owner's execute bit)

When set on an executable file, the program runs with the file owner's privileges rather than the calling user's. This is how commands like passwd allow regular users to modify /etc/shadow (which is owned by root).

ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 54256 Mar 27 2023 /usr/bin/passwd

The s in the owner's execute position indicates setuid.

2. setgid (s on group's execute bit)

On a file, the program runs with the group's privileges. On a directory, new files created inside automatically inherit the directory's group — useful for shared project folders.

ls -ld /shared/project
drwxrwsr-x 2 alice developers 4096 Aug 16 12:30 /shared/project

3. Sticky Bit (t on others' execute bit)

When set on a directory, only the file's owner (or root) can delete or rename files within it, even if others have write permission. This is the standard configuration for /tmp:

ls -ld /tmp
drwxrwxrwt 12 root root 4096 Aug 16 12:30 /tmp

The t at the end signals the sticky bit is active.

Numeric representation of special bits:

So drwxrwxrwt = 1777 (1000 + 777).

Complete Permission Reference Table

Real-World Permission Examples

Here are the most common permission patterns you will encounter in practice:

-rw-r--r-- (0644) — Standard File

-rw-r--r-- 1 alice developers 1024 Aug 16 12:30 config.txt

Owner can read and write. Group and others can only read. Typical for configuration files and web content.

-rwxr-xr-x (0755) — Executable Script or Binary

-rwxr-xr-x 1 alice developers 4096 Aug 16 12:30 deploy.sh

Owner has full access. Everyone else can read and execute but cannot modify. Standard for shell scripts, web server binaries, and public executables.

-rw------- (0600) — Private File

-rw------- 1 alice alice 1679 Aug 16 12:30 id_rsa

Only the owner can read or write. No access for anyone else. Required for SSH private keys — SSH will refuse to use a key file with broader permissions.

drwxr-xr-x (0755) — Standard Public Directory

drwxr-xr-x 5 alice developers 4096 Aug 16 12:30 public_html

Common for web root directories. Owner has full control; others can browse and enter.

drwx------ (0700) — Private Directory

drwx------ 3 alice alice 4096 Aug 16 12:30 .ssh

Completely private. Only the owner can access. Required for the ~/.ssh directory.

drwxrwxrwt (1777) — World-Writable with Sticky Bit

drwxrwxrwt 12 root root 4096 Aug 16 12:30 /tmp

Everyone can create files, but only each file's owner can delete their own files.

Practical Tips for Server Environments

If you manage a Linux server — whether it's a VPS running a web application, a mail server secured with an SSL Certificate, or a machine hosting multiple domains registered through Domain Registration — here are some essential permission best practices:

1. Never set 777 on files or directories unless you have a very specific, temporary reason. World-writable files are a major security risk.
2. Web server files (e.g., under /var/www/) should typically be 644 for files and 755 for directories, owned by your application user.
3. SSH keys must be 600 for private keys and 644 for public keys. SSH enforces this strictly.
4. Configuration files containing passwords or API keys should be 600 or 640 at most.
5. Use find to audit permissions across a directory tree:

   # Find all world-writable files (potential security risk)
   find /var/www -type f -perm -o+w

   # Find all SUID files (for security auditing)
   find / -type f -perm -4000 2>/dev/null

Quick Command Reference

Conclusion

Understanding Linux file permissions is not just an academic exercise — it is a practical, daily skill for anyone managing servers, deploying applications, or working in a Linux environment. To summarize the key takeaways:

• Use ls -l for a quick, human-readable overview of permissions on files and directories.
• Use stat when you need both symbolic and numeric representations, along with ownership details.
• Master both notations — symbolic (rwx) and numeric (755, 644) — as different tools and documentation use both interchangeably.
• Remember the directory difference: the execute bit (x) on a directory means the ability to enter it, not to run it.
• Be aware of special bits — setuid, setgid, and the sticky bit — as they appear frequently on production systems and have significant security implications.

Proper permission management is a cornerstone of Linux security. Whether you are running a personal project on VPS Hosting or administering a fleet of Dedicated Servers, getting permissions right from the start will save you from security vulnerabilities, broken applications, and countless hours of troubleshooting down the line.