chmod 777 does not solve a permissions problem; it makes every local account and service a potential writer. Start with ls -l, identify the process user, then change the narrowest bit that makes the access legitimate.
Read the mode before changing it
-rw-r----- 1 app deploy 840 Jul 20 09:10 .env
The three triplets are owner, group, and other. r is 4, w is 2, and x is 1; the line above is 640: the owner can read/write, the group can read, and everyone else gets nothing.
| Target | Typical mode | Why |
|---|---|---|
| Application secret | 600 | Only its owner should read it |
| Static public file | 644 | Process can write; web server can read |
| Executable script | 755 | Everyone can run it, only owner can alter it |
| Private directory | 700 | No listing or traversal for others |
Directories are not files
On a directory, x permits traversal. A user may be able to read a directory's names but cannot open a known file without execute permission on every parent directory. That is why blindly adding read does not fix a “Permission denied” path error.
namei -l /srv/app/config/.env
stat -c '%A %a %U:%G %n' /srv/app/config/.env
namei exposes the permissions of each path component; it saves a lot of guesswork with mounted volumes and service accounts.
Fix ownership when ownership is wrong. Running
chmod -R 777on a deploy directory hides the real problem and can turn a compromised low-privilege process into a code writer.
Prefer symbolic changes for small edits
chmod u+x deploy.sh # owner may execute
chmod g-r secrets.txt # group may no longer read
chmod o= public.txt # remove all access for others
Numeric modes are great when declaring a complete policy; symbolic modes are safer when adjusting one bit. If ACLs, SELinux, or a network filesystem are involved, inspect those too—classic mode bits may not be the deciding rule.
Cover photo by Pixabay on Pexels.