What it means
chmod 777 gives read, write and execute permission to the owner, the group and every other user on the machine. In ls -l it shows as drwxrwxrwx for a directory or -rwxrwxrwx for a file. It turns permissions off in practice.
| Who | Digit | Read | Write | Execute | Symbolic |
|---|---|---|---|---|---|
| Owner (u) | 7 | yes | yes | yes | rwx |
| Group (g) | 7 | yes | yes | yes | rwx |
| Others (o) | 7 | yes | yes | yes | rwx |
The symbolic equivalent:
chmod a=rwx file
On a file
Any account can read the file, change it and run it. If the file is a script that root, cron or the web server runs, any local user (or any compromised service) can change what it does and run code with those privileges.
On a directory
Any account can list the directory and create, delete or rename any file in it, including files owned by other users. That's why shared directories like /tmp use chmod 1777: the sticky bit stops users from deleting each other's files.
Why people reach for it
777 makes "Permission denied" go away, because there's nothing left to deny. The usual situations:
| Symptom | What's really wrong | Proper fix |
|---|---|---|
| The web app can't write uploads or cache | The server's user doesn't own the directory or isn't in its group | chown deploy:www-data dir and chmod 775 (or 2775) |
| nginx returns 403 for a site | A parent directory lacks x for the server |
chmod 755 or 711 on that directory |
| A script won't run | No execute bit | chmod 755 script.sh or chmod u+x |
| Two users can't edit the same files | No shared group | A group, chmod 664 files, 2775 directories |
| A Docker volume isn't writable | UID inside the container doesn't match the host files | chown to the container's UID, or run the container as your UID |
Every one of these has a narrower fix that grants access to exactly the user that needs it.
Why it's dangerous on a web server
- Uploaded code. If an app or CMS has a file upload or path traversal bug, a 777 web root lets an attacker write a PHP file and run it.
- Defacement and backdoors. Any process on the machine can edit your code, including another site's compromised app on shared hosting.
- Tampered logs and configs. Evidence can be removed and settings changed.
Some hosting control panels and PHP setups refuse to run scripts that are group- or world-writable, so 777 can even cause 500 errors instead of fixing them.
Find and undo it
List world-writable files and directories under your web root:
find /var/www -perm -0002 -not -type l -ls
Reset a tree to the usual safe modes:
find /var/www/example.com -type d -exec chmod 755 {} +
find /var/www/example.com -type f -exec chmod 644 {} +
Then grant write access only where the app needs it, through a group. Avoid chmod -R 777 entirely: it also marks every file as executable.
Is 777 ever fine?
On a throwaway local VM or inside a scratch container with a single user, it does no direct harm. Directories that must be writable by everyone, like /tmp, should be 1777, not 777. On anything reachable from a network, treat 777 as a bug.
Related modes
- chmod 755: the normal mode for directories and scripts.
- chmod 775: shared write for one group.
- chmod 1777: world-writable with the sticky bit.
- chmod 666: the file-only version of this mistake.
Work out the narrowest mode that fixes your error in the chmod calculator.