What chmod 755 and 644 mean: permission digits, rwx, and x on directories

File permissions are often set with numbers: chmod 755 deploy.sh, chmod 644 index.html. Those three digits are the nine permission bits written in octal. In this article, “the standard” means POSIX.1-2024 (IEEE Std 1003.1-2024). Behavior documented only by GNU or Linux is labeled separately. The examples were run as an ordinary user in a Debian 13.7 container with chmod from GNU coreutils 9.7.

Each digit is three bits

In the standard’s chmod table, owner read, write and execute are 0400, 0200 and 0100. The group values are 0040, 0020 and 0010, and the values for others are 0004, 0002 and 0001.

Within one digit, read is 4, write is 2 and execute is 1. The digit is the sum of the bits that are set.

Digit	Bits	ls -l
7	4+2+1	rwx
6	4+2	rw-
5	4+1	r-x
4	4	r--
0	none	---

755 is owner 7, group 5 and others 5: rwxr-xr-x. 644 is rw-r--r--. In binary, 755 is 111 101 101, and each group of three lines up with one rwx field. You can check the octal-to-binary conversion with the number base converter.

In the string at the start of ls -l, the first character is the file type: - for a regular file, d for a directory and l for a symbolic link. The next three groups show the permissions for owner, group and others. One more character can follow when the file has an additional or alternate access control method.

A numeric mode replaces permissions rather than adding to them. The bits present in the number are set, and the other permission bits are cleared. Running chmod 644 on an executable file removes its execute bits.

Only one permission class counts

Which group of three applies depends on the process’s user and group IDs.

• If the process’s effective user ID matches the file owner, the process is in the file owner class.
• Otherwise, if its effective group ID or one of its supplementary group IDs matches the file’s group, it is in the file group class.
• Otherwise, it is in the file other class.

Exactly one class is selected in that order. If the owner field is empty, the owner cannot read the file even when the group or other fields allow reading.

$ echo hi > f
$ chmod 044 f
$ ls -l f
----r--r-- 1 u u 3 Oct  2 02:04 f
$ cat f
cat: f: Permission denied

User u also belongs to the file’s group u, but the owner class applies, so the group’s r is never consulted.

Privileged processes behave differently. Under the standard, appropriate privilege grants read, write and directory search. Execute still requires at least one of the three execute bits to be set.

Linux divides this privilege into capabilities. According to path_resolution(7), CAP_DAC_OVERRIDE bypasses permission checks, but grants execute only if at least one execute bit is set. The read in the example above would not be denied when run as root, so permission experiments should be run as an ordinary user.

What r, w and x mean on a directory

The same bits mean different things on a directory. The GNU coreutils documentation describes directory read as permission to list its contents, write as permission to create and remove files, and execute as permission to access files inside. The standard calls directory x search permission.

According to path_resolution(7), every directory traversed while resolving a path needs search permission. Without it, lookup fails with EACCES.

That is why r and x work independently.

$ mkdir box && echo hi > box/a.txt
$ chmod 600 box          # rw-: can list, cannot search
$ ls box
a.txt
$ cat box/a.txt
cat: box/a.txt: Permission denied

$ chmod 300 box          # -wx: can search, cannot list
$ ls box
ls: cannot open directory 'box': Permission denied
$ cat box/a.txt
hi

With r alone, you can see the names but cannot open the files. With x alone, you cannot list the directory, but you can look up a name you already know. Opening the file still depends on the file’s own permissions and any other access controls. To list a directory and also access the files inside, you need both r and x.

The same 600 and 300 examples were run on macOS 15.6.1. cat was allowed and denied in the same cases. At mode 600, however, ls printed a.txt together with ls: fts_read: Permission denied, and the error wording at mode 300 was different too.

The directory decides whether a file can be deleted

unlink() removes a directory entry, which is a name. This is also covered in why deleting a file does not free disk space.

The EACCES conditions POSIX lists for unlink() are missing search permission on a directory in the path and missing write permission on the directory containing the entry. The file’s own write bit is not among them. A file being read-only does not by itself prevent deletion.

The S_ISVTX bit adds a restriction for shared directories. When it is set on a writable directory, only a process that owns the file, owns the directory or has appropriate privileges may remove or rename files inside it. Whether a process with write permission to the file is also allowed is implementation-defined.

The GNU chmod documentation calls this the restricted deletion flag or sticky bit. It is commonly used on world-writable directories such as /tmp. In ls -l, the last character of the other field is t when others have search permission and T when they do not.

The leading digit

The standard’s table also has a leading digit: 4000 is set-user-ID, 2000 is set-group-ID and 1000 is S_ISVTX. In GNU chmod, an ordinary numeric mode has one to four octal digits. Omitted digits are treated as leading zeros, so 755 is the same as 0755.

Implementations handle this digit differently. For regular files, the standard says set-user-ID and set-group-ID bits absent from the number are cleared. It leaves other file types to the implementation.

GNU chmod keeps a directory’s two set-ID bits unless they are explicitly addressed. To clear them with a numeric mode, it accepts an additional leading zero, as in 00755. In the test, a directory with g+s stayed at 2755 after chmod 755 and became 755 only after chmod 00755.

Symbolic modes and umask

chmod u=rwx,go=rx sets the nine rwx bits to the same values as 755. = sets the named classes to exactly that value. + and - add to or remove from the current permissions.

Leaving out u, g, o or a needs care. Bits set in the process’s file mode creation mask, or umask, are then left unchanged.

In a shell with umask 022, chmod +w on a file with mode 444 produced 644, while chmod a+w produced 666. The standard’s chmod page uses the same reasoning to contrast chmod a-w file with chmod -- -w file.

The umask also applies when files are created. Bits present in the mask are cleared from the new file’s requested mode. touch requests read and write for everyone, 0666, while the mkdir utility requests 0777. With umask 022, they therefore produce 644 and 755. The test produced those results as well.

chmod -R 755 and capital X

-R changes the mode of a directory and every file below it. Using chmod -R 755 for a directory tree also turns on execute bits for regular files.

The symbolic capital X is useful here. X is treated as the execute or search bit only when the target is a directory or its current mode already has at least one execute bit set. It is ignored for other files.

$ mkdir -p t/d && touch t/d/x.txt
$ chmod -R u=rwX,go=rX t
$ stat -c '%A %a %n' t t/d t/d/x.txt
drwxr-xr-x 755 t
drwxr-xr-x 755 t/d
-rw-r--r-- 644 t/d/x.txt

$ chmod -R 755 t
$ stat -c '%A %a %n' t/d/x.txt
-rwxr-xr-x 755 t/d/x.txt

With the u=rwX,go=rX mode shown above, a file that already has an execute bit also receives execute permission for group and others through go=rX.

With -R, implementations differ on whether a directory’s mode changes before or after the files inside it. The standard advises against removing permissions from an entire hierarchy in a way that makes it inaccessible to you.

Scope

The standard allows implementations to add or substitute access control mechanisms beyond permission bits. An additional mechanism may further restrict what the bits allow.

The GNU documentation also mentions ACLs as file-system-specific attributes. This article does not cover ACLs and other additional controls, network file systems or the Windows permission model. In those environments, permission bits alone do not determine the result.

Specifications and documentation used

• POSIX.1-2024: chmod, General Concepts (directory protection, file access permissions), Definitions (owner, group and other classes), <sys/stat.h>, unlink(), open(), umask(), ls, touch, mkdir
• GNU Coreutils manual: Mode Structure
• Linux man-pages: chmod(1), path_resolution(7)

Links and content were checked on 2 October 2026.