Suppose the owner/user doesn't have the write permission on a directory but he has it on a file under it. Can the file here be edited or not? If yes, is there any situation where the file cannot be edited?


3 Answers 3


Yes, the file can be edited.

As far as the directory is concerned, the file can not be edited if you remove the execute permission on the directory for the target (owner/group/others).

EDIT: If you want the owner to not be able to edit the file by changing the permission of the directory (assuming the same user owns the directory and file), then you can simply remove the execute permission on the directory for the owner. For example you can make the permission for the owner as rw- i.e. 6.

  • Isn't there any other situation where we could not edit the file ?
    – h8pathak
    Mar 25, 2015 at 18:42
  • @h8pathak: Check my edits
    – heemayl
    Mar 25, 2015 at 18:47

As the other answers have stated: Yes, the file can be edited/modified.  And, at the risk of splitting hairs, allow me to point out that the question says

… he has [write permission] on a file under [the directory].

and to make the semi-obvious comment that, to edit a file in the traditional meaning of the word, the user must also have read permission to the file, in order to obtain its current contents.  Without read permission, the user can overwrite existing data, and/or add (append) data at the end, but he cannot do useful edits like fixing typos or inserting text.

And I say “modified” to emphasize that we’re talking about a range of scenarios, to include the ones I mentioned above (overwrite or append) as well as

  • copying the file data out (e.g., to a file in another directory), manipulating it somehow, and then copying it back (overwriting the file), or
  • using a traditional text editor, such as vi, (or even a hex editor, if applicable),

and vi, in particular, has no problem with editing a file in this situation.  I haven’t tested a lot of other editors.  I expect that most of them (e.g., emacs, pico, …) would be fine, too.


sed  -i  sed_command(s)  filename

will not work, because sed -i works by

  • creating a temporary file in the same directory,
  • copying the text from the original file to the new (temporary) file, performing the specified sed_command(s) on it in the process,
  • deleting the original file, and then
  • renaming the temporary file to the original name (and chmoding it to match the original mode of the original file).

and these operations fail when the directory is write-protected.  (I believe/suspect that a few other editors might behave the same way, but I can’t cite any examples.)

So, sed -i requires write access to the directory.  And, of course, it also requires read permission to the file.  But, the double-twist surprise ending is: it doesn’t require write access to the file.  After all, you don’t need write access to a file to delete it; just write access to the directory.


You do not need to have write permissions to the directory, but the executable x bit has to be set.

So, consider a direcory foo with a file bar. If permissions are set up as

 drwx--x--x   foo
 -rw-rw-rw-   foo/bar

for example, write access is available to anyone as long as the x bit is given. Not even read-access r to the directory is required.

You must log in to answer this question.

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