If you want the simplest rule, here it is: the web server should be able to read the project, but it should only be able to write where the app truly needs it. That is the model that saves time and avoids permission chaos.
The mistake almost everyone makes
When a site breaks, many people jump to chmod -R 777. That may appear to fix the symptom, but it creates a bigger security problem and usually hides the real issue.
The safe baseline
- files:
644 - directories:
755 - only cache, uploads, logs, or storage folders should be writable
Who should own the project?
For many deployments, your deploy user owns the code, and the web server user only writes to specific runtime directories.
That often means:
- owner: your deploy user
- group: web server group or project group
- writable folders owned or grouped for
www-dataonly where necessary
A practical setup
sudo chown -R deploy:deploy /var/www/my-project
sudo find /var/www/my-project -type f -exec chmod 644 {} \;
sudo find /var/www/my-project -type d -exec chmod 755 {} \;
Make only runtime folders writable
Examples include:
storage/bootstrap/cache/var/uploads/
For those:
sudo chown -R www-data:www-data /var/www/my-project/storage
sudo chown -R www-data:www-data /var/www/my-project/bootstrap/cache
Check parent directory access too
Linux permissions are not only about the final folder. The web server must be able to traverse each parent directory.
namei -l /var/www/my-project/public
What permissions really mean
r: readw: writex: execute or traverse for directories
That last one matters a lot. A directory without execute permission can block access even when files inside look readable.
When to use groups
If both your deploy user and the web server need coordinated access, groups are often cleaner than making everything owned by www-data.
Common permission problems
- web server cannot write to cache or uploads
- project root is readable, but a parent directory blocks access
- everything is owned by root after a manual copy
- using 777 as a shortcut
Useful next reads
If permissions broke the app after a root change, read How to Fix 403 Forbidden After Changing Your Document Root. If PHP requests fail after deployment, check How to Fix 502 Bad Gateway with Nginx and PHP-FPM.
Quick FAQ
Should I ever use 777?
For normal web deployments, no. If you feel tempted, stop and find the real ownership problem.
Should www-data own the whole project?
Not usually. It is better for the web server to write only where needed.
What is the fastest safe baseline?
644 for files, 755 for directories, and selective writable folders only.