chmod 666 (rw-rw-rw-)

⚠️ Risky permission. This grants write access beyond the owner — only use it when you truly need it, and prefer tighter, group-based permissions where you can.

When to use 666

Almost never for files on disk. A persistent file at rw-rw-rw- can be rewritten by any account on the system. Like 777 it's usually a symptom of wrong ownership, not a real requirement. The execute bits are off, so it can't be a script — it's purely a world-writable data file.
Device nodes and pseudo-files, not regular files. The places you legitimately see 666 are kernel-managed device files like /dev/null, /dev/zero, and /dev/tty — every process must read and write them. The kernel sets these; you should not be hand-chmod'ing your own files to match.
A genuinely shared scratch file — only with care. If several users on a trusted, isolated box must append to one log or data file, 666 technically allows it, but a group-scoped 664 with a shared group is the safer expression of the same intent.
Quick local debugging. Temporarily on your own single-user machine to rule out a write-permission problem, then reset to the correct mode. Never leave it on a server.

Common mistakes & gotchas

666 means anyone can corrupt or rewrite your data. Any user or compromised service on the host can open the file and replace its contents. For a config, a database file, or a log, that's silent data tampering waiting to happen.
It does NOT make a directory usable. 666 has no execute bit, so applied to a directory you cannot cd into it or reach anything inside — you'd only be able to list names. World-writable directories need the (also dangerous) execute bit; this is one reason 666 on a directory just breaks things.
World-writable config = privilege escalation. If a root-run service reads a 666 config or data file, any local user can edit that file to change the service's behavior. Keep anything a privileged process consumes at 644 or 600.
A common umask accident. Files created by a process with umask 000 land at 666. If you see unexpected world-writable files, check the creating process's umask rather than chmod'ing them one by one — fix the source.

666 vs the alternatives

644 (rw-r--r--) is the correct default for the data files people wrongly set to 666: owner writes, everyone else reads only. Nobody but the owner can alter the contents.
664 (rw-rw-r--) grants write to a trusted group while keeping the world read-only — the right way to let a team share a file. It's the group-scoped version of what 666 does to everyone.
777 (rwxrwxrwx) is 666 plus execute for all — same world-writable danger, but for directories and programs. If 666 is wrong for a data file, 777 is wrong for a directory for the same reason.

Set it with chmod

Apply this permission to a single file:

chmod 666 filename

Or apply it recursively to a directory and everything inside it:

chmod -R 666 directory/

The same thing in symbolic form:

chmod u=rw,g=rw,o=rw filename

Frequently asked questions

What does chmod 666 mean?

chmod 666 sets rw-rw-rw-: the owner, the group, and all other users can read and write the file, but nobody can execute it. It is world-writable but not executable.

Is chmod 666 dangerous?

Yes for regular files — any user or process on the system can overwrite the contents, which means silent data tampering and, for files read by privileged services, potential privilege escalation. Use 644 or 664 instead.

What's the difference between 666 and 777?

666 (rw-rw-rw-) has no execute bit; 777 (rwxrwxrwx) adds execute for everyone. Use neither for normal files. 666 can't make a directory traversable because it lacks the x bit; 777 can but is unsafe.

Why is /dev/null permission 666 then?

Device nodes like /dev/null are special files the kernel manages, and every process legitimately needs to read and write them. That's a kernel-maintained exception — it is not a reason to set your own regular files to 666.

Other common permissions

Or build any permission with the interactive chmod calculator.

chmod 666 — what rw-rw-rw- means

Permission breakdown