Apache "Forbidden: You don't have permission to access this resource

The browser shows:

Forbidden
You don't have permission to access this resource.

Older Apache versions say "You don't have permission to access /path on this server." The status is 403. The page is the same for six or seven quite different causes, so the only reliable move is to read the error log line, which names the real reason.

The existing page on AH01630 client denied by server configuration covers access rules in detail. This page is the decision tree for everything else.

Step 1: read the log

sudo tail -n 20 /var/log/apache2/error.log     # Debian, Ubuntu
sudo tail -n 20 /var/log/httpd/error_log       # RHEL, Rocky, Alma

Match the message to a row:

Step 2: file and directory permissions

Apache runs as www-data (Debian, Ubuntu) or apache (RHEL family). That user needs execute permission on every directory from / down to the document root, and read permission on the files.

namei -l /var/www/example.com/public/index.html

namei -l lists owner and mode for each path component. Look for a component without x for others, for example a home directory at 700, which is the typical problem when the site lives under /home/user/. Typical safe settings:

sudo find /var/www/example.com -type d -exec chmod 755 {} \;
sudo find /var/www/example.com -type f -exec chmod 644 {} \;

Do not use chmod 777; it hides the cause and opens the site to tampering. Where ownership is the issue, chown -R deploy:www-data with group read access is cleaner than world-readable files.

Step 3: missing index file

If the request is for a directory such as /, Apache looks for a file named in DirectoryIndex (by default index.html). If it finds none and Options Indexes is off, it returns 403. Either add an index file or tell Apache which name to use:

DirectoryIndex index.php index.html

Only enable Options +Indexes when you really want a public file listing.

Step 4: SELinux

On RHEL-family systems with SELinux enforcing, files must carry the httpd_sys_content_t label. Permissions look perfect but access is still denied, and the audit log shows an AVC entry.

ls -Zd /var/www/example.com/public
sudo ausearch -m avc -ts recent | tail
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/site(/.*)?"
sudo restorecon -Rv /srv/site

A site root in a custom path like /srv/site needs that semanage rule. Setting SELinux to permissive for a test is fine, but do not leave it disabled as the fix.

Step 5: when nothing is in Apache's log

Another layer may be answering. Check the response headers with the HTTP Header Checker. A Server: cloudflare or other CDN header, a WAF block page, hosting-level IP blocks, or nginx in front means the 403 is not from Apache. Compare against a direct request to the origin IP with a Host header. If Apache is the one answering, also review mod_security, mod_evasive and any Require not ip rules. The general meaning of the status is in the HTTP 403 reference और HTTP 403 Forbidden fix.

Step 6: DocumentRoot mismatch

A vhost pointing at the wrong DocumentRoot, or a Directory block that does not cover the new path, falls back to the default Require all denied that Debian sets on /. Check the effective config:

apachectl -S
apachectl -t -D DUMP_VHOSTS

And make sure the Directory block for the real path says Require all granted.

How to verify

Request the page again and confirm 200 with the HTTP स्टेटस चेकर. Then test a static file and a subdirectory, since permissions often fail only deeper in the tree. Keep an अपटाइम मॉनिटर on the homepage to catch the next permission regression after a deploy.

अगले कदम

• Read AH01630 client denied by server configuration.
• See the nginx version in nginx 403 Forbidden fix.
• Review HTTP 403 Forbidden fix.
• Check the वेबसाइट हेल्थ चेक.

सामान्य प्रश्न

Why do I get 403 on a brand-new site?

Almost always because the document root is outside /var/www and has no Require all granted block, or because a parent directory is not traversable by the Apache user.

Is chmod 777 a valid fix?

It may make the error disappear, but it exposes your files to every local user and is a security risk. Use 755 for directories and 644 for files instead.

Why does it only fail on a subpage?

A subdirectory can have its own .htaccess with a deny rule or restrictive permissions. Test deeper paths separately.

Does a 403 mean the page exists?

Not always. Apache may deny access before checking whether the file exists, so a 403 does not confirm the resource is there.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.