chmod and chown: how to fix Linux permissions without using 777
Published on 2026-10-26 by frfrand
Unix permissions users groups and file security on servers
A file returns «Permission denied» and someone recommends chmod 777. It can make the error disappear, but it also opens unnecessary permissions. It is better to understand who owns the file and what user runs the application.
I show you where the problem is, how to check it without guessing, and what I would do in an application that actually has users. You don't need to memorize an entire manual to solve a specific failure.
What chmod and chown mean in practice
chown changes the user or group owner; chmod adjusts read, write, and execute bits for owner, group, and others. Directory permissions determine whether a path can be traversed. In some environments, ACLs, mounting, and security policies also come into play.
A clarification before touching the server: if the project is already in production, save the state you found and check what user and machine you are going to run the commands on. Working as root without need and changing several things at once makes it harder to find the cause of an error.
Useful commands to get started
ls -ld /srv/miapp
ls -l /srv/miapp/config.json
id www-data
sudo chown -R deploy:deploy /srv/miapp
chmod 750 /srv/miapp
chmod 640 /srv/miapp/config.json
namei -l /srv/miapp/config.jsonPaths, unit names, and domains are examples. Adapt them to your service. If a command requires administrator permissions, review what changes and why. Diagnostic queries should come before modifications.
Step by step, with checks
- Identify with
systemctl catorpsthe user running the service. - Review owner and permissions of each directory in the path, not just the final file.
- Grant the minimum necessary access: read if it only needs to read, write in a specific folder if it must generate files.
- Test again as the service user, not as root.
- Document permissions so that the next deployment does not reset them incorrectly.
After each step, verify an observable result: a status, a file, an HTTP response, or a log entry. If you find an unexpected message, save it for investigation instead of hiding it with repeated restarts.
Real example: an application that needs maintenance
A Django backend runs as user webapp and needs to write photos to /srv/miapp/media, but the directory belongs to root. Fix only the uploads folder; do not make the entire project writable by any user.
At the end, test the full path: access via domain, call the API, write a test data point, and verify that the information remains after a controlled restart. A server that "starts" is not always an application that works.
Mistakes worth avoiding
The chown -R example changes all elements under a path: verify the path before executing. Avoid applying it recursively to /, /etc, or databases managed by the system.
It is also important that credentials do not end up in terminal history, logs, shared files, or screenshots. For users and services, use minimal permissions and document who can revoke access.
How ArduMaker fits into this scenario
In ArduMaker, separate application users from administrative users. VPS security includes file and service permissions, not just firewall and password.
ArduMaker can help you manage VPSs, deploy repositories, and work with services, databases, and domains from the same platform. It does not replace what we just explained about Linux: precisely for that reason, it is worth understanding the diagnosis and having a way to repeat it.
When it is worth automating it
If the task repeats, first document the manual procedure and its checks. Then consider a script or a scheduled task with visible errors, logs, and limited permissions. Do not automate a command that you still do not know how to recover when it goes wrong.
Frequently asked questions
Can I try it without affecting customers? In many cases, yes: a staging VPS or a separate test service allows you to validate the configuration before changing production.
How do I know it went well? Check logs and a functional operation, not just that the command ended with exit code zero.
When do I need more resources? When metrics indicate CPU, RAM, disk, or connection saturation. A configuration failure is rarely fixed by hiring more memory.
References
In one sentence: first understand the error, then change one concrete thing and check its effect. That discipline saves you many hours of support.