403 Forbidden Apache error
An Apache 403 error, also known as "403 Forbidden," is an HTTP status code that indicates the server understood the request, but it refuses to authorize it. In simpler terms, it means the server is refusing to fulfill the request due to insufficient permissions. There are several reasons why you might encounter a 403 error:
- Insufficient permissions: The user trying to access the resource doesn't have the necessary permissions
- Incorrect file or directory permissions: The file or directory you're trying to access doesn't have the appropriate permissions set. This could be due to incorrect permissions set by the server administrator or a misconfiguration
- IP blocking or access restrictions: The server may be configured to block access from certain IP addresses or ranges, or it may have other access restrictions in place
- Authentication issues: If the resource requires authentication, but the user hasn't provided valid credentials, or the credentials provided are incorrect, the server will return a 403 error
- Resource availability: Sometimes, the server may return a 403 error if the requested resource is unavailable for some reason, such as being temporarily offline or removed.
When troubleshooting a 403 error, it's essential to check the server logs for more detailed information about why the request was forbidden. This can help pinpoint the exact cause of the error and guide the resolution process.
One way to access the Apache error log:
tail /var/log/apache2/error.log
Due to index.php?
It's possible that the issue lies within the PHP file itself, especially if the PHP code includes logic or configurations that restrict access based on specific conditions such as the URL or client IP address. Here are some scenarios where the PHP file itself could be causing the access denial:
- URL-based restrictions: The PHP code may contain logic to restrict access based on the URL from which the request originated. If the PHP file contains code to check the URL and deny access to certain URLs, it could lead to the server denying access when the site is cloned to another URL
- IP-based restrictions: Similarly, the PHP code may include IP-based access restrictions that deny access to certain clients or IP ranges. If the cloned site is accessed from an IP address that is restricted by the PHP code, it could result in the server denying access
- Authentication: The PHP code may require authentication, and if the credentials provided are incorrect or missing, it could lead to access denial.
Case: After migration to laptop (2024.04)
Context: Cloning a website from a webserver to my laptop for testing & troubleshooting.
Possible causes:
- Specific server-sided stuff, like caching. Maybe through
/wp-admin.php
- Stuff in
wp-config.php
that indicates that the site shouldn't be available under another URL
Additional information
- Placing a
index.html
file in the root of the site, worked: The html file got just executed as expected. Placing back theindex.php
recreated the problem - Liberating file rights, didn't make a change - Up to
777
- Renaming and later removing
.htaccess
file - No difference - Removing anything from
wp-config.php
related to maybe other things like caching - No difference.
Last 4 log lines (only the last 2 are actually relevant, in hindsight):
[mpm_prefork:notice] [pid 926] AH00163: Apache/2.4.41 (Ubuntu) configured -- resuming normal operations [core:notice] [pid 926] AH00094: Command line: '/usr/sbin/apache2' [access_compat:error] [pid 949] [client 127.0.0.1:39434] AH01797: client denied by server configuration: /var/www/de.de/index.php [access_compat:error] [pid 19893] [client 127.0.0.1:39438] AH01797: client denied by server configuration: /var/www/de.de/index.php Etc.
The [access_compat:error]
part of the log entry suggests that the issue might be related to the Apache module mod_access_compat
, which provides compatibility with the older access control syntax used in Apache 2.2.
Note that it looks like the index.php
, hasn't been executed yet, but there is an issue with the access module. There is nothing like that in the actual index.php file → Check for something around Apache, e.g., here sudo vim /etc/apache2/sites-available/de.de.conf
→ Got it:
Cause
There was an old version of the script add_domain
. It contained the erroneous lines:
<FilesMatch "\.php$"> Deny from all </FilesMatch>
and that caused the problem: No PHP file was allowed to be executed.
Review
How to do this faster next time:
- ChatGPT really helped - quite a surprise
- The fact that there