In my CMS, I noticed that directories need the executable bit (+x) set for the user to open them. Why is the execute permission required to read a directory, and how do directory permissions in Linux work?


9 Answers 9


When applying permissions to directories on Linux, the permission bits have different meanings than on regular files.

  • The read bit (r) allows the affected user to list the files within the directory
  • The write bit (w) allows the affected user to create, rename, or delete files within the directory, and modify the directory's attributes
  • The execute bit (x) allows the affected user to enter the directory, and access files and directories inside
  • The sticky bit (T, or t if the execute bit is set for others) states that files and directories within that directory may only be deleted or renamed by their owner (or root)
  • 43
    Great answer, but I think the last sentence is misleading. None of these permissions can be overridden per-file actually. Here “access” is a bit ambiguous: +x on the directory grants access to files inodes through this specific directory (nothing less, nothing more, well… maybe chdir needs +x too). To read or write the contents of one file, the user also needs +r/+w on this file, but those are distinct permissions (they do not override anything). Commented Sep 22, 2011 at 13:06
  • 3
    The immutable flag is filesystem specific and it won't precisely override those permissions, that's why I think the last sentence is misleading :-) Commented Sep 22, 2011 at 13:18
  • 1
    I think it might be useful to mention ACL in this and other answers, cause their application for some directories can be misleading if one will consider only information provided by Chris Down
    – d.k
    Commented Dec 29, 2014 at 12:30
  • 7
    Seems that this answer doesn't mention the combined effect of write bit and execute bit, as Baldrick's answer mentions below? i.e. if you only have write permission but not execution permission, then it's quite useless.
    – xji
    Commented Feb 16, 2015 at 8:55
  • 2
    @StéphaneGimenez "+x on the directory grants access to files inodes" -- This seems like a good nemonic, but perhaps doesn't tell the whole story? Without the execute bit set on a directory, you can't change the filename of a file in that directory. I'm wondering why this is, because the filename is stored in a directory entry, not an inode. Commented Dec 17, 2015 at 22:11

First, think: What is a directory? It's just a list of items (files and other directories) that live within. So: directory = list of names.

Read bit = If set, you can read this list. So, for example, if you have a directory named poems:

  • You can ls poems and you'll get a list of items living within (-l won't reveal any details!).
  • You can use command-line completion i.e. touch poems/so <TAB> poems/somefile.
  • You cannot make poems your working directory (i.e. cd into it).

Write bit = If set, you can modify this list i.e. you can {add,rename,delete} names on it. But! You can actually do it only if the execute bit is set too.

Execute bit = Make this directory your working directory i.e. cd into it. You need this permission if you want to:

  • access (read, write, execute) items living within.
  • modify the list itself i.e. add, rename, delete names on it (of course the write bit must be set on the directory).

Interesting case 1: If you have write + execute permissions on a directory, you can {delete,rename} items living within even if you don't have write permission on those items. (use sticky bit to prevent this)

Interesting case 2: If you have execute (but not write) permission on a directory AND you have write permission on a file living within, you cannot delete the file (because it involves removing it from the list). However, you can erase its contents e.g. if it's a text file you can use vi to open it and delete everything. The file will still be there, but it will be empty.


  • Read bit = You can read the names on the list.
  • Write bit = You can {add,rename,delete} names on the list IF the execute bit is set too.
  • Execute bit = You can make this directory your working directory.

PS: The article mentioned by Kusalananda is a good read.

  • 27
    Thinking about directory as a list makes things more clear and logical. Commented Jan 9, 2014 at 8:51
  • 39
    Great answer, but too focused on the term "working directory". I need the x bit for any access to this file: for cat a/b/c/d, I need the x bit on all a, b and c, even if I don't use them as cwd.
    – glglgl
    Commented Nov 3, 2014 at 9:24
  • 4
    This is where I found out you can't write unless it's executable too! Case 2 is also interesting, great answer!
    – Mirko
    Commented Nov 30, 2014 at 1:56
  • 2
    Another note is that even if you have x permission on the directory, if you don't have x permission on the file within, you can't really "execute" the file. You can only cat it for example, but you can't run the file itself.
    – xji
    Commented Feb 16, 2015 at 9:19
  • 4
    If you want to ls -l work for a folder, need both r and x permission.
    – Eric
    Commented Jun 12, 2015 at 9:48

I have prepared this table with all the possible permissions and their practical effects.

Octal del
dir list read
cd dir cd
--- 0
-W- 2
R-- 4 only file
names (*)
RW- 6 only file
names (*)
--X 1
-WX 3
R-X 5

(*) Only file names: other attributes such as size or date are not accesible. E.g. you can use tab key to autocomplete but not ls command.

Some thoughts:

  • With X unset, R and W are mostly useless.
  • X alone disabling RW gives you a false sense of security since you could blindly read and write file contents and access subdirectories. You should be sure that every direct children of the directory have explicit permissions.
  • Rarely you will use other values than:
    • 0: No access.
    • 1: Minimum access allowing traversing.
    • 5: Allow reading / writing, but not altering the structure of the directory tree itself.
    • 7: Full access.
  • 8
    Great summary chart. Makes me wonder what someone was thinking to have -W- be functionally equivalent to --- for directories. Not very intuitive. Of course these types of low-level bits often aren't.
    – CivFan
    Commented May 2, 2017 at 21:06
  • 1
    Another typical use case is the ability to change permissions on the directory itself. How is that affected by the different combos?
    – CivFan
    Commented May 2, 2017 at 21:20
  • 4
    I tested this on my mac, but with -W-, I could rename the directory (in a directory with a sticky bit) but not with ---. That seems to be a difference Commented Jul 15, 2017 at 1:45
  • 4
    @David, You are missing the sticky bit.
    – Pacerier
    Commented Nov 21, 2017 at 17:29
  • 2
    "Only file names: other attributes such as size or date are not accesible." This is not completely true. Yes, you do not have access to the respective target files inodes, which store all the attributes. But some file systems cache part of that in the directory entries: Basically, you have access to everything that is returned in the dirent by readdir(3). In POSIX this includes (besides the name) at least the inode number; on Linux furthermore the file type.
    – Daniel
    Commented Aug 19, 2018 at 22:32

