If you changed your document root and suddenly got a 403 Forbidden, the problem is usually simple: the web server can see the path, but it cannot serve the content from it correctly.
That usually means one of these things is wrong:
- the new root path is wrong
- permissions do not allow access
- there is no valid index file
- the server block or virtual host points to the wrong directory
Step 1: Check the actual root path in your config
For Nginx:
grep -R "root " /etc/nginx/sites-enabled/
For Apache:
grep -R "DocumentRoot" /etc/apache2/sites-enabled/
Make sure the path is real and points to the public web directory, not just the project root.
Step 2: Verify the folder exists
ls -lah /var/www/your-project
ls -lah /var/www/your-project/public
Framework apps usually want the public web server root to be public/, not the top-level project folder.
Step 3: Check permissions on every parent directory
This part wastes a lot of time. Even if the final folder has correct permissions, one parent directory can still block traversal.
namei -l /var/www/your-project/public
This command is excellent for spotting where access breaks.
Step 4: Make sure there is an index file
If there is no index.php or index.html and autoindex is disabled, some setups will return a 403.
Step 5: Check web server config syntax
sudo nginx -t
sudo apache2ctl configtest
Then reload the service you use.
Step 6: Look at the error log
For Nginx:
sudo tail -f /var/log/nginx/error.log
For Apache:
sudo tail -f /var/log/apache2/error.log
The log usually reveals whether the issue is permissions, forbidden indexing, or a bad path.
Step 7: Fix permissions safely
Do not use 777. If permissions are wrong, fix them correctly instead.
Read How to Set Correct Linux Permissions for Web Projects for the safe model.
Common 403 causes after changing the root
- root points to the wrong folder
- framework app should use
public/but server points to project root - missing
index.php - directory execute permissions missing on a parent folder
- web server user cannot read the files
Fast recovery checklist
- confirm the new path exists
- confirm the root points to the right public directory
- check permissions with
namei -l - check logs
- reload the web server
Useful next reads
If the site now shows 502 instead of 403, read How to Fix 502 Bad Gateway with Nginx and PHP-FPM. If you are still deciding on server layout, read How to Deploy a PHP App on Ubuntu Step by Step in 2026.
Quick FAQ
Can a missing index file really cause 403?
Yes. If directory listing is disabled and no default file is found, a 403 can happen.
Should the document root point to the framework root?
Usually no. For many frameworks, the correct root is the public/ directory.
Is 403 always a permission issue?
No. It can also be a root-path mistake or a server config rule.