I created a file, did chmod 000 to it and then changed the owner and group to root:root. I was still able to delete the file as the original creator of it (not root).

Who has permissions to delete a file?

  • 5
    To clarify the answers a bit, you aren't "deleting" the file you are unlinking it. The file system knows about the file by a link, which are a part of the parent directory. So the file permission on the file do not apply because technically it's still there (recovering an unlinked file is next to impossible, but sometimes you can find it in the disk's data). It's just no longer pointed to by the directory, hence in removing the link you're actually editing the contents of the directory, so it's permissions that apply.
    – Chris S
    Jan 7, 2012 at 4:16

2 Answers 2


The permissions of the containing directory determine the ability to rename and delete files.

Specifically, to delete/rename a file, a user needs to have write and execute (i.e. traversal) permissions on the containing directory, and the file in question must not be immutable. (Under these circumstances, a non-privileged user can even delete files owned by root.)

Restricted Deletion:

It is possible to restrict deletion of files to only the owner of the files (and privileged users), by setting the 'sticky bit' (also known as the 'restricted deletion flag') on the containing directory using: chmod +t directory. A directory with the sticky bit set, displays a 't' in the last position (e.g. drwxr-xr-t) - this can also be set in 'octal' form by prefixing the 3 digit octal code with a '1' (e.g. chmod 1755 directory). (Linux ignores the sticky bit on files - although some other operating systems do assign meaning to it.)

Read Permissions:

You should note that the read permission on the containing directory is not required. Without it, you will still be able to delete the file, if you know its name, although you will not be able to 'read' the contents of the directory (e.g. without read permissions you cannot run ls).

Immutable Files:

As a side point, by making a file immutable (i.e. chattr +i) neither the owner nor other users (including privileged users) will be able to delete (or rename, link to, or modify) the file, even if they have write permissions on the directory (only the superuser can remove this).

  • 1
    An excellent answer except that although chmod +t [-v] dir does what you suggest, chmod +t [-v] file doesn't. I've just tested it, and although I can't paste the results into a comment, they can be seen at teaparty.net/data/serverfault-347589.html and seem pretty definitive.
    – MadHatter
    Jan 7, 2012 at 9:34
  • You are absolutely right - the sticky bit is ignored completely by Linux operating systems on files, but is the 'restricted deletion flag' when applied to folders. Thank you for pointing that out, I will modify the answer.
    – cyberx86
    Jan 7, 2012 at 9:52
  • Glad to help! And it's not just Linux, I tested it on Solaris 8 and observed the same behaviour.
    – MadHatter
    Jan 7, 2012 at 14:19
  • @MadHatter: as far as I know (or can find documentation to support), no operating system interprets the sticky bit on a file as restricted deletion. Many simply ignore the sticky bit (e.g. Linux), while others have a different meaning for it (e.g. the way the file is stored in swap). (Not an 'authoritative source' but, Wikipedia's - Sticky bit has a nice summary of the meaning on different operating systems.)
    – cyberx86
    Jan 8, 2012 at 1:33
  • cyberx86: that's rather what I thought, too; but all credit to you for some references!
    – MadHatter
    Jan 8, 2012 at 8:18

The owner of the folder where the file resides will, if they have write permissions on the folder, be able to delete the file even if it's mask is 000 or the file is owned by another user. If you really want to create a file that no one can touch/delete you should look into the command chattr and its immutable flag.

From the documentation:

A file with the i attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.