3 min read

How to Set Correct Linux Permissions for Web Projects

A simple guide to Linux permissions for web projects, including owners, groups, readable paths, writable folders, and why 777 is the wrong fix.

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-data only 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: read
  • w: write
  • x: 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.

Linux Mar 28, 2026