chmod 444: Read Only for Everyone, With Real Limits

444 says this file is finished. Reference data, a generated file that a build produces and nothing should hand edit, a licence text, a checked in artefact: making it unwritable turns an accidental save into a visible error. Editors report that the file is read only, which is a far better outcome than a silent overwrite discovered three commits later.

The limit that catches people is deletion. Removing a file requires write permission on the directory that contains it, not on the file, so a 444 file in a writable directory can be deleted by anyone who could delete a 644 one. Interactive rm asks for confirmation about a write protected file, and rm -f does not ask at all.

It is also not immutability. The owner can chmod it back to 644 in a single command, and root can do so to anything. If a file must resist a deliberate change, use chattr +i, which even root has to clear before writing, or place it on a read only mount where the file system itself refuses.

On a directory 444 is a curiosity worth understanding: the read bit lets you list the names, and the missing execute bit means you cannot stat any of them or enter the directory. The result is a listing where every entry shows as unknown, which is the clearest possible demonstration that read and execute are separate permissions.

For most read only needs, 444 is more than required. If only the owner and a service group should see the file, 440 is the narrower version, and it is what tools such as sudo require of their own configuration. Choose 444 when the content is genuinely public on the machine.