Here is a good article on this.


A directory with its x bit set allows the user to cd (change directory) into this directory, and access the files in it.


  • Read (r)

    The ability to read the names of files stored in this directory.

  • Write (w)

    The ability to rename files in the directory, create new files, or delete existing files, if you also have Execute permissions. If you don't have execute perms, then write perms are meaningless.

  • Execute (x)

    The ability to cd into this directory, and access the files in this directory.

Here are a few examples that should make it easier to understand:

# "Full Access".  Reegen can list, create, delete, rename, delete,
# and stat any files in dir.
# Access to file contents is subject to the permissions
# of the file itself.
# New files can be created, any file can be deleted, regardless of
# file permissions.
drwx------  1 reegen    reegen          4096 Jan 01 2003  dir

# Reegen can do everything in the "Full Access" list except create,
# delete, or rename files in this directory.
dr-x------  1 reegen    reegen          4096 Jan 01 2003  dir

# Reegen can do everything in the "Full Access" list except list the
# filenames in this directory.  If she suspects there is a file
# named "program" she can list it, but cannot do an 'ls'
# of the directory itself.  She can access any file (file
# permissions permitting) if she knows its name.  She can
# create new files, or rename/delete existing ones.
d-wx------  1 reegen    reegen          4096 Jan 01 2003  dir

# Reegen cannot create or delete any files in this directory.
# She can access any file (permissions permitting) if she
# knows its name already.
d--x------  1 reegen    reegen          4096 Jan 01 2003  dir

There is even more information in the Hacking Linux Exposed article.


From Robert Love's book "LINUX System Programming" chapter 1 section permission-

enter image description here


For any operation accessing a file or directory, it must first resolve the path to the file or directory. The resolution requires the user has execute permission on all directories along the path, except the final path component. So for directories, you can think of the execute bit means "resolvable".

Take path /a/b/c.txt as an example, say the user has 1) execute permission on / and /a; 2) has read permission on /a/b; 3) read and write permission on /a/b/c.txt.

  • The user will fail to read (list) /a, because it has no read permission. But the path resolution doesn't fail.

  • The user will be able to read (list) /a/b, because the user has execute permission on /, /a and read permission on /a/b. Note that, when reading /a/b, the filename c.txt is visible, but the metadata (e.g. filesize) and the content is not, because the filename is stored with the directory, not with the file, but the metadata is stored in the inode of the file.

  • The user will fail to read /a/b/c.txt, because when resolving the path from / to /a to /a/b, it fails at /a/b since the user doesn't have execute permission.

See also how a pathname is resolved to a file.

  • So you need 'x' on a folder to read the content of a file directly inside the folder itself? Why?
    – realtebo
    Commented Jun 27, 2022 at 19:47

An useful analogy is to think of each file as a book, and each directory as a room where the books are kept.

There are rules to be able to list all the names in a room: the read bit for directories. Rules to remove a book from the room: the write bit for directories. And rules to enter a room and explore: the resulting directory execute bit.

Those rules are separate and different than the rules for each book. There are rules to allow someone to open a book and read its contents: the read bit(s) for each file. There are rules to modify the contents of a book: the write bit(s) for each file. And to execute a file: the execute bit(s) for each file.

I write bit(s) because there are three bits for each action. There is one read bit for the owner, one read bit for the group(s) and a read bit for everyone else (others). If any of those three bits is set for an specific user, that user has the read bit active. It doesn't matter how that bit was found to be active either by user or group or other, it has the same effective results.

Thus, an user could be allowed to enter a room and remove books from the library but not allowed to read the contents of same book.

That is why a read bit for directories is required: to control who is allowed to list the room contents (book titles).

And the execute bit is used to control who can enter the room of books.

  • I like your example. The rooms with books is better than simply lists of books. In your examples the 'r' allow reading the index of books but to cat a file you must also 'x' to effectively enter on it and use the list itself to locate a book. But question: what happen if you have only x and not r on a folder. You can enter, but not la and not autocomplete?
    – realtebo
    Commented Jun 27, 2022 at 19:52

access(2) — Linux manual page

A file is accessible only if the permissions on each of the directories in the path prefix of pathname grant search (i.e., execute) access. If any directory is inaccessible, then the access() call fails, regardless of the permissions on the file itself.

path_resolution(7) — Linux manual page

This man page explains how a pathname is resolved in relation to permissions

Step 2: walk along the path

If the process does not have search permission on the current lookup directory, an EACCES error is returned ("Permission denied").

"seach permission" means execute permission of directories.

  • 2
    Does this add anything that isn't already in the earlier 8 answers?
    – ilkkachu
    Commented Apr 10, 2021 at 12:25

The meaning of Execute for directories is quite clear. Since there is no Traverse permission, unlike Windows, you must overload something. The designers picked Execute, That causes endless confusion. As a computer security guy assigning Execute rights to something you don't intend to actually Execute looks dodgy.

  • 2
    The invention of the execute permission bit pre-dates the invention of the concept of a distinct traverse permission by about two decades. This answer's logic depends from a historic timeline that is nothing like that of the real world, and also fails to notice the existence of GENERIC_EXECUTE and what it is.
    – JdeBP
    Commented Apr 3, 2018 at 7:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .