The 403 Forbidden error appears when your server denies you permission to access a page on your site. This is mainly caused by a faulty security plugin, a corrupt . htaccess file, or incorrect file permissions on your server.
A 403 error occurs when a server won't allow you to access a webpage. You can't always fix a 403 error on your own, but simple tricks like refreshing your page or clearing your cache could help. If visitors to your webpage are getting 403 errors, you may have to reconfigure it.
Check that :
Additionally, you can look at the error.log file (usually located at /var/log/apache2/error.log
) which will describe why you get the 403 error exactly.
Finally, you may want to restart apache, just to be sure all that configuration is applied.
This can be generally done with /etc/init.d/apache2 restart
. On some system, the script will be called httpd. Just figure out.
I just fixed this issue after struggling for a few days. Here's what worked for me:
First, check your Apache error_log
file and look at the most recent error message.
If it says something like:
access to /mySite denied (filesystem path
'/Users/myusername/Sites/mySite') because search permissions
are missing on a component of the path
then there is a problem with your file permissions. You can fix them by running these commands from the terminal:
$ cd /Users/myusername/Sites/mySite
$ find . -type f -exec chmod 644 {} \;
$ find . -type d -exec chmod 755 {} \;
Then, refresh the URL where your website should be (such as http://localhost/mySite
).
If you're still getting a 403 error, and if your Apache error_log
still says the same thing, then progressively move up your directory tree, adjusting the directory permissions as you go. You can do this from the terminal by:
$ cd ..
$ chmod 755 mySite
If necessary, continue with:
$ cd ..
$ chmod Sites
and, if necessary,
$ cd ..
$ chmod myusername
DO NOT go up farther than that. You could royally mess up your system.
If you still get the error that says search permissions are missing on a component of the path
, I don't know what you should do. However, I encountered a different error (the one below) which I fixed as follows:
If your error_log
says something like:
client denied by server configuration:
/Users/myusername/Sites/mySite
then your problem is not with your file permissions, but instead with your Apache configuration.
Notice that in your httpd.conf
file, you will see a default configuration like this (Apache 2.4+):
<Directory />
AllowOverride none
Require all denied
</Directory>
or like this (Apache 2.2):
<Directory />
Order deny,allow
Deny from all
</Directory>
DO NOT change this! We will not override these permissions globally, but instead in your httpd-vhosts.conf
file.
First, however, make sure that your vhost Include
line in httpd.conf
is uncommented. It should look like this. (Your exact path may be different.)
# Virtual hosts
Include etc/extra/httpd-vhosts.conf
Now, open the httpd-vhosts.conf
file that you just Include
d. Add an entry for your webpage if you don't already have one. It should look something like this. The DocumentRoot
and Directory
paths should be identical, and should point to wherever your index.html
or index.php
file is located. For me, that's within the public
subdirectory.
For Apache 2.2:
<VirtualHost *:80>
# ServerAdmin [email protected]
DocumentRoot "/Users/myusername/Sites/mySite/public"
ServerName mysite
# ErrorLog "logs/dummy-host2.example.com-error_log"
# CustomLog "logs/dummy-host2.example.com-access_log" common
<Directory "/Users/myusername/Sites/mySite/public">
Options Indexes FollowSymLinks Includes ExecCGI
AllowOverride All
Order allow,deny
Allow from all
Require all granted
</Directory>
</VirtualHost>
The lines saying
AllowOverride All
Require all granted
are critical for Apache 2.4+. Without these, you will not be overriding the default Apache settings specified in httpd.conf
. Note that if you are using Apache 2.2, these lines should instead say
Order allow,deny
Allow from all
This change has been a major source of confusion for googlers of this problem, such as I, because copy-pasting these Apache 2.2 lines will not work in Apache 2.4+, and the Apache 2.2 lines are still commonly found on older help threads.
Once you have saved your changes, restart Apache. The command for this will depend on your OS and installation, so google that separately if you need help with it.
I hope this helps someone else!
PS: If you are having trouble finding these .conf
files, try running the find
command, such as:
$ find / -name httpd.conf
restorecon
command works as below :
restorecon -v -R /var/www/html/
it doesn't, however, solve the problem, because on e.g. open SUSE Tumbleweed, custom source build is triggering the same 401 error on default web page, which is configured accordingly with Indexes and
Require all granted
The server may need read permission for your home directory and .htaccess therein
Notice that another issue that might be causing this is that, the "FollowSymLinks" option of a parent directory might have been mistakenly overwritten by the options of your project's directory. This was the case for me and made me pull my hair until I found out the cause!
Here's an example of such a mistake:
<Directory />
Options FollowSymLinks
AllowOverride all
Require all denied
</Directory>
<Directory /var/www/>
Options Indexes # <--- NOT OK! It's overwriting the above option of the "/" directory.
AllowOverride all
Require all granted
</Directory>
So now if you check the Apache's log message(tail -n 50 -f /var/www/html/{the_error_log_file_of_your_site}
) you'll see such an error:
Options FollowSymLinks and SymLinksIfOwnerMatch are both off, so the RewriteRule directive
is also forbidden due to its similar ability to circumvent directory restrictions
That's because Indexes
in the above rules for /var/www
directory is overwriting the FolowSymLinks
of the /
directory. So now that you know the cause, in order to fix it, you can do many things depending on your need. For instance:
<Directory />
Options FollowSymLinks
AllowOverride all
Require all denied
</Directory>
<Directory /var/www/>
Options FollowSymLinks Indexes # <--- OK.
AllowOverride all
Require all granted
</Directory>
Or even this:
<Directory />
Options FollowSymLinks
AllowOverride all
Require all denied
</Directory>
<Directory /var/www/>
Options -Indexes # <--- OK as well! It will NOT cause an overwrite.
AllowOverride all
Require all granted
</Directory>
The example above will not cause the overwrite issue, because in Apache, if an option is "+" it will overwrite the "+"s only, and if it's a "-", it will overwrite the "-"s... (Don't ask me for a reference on that though, it's just my interpretation of an Apache's error message(checked through journalctl -xe
) which says: Either all Options must start with + or -, or no Option may.
when an option has a sign, but another one doesn't(E.g., FollowSymLinks -Indexes). So it's my personal conclusion -thus should be taken with a grain of salt- that if I've used -Indexes
as the option, that will be considered as a whole distinct set of options by the Apache from the other option in the "/" which doesn't have any signs on it, and so no annoying rewrites will occur in the end, which I could successfully confirm by the above rules in a project directory of my own).
Hope that this will help you pull much less of your hair! :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With