Quick answer: A Magento 2 “403 Forbidden” usually means your web user doesn’t have read/execute access or the doc root/entry files have wrong permissions. Set standard Magento permissions (dirs 755, files 644), ensure correct owner:group for the web server user, clear caches, and reload Nginx/Apache. See the full commands below.
Symptoms
- Browser shows 403 Forbidden or “You don’t have permission to access … on this server”.
- Admin or storefront returns 403 after deploy, migration, or ownership change.
- Error log shows permission/denied entries or missing index permission.
Common causes
- Directories or files have incorrect mode (e.g., dirs 700 or files 600).
- Wrong owner/group after Composer deploy, rsync/SFTP, or CI pipeline.
- Server user (e.g.,
www-data,nginx,apache) lacks read/execute. - Nginx/Apache root or location config points to wrong path / missing index.
- SELinux/AppArmor or chroot constraints (less common).
Prerequisites
- SSH access with sudo privileges.
- Magento docroot path (e.g.,
/var/www/html/magento). - Web server user & group (e.g.,
www-data:www-dataon Ubuntu/Debian,nginx:nginxorapache:apacheon CentOS/RHEL).
Fix steps (Linux CLI)
Run these from the Magento root directory. Replace <user>:<group> with your web server user & group.
1) Set correct ownership
cd /var/www/html/magento
sudo chown -R <user>:<group> .
# Example:
# sudo chown -R www-data:www-data .2) Reset directory and file permissions
# Directories 755 (rwx for owner; rx for group/others)
find . -type d -exec chmod 755 {} \;
# Files 644 (rw for owner; r for group/others)
find . -type f -exec chmod 644 {} \;3) Ensure executables stay executable
chmod u+x bin/magento4) Give generated/var/pub the expected write access (owner = web user)
# If filesystem ownership matches the web user, 755/644 is typically enough.
# If you must use groups for write access:
sudo find var generated pub/static pub/media -type d -exec chmod 775 {} \;
sudo find var generated pub/static pub/media -type f -exec chmod 664 {} \;5) Clear caches
bin/magento cache:flushNote: Avoid using 777—this is insecure and can still fail with certain server configs.
Web server checks (Nginx/Apache)
Nginx
- Verify
rootpoints to the Magentopub/directory (production best practice). - Ensure
index.phpis listed in theindexdirective. - Reload:
sudo nginx -t && sudo systemctl reload nginx
Apache
- Set
DocumentRoottopub/(or enable provided rewrites if serving from root). - Allow overrides for Magento dirs (
AllowOverride Allwhere .htaccess is needed). - Reload:
sudo apachectl configtest && sudo systemctl reload apache2
Verify the fix
- Visit storefront and admin; 403 should be gone.
-
Check server logs for lingering permission denials:
# Nginx sudo tail -n 200 /var/log/nginx/error.log # Apache sudo tail -n 200 /var/log/apache2/error.log -
Run a quick static content deploy in production if needed:
bin/magento maintenance:enable bin/magento setup:di:compile bin/magento setup:static-content:deploy -f bin/magento cache:flush bin/magento maintenance:disable
Prevention & best practices
- Deploy as the web user (or fix ownership immediately post-deploy).
- Keep docroot set to
pub/in production. - Use CI tasks to normalize permissions after Composer install or artifact upload.
- Avoid 777; use correct owner/group and 775/664 where write is required.
- Track permission drift with a post-deploy script or Magento Cleanup task.
One-click post-deploy permissions
Automate permission & cache tasks with our deployment checklist.
Download the checklist (PDF)FAQ
What are the recommended Magento 2 permissions?+
Directories 755, files 644. For writable dirs (var, generated, pub/static, pub/media) you may use 775/664 when the web group needs write access.
Should I serve Magento from pub/?+
Yes—production best practice is to set docroot to pub/ for security and proper rewrite handling.
Does 403 mean my server is down?+
No. It indicates permission/authorization issues. Check ownership, modes, and web server config.
Will 777 fix it faster?+
Don’t use 777. It’s insecure and can still fail under certain security modules. Correct owner/group + 755/644 (or 775/664 where needed) is the right approach.