chmod 777 (rwxrwxrwx)

Answer

chmod 777 sets rwxrwxrwx: every user on the machine, including the web server and any compromised service, can read, modify, replace and execute the file. It makes permission errors go away by removing permissions entirely, which is why it is almost never the right fix.

chmod 777 = rwxrwxrwx: everyone full access.

	Read 4	Write 2	Execute 1	Digit
Owner (user)	Owner (user) rr	Owner (user) ww	Owner (user) xx	7
Group	Group rr	Group ww	Group xx	7
Others	Others rr	Others ww	Others xx	7
Special	setuidsetuid	setgidsetgid	stickysticky	0

7
Owner (user): 7 = 4 read + 2 write + 1 execute
7
Group: 7 = 4 read + 2 write + 1 execute
7
Others: 7 = 4 read + 2 write + 1 execute

World-writable: every user on the system can change this. Almost never what you want, except /tmp-style directories, which also set the sticky bit (1777).

On a file

Owner (user) read it, change it and run it as a program
Group read it, change it and run it as a program
Others read it, change it and run it as a program

On a directory

Owner (user) list the names inside, enter it and open files by name, create and rename and delete entries
Group list the names inside, enter it and open files by name, create and rename and delete entries
Others list the names inside, enter it and open files by name, create and rename and delete entries

chmod 777 filechmod a=rwx filels -l → -rwxrwxrwx

What to know

A permission error means one specific user (for example www-data, nginx, or the UID a container runs as) needs one specific kind of access. 777 grants every kind of access to every user instead of that one.

The better fix is to make that user the owner or a member of the file's group, then grant only what it needs: chown www-data uploads/ with 755, or a shared group with 775 and 664. For Docker bind mounts, make the container run as the UID that owns the host directory (--user) instead of opening the directory to everyone.

On a directory, 777 also lets any user delete or rename other users' files in it. The one place world-writable directories are normal, /tmp, adds the sticky bit to prevent that: see 1777.

Where it fits

Practically none for real files. A world-writable shared scratch directory should be 1777, not 777.
Throwaway files on a single-user machine where nothing else runs, if you accept the habit risk

Gotchas

A 777 PHP or script file in a web root can be rewritten by any process that runs as another user, and the web server will then execute the attacker's code.
OpenSSH's StrictModes (on by default) rejects authorized_keys if it, ~/.ssh or your home directory is writable by group or others, so chmod -R 777 ~ locks you out of key-based SSH login.
chmod -R 777 cannot be cleanly undone: the original modes are lost. You have to reset files and directories separately, for example chmod -R u=rwX,go=rX.
If 777 is the only thing that "works", the real cause is usually ownership, a missing execute bit on a parent directory, SELinux/AppArmor, or a read-only or noexec mount.

Related explainers

← chmod calculator