Who Gets to Delete a Linux File?

A file marked read-only can still disappear with a single rm. This often surprises people because the familiar permission letters appear to tell a simple story: write permission means change is allowed, so removing a file must require write permission on that file.

Linux deletion follows a different rule. A filename is an entry inside a directory, pointing to an underlying inode that stores the file’s metadata and data-block locations. The unlink operation used by rm removes that directory entry. It does not edit the file’s contents.

Because deletion changes the directory, Linux primarily checks permissions on the file’s parent directory. The user needs write permission there to remove an entry and execute permission to access entries within the directory. The file’s own write bit is not the deciding factor.

Consider a regular file with mode 0444, which makes it readable but not writable. If its owner has write and execute permission on the containing directory, the owner can usually delete it. Some versions of rm may display a confirmation prompt for a write-protected file when used interactively, but that prompt is a safety feature in the command, not proof that the kernel requires file write permission. If deletion proceeds, the kernel evaluates the directory permissions.

The reverse case is equally revealing. A user may own a writable file and still be unable to remove it when the parent directory is not writable. The user can modify the file’s contents through an existing path but cannot remove that path from the directory.

Shared directories add one important control: the sticky bit. A directory such as /tmp is normally writable by many users, which would otherwise let them delete one another’s entries. With the sticky bit enabled, deletion is generally restricted to the file owner, the directory owner, or a privileged user. This is why /tmp commonly has mode 1777 rather than plain 0777.

Deletion also does not necessarily destroy the data immediately. An inode remains alive while another hard link points to it or a process still has it open. Removing a filename merely reduces the inode’s link count. Storage becomes reclaimable only after the final link is gone and no open file descriptions still reference the inode.

The practical diagnostic is straightforward: when rm reports “Permission denied,” inspect the parent directory before changing the file’s mode. Making a file writable may silence an interactive warning, but it does not grant authority to remove the directory entry. On Linux, control over a filename belongs chiefly to the directory containing it.