chmod 777

chmod 777 sets the mode to rwxrwxrwx: the owner, the group and every other user can read, write and execute. On a file, anyone can replace its contents. On a directory, anyone can create files in it and delete or rename any file there, other users’ included, because 777 has no sticky bit.

Why it’s almost never right

• Anyone can change what runs. If root, cron or a service runs a world-writable script or binary, every local account and every compromised process can put its own code in it and have it run as that user.
• Software refuses it. sshd’s StrictModes, on by default, rejects key logins when the home directory, ~/.ssh or authorized_keys is writable by others. MySQL skips a world-writable option file with World-writable config file '/etc/mysql/my.cnf' is ignored. sudo won’t run with a world-writable /etc/sudoers.
• It hides the bug. The error comes back when a deploy or a restore resets the mode, and by then nobody remembers why it was 777.

777 is not the fix for “Permission denied”

Usually the error means that the user the process runs as lacks one specific bit on one specific path. Find which:

ps -eo user,comm | grep -E 'nginx|php-fpm'          # who the workers run as
namei -l /var/www/site/uploads/photo.jpg            # owner and mode of every step of the path
sudo -u www-data test -w /var/www/site/uploads && echo writable

Then give exactly that user exactly that access, through ownership or a group:

sudo chgrp www-data /var/www/site/uploads
sudo chmod 2775 /var/www/site/uploads   # group-writable; new files take the www-data group

If ls -l already allows the access and it still fails, 777 changes nothing: look at SELinux (ls -Z, ausearch -m avc), AppArmor, a read-only or noexec mount, or an operation that needs ownership, such as chmod itself.

Where rwxrwxrwx is fine

• Symlinks. On Linux they always show lrwxrwxrwx; the mode is unused and chmod on a link changes its target.
• Before the umask. mkdir asks for 777 and the umask 022 makes it 755; umask 000 is how you’d get real 777 directories, and 666 files.
• Shared scratch space wants 1777, as /tmp has: everyone can write, but only a file’s owner can delete it.

In containers

A non-root container that can’t write to its volume needs the right owner, not 777: COPY --chown=app:app in the Dockerfile, or securityContext.fsGroup in Kubernetes, which makes a volume that supports it group-owned and group-writable for the pod. Git never stores 777 anyway: it keeps only the executable bit, so the file comes back 755 under umask 022.