Chmod 777: why it works and why you should stop reaching for it

chmod 777 works. That is the whole problem with it. It clears the permission question rather than answering it, so the thing that was failing starts working and the reason it was failing stays unknown. On a single-user Mac the security argument lands softly, which is why the usual warnings bounce off. The stronger argument is different: on macOS there are three separate permission layers, chmod reaches one and a half of them, and reaching for 777 usually means the actual cause was never identified. It also quietly clears three bits that had a job.

What each digit grants

The octal number is a sum. The manual page for chmod lists the values that make it up: 0400 read by owner, 0200 write by owner, 0100 execute by owner, then 0040, 0020 and 0010 for group members, and 0004, 0002 and 0001 for everyone else. Three digits, each a sum of 4, 2 and 1, applied to owner, group and other in that order. So 777 is read, write and execute for all three categories, which is the maximum the mode bits can express.

Digit	Value	On a regular file	On a directory
4	read	Read the contents	List the entries
2	write	Change the contents	Create, rename, move and delete entries
1	execute	Run it as a program	Look up a name inside it

The right-hand column is where the reasoning usually goes wrong. On a directory, execute is not about running anything. The manual calls it search: permission to look up files by name inside that directory. A directory with read but not execute can be listed while nothing inside it can be opened, which produces the odd result of ls working and every path under it failing. And write on a directory is broader than it looks. The manual states it plainly: the write permission on directories will permit file creation, relocation, and copy into that directory.

The manual's own worked example is 755, which it spells out as 400 plus 200 plus 100 plus 040 plus 010 plus 004 plus 001. That is the mode most things being handed 777 actually wanted.

On a directory, 777 gives away deletion

Deleting a file does not require permission on the file. It requires write permission on the directory that contains it. This is the single fact that makes 777 on a directory different in kind from 777 on a file. A directory at mode 777 lets any account on the machine remove or rename anything inside it, including files owned by somebody else and marked read-only.

Unix has a specific mechanism for the case where a directory genuinely must be writable by everyone, and it is the sticky bit. A directory with it set becomes one in which deletion is restricted: a file can only be removed or renamed by a user who has write permission on the directory and is also the owner of the file, the owner of the directory, or the superuser. /tmp is the canonical example, which is why its mode is 1777 rather than 777. In a long listing the difference shows as a t in the last position, drwxrwxrwt rather than drwxrwxrwx.

A three-digit chmod 777 clears the sticky bit, because the sticky bit lives in a fourth digit that was not supplied. The same applies to setuid, value 4000, and setgid, value 2000. Running chmod 777 on a directory that was 1777 removes the protection. Running it on a binary that was 4755 removes the setuid bit and changes how that program runs. Neither produces a warning.

The symbolic form does not have this problem, because it edits the bits that are named and leaves the rest alone. chmod a+rw adds read and write for everyone without touching the fourth digit. The manual's examples are worth borrowing directly: go-w denies write to group and others, =rw,+X sets read and write while retaining execute where it is already set, and go= clears group and other entirely.

macOS has a second layer that chmod barely touches

Everything above is POSIX mode bits. macOS also carries access control lists, and they are evaluated before the mode bits. This is the most common reason 777 appears not to work: the mode is wide open, the operation still fails, and the denial is coming from an ACL entry that chmod 777 never saw.

ls -le shows them. A plus sign after the mode string in an ordinary ls -l listing, as in -rw-r--r--+, means an ACL is present. The entries are numbered and read in order, and each one allows or denies a named set of rights to a user or group. The rights are finer grained than the mode bits: delete and delete_child are separate, as are readattr, writeattr, readextattr, writeextattr, readsecurity, writesecurity and chown. For directories there are list, search, add_file and add_subdirectory. A single deny delete entry will stop a file being removed no matter what the mode says.

chmod does manipulate ACLs, through a different set of options. +a adds an entry, -a removes one, -N removes the ACL from a file entirely, -I removes all inherited entries, and -i strips the inherited flag from the entries that remain. Inheritance is worth knowing about because a directory can carry entries flagged file_inherit or directory_inherit, which means newly created items acquire them automatically. That is how a permission problem reappears on a file created after the problem was supposedly fixed.

The Finder side of this is the Info window, and Apple describes the mapping in its own terms:

Permission settings determine who can view and alter files on the computer. You change permission settings at the bottom of the Info window for a file, folder, or disk in the Finder. Source: support.apple.com

The four choices offered there are Read & Write, Read only, Write only for a drop box, and No Access, and the button at the bottom of that window offers Apply to enclosed items, which is the graphical equivalent of chmod -R. Reading the Info window and the output of ls -le together is the fastest way to tell a mode problem from an ACL problem, and it is one of the cases where having the folder view and the shell in the same window removes a real step rather than a cosmetic one. That pairing is what a file manager with a built-in terminal is for.

And a third layer: file flags

Flags are separate again, and chmod cannot see them. chflags sets them, and ls -lO displays them. The two that matter day to day are uchg, the user immutable flag, which the owner or the superuser can set and clear, and schg, the system immutable flag, which only the superuser can set. An immutable file cannot be changed or deleted regardless of mode, and 777 does nothing to it. chflags nouchg is the command that does.

This is also the layer behind the Lock checkbox in the Finder's Info window. A file locked there is an immutable file, and the symptom is a file that refuses to be modified or trashed while its permissions look entirely permissive. chflags -R 0 <directory> clears every flag in a tree, which the manual gives as its own example.

System files sit behind a fourth barrier, System Integrity Protection, which is enforced by the kernel and is not addressable by permissions at all. If a path under /System refuses to change, no combination of chmod, chflags and sudo is the answer, and treating it as a permission problem wastes time.

What to run instead

The useful question is not which mode is safe but which of the three layers is refusing. ls -leO answers all three at once: mode bits, ACL entries and flags in a single listing.

Symptom	Likely cause	What to run
Cannot write a file you own	Missing owner write bit	chmod u+w <file>
Cannot enter a directory	Missing execute bit	chmod u+x <dir>
A web server cannot read files	Missing other read and search	chmod -R a+rX <dir>
Files owned by the wrong account	Ownership, not mode	chown on the tree
Mode looks open, operation still fails	An ACL deny entry	ls -le, then chmod -a or -N
File refuses to change or delete	Immutable flag	chflags nouchg <file>

a+rX deserves its own note. The capital X sets the execute bit only on directories and on files that already have some execute bit set, which is exactly the distinction that chmod -R 777 destroys. It is the difference between making a tree readable and marking every text file in it as a program.

Ownership is the answer more often than mode is. A file that the current account cannot write because it belongs to another account does not need its permissions widened for the whole machine; it needs its owner corrected, or the account added to the group that already has access. Widening the mode solves today's error and leaves the wrong owner in place for the next one.

Homebrew's documentation puts the general principle better than most, in the specific case of zsh refusing to load completions from a world-writable directory:

If zsh reports insecure completion directories, run compaudit to list the affected paths. Inspect their ownership and remove group or world write access only from the directories reported by compaudit. Do not recursively change permissions across the entire Homebrew prefix. Source: docs.brew.sh

Note the direction. The complaint there is caused by too much write permission, and the fix is to remove it from named directories rather than to apply anything recursively. It is a useful reminder that some tools refuse to work precisely because a mode is too open.

Recursion is the part that leaves a mess

chmod -R 777 is worse than chmod 777 on a single item, for reasons that outlast the moment. Every file in the tree becomes executable, and in a Git repository that is a recorded change: Git tracks the executable bit, so hundreds of files switch mode and the diff fills with changes nobody made on purpose. Every directory loses its sticky bit if it had one. Any nested item that was deliberately restricted stops being restricted, and there is no record of what it used to be.

The manual adds a sharper warning about -R, which is to beware of unintentionally matching the .. hard link to the parent directory when using wildcards such as .*. A command aimed at the hidden files in one directory can reach the parent that way.

There is a final irony. Modes are not the whole story for files that do not exist yet: new files are created according to the process umask, so a tree flattened to 777 today will produce files at the umask default tomorrow, and the error comes back. A permission problem that returns after a recursive chmod is usually a sign that the real cause was ownership, an ACL, or the umask of whatever process creates the files.

What to change first

Run ls -leO on the item that is failing before changing anything, because it names which of the three layers is refusing. Then pick the narrowest command that addresses that layer: chmod u+w for a missing owner bit, chown for wrong ownership, chmod -a for an ACL entry, chflags nouchg for an immutable file. Reading that listing next to the folder it describes, in one window, is what Atriens is built around.