56

Ok, so i've previously set up two virtual hosts and they are working cool. they both house simple web projects and work fine with http://project1 and http://project2 in the browser.

Anyway, I've come to add another vhost. I edited the /etc/hosts file with 127.0.0.1 project3 and also updated the httpd-vhosts.conf file by copy and pasting the previous entries for project2 and editing the file path.

I've checked all the file and folder permissions (in fact I copied and pasted from project2) and simply put a "hello world" message in the index.php file.

I get a 403 forbidden permission denied message when accessing http://project3

Why is this, I just can figure out what step I've missed as everything seems to be set up correct.

2
  • Did you restart Apache? Commented Aug 26, 2013 at 15:31
  • In case SELinux is enabled, please check SELinux permissions as well. Here is a good reference - techtarget.com/searchdatacenter/tip/… Commented Jan 18, 2024 at 20:26

9 Answers 9

51

Check that :

  • Apache can physically access the file (the user that run apache, probably www-data or apache, can access the file in the filesystem). For instance, you can use sudo su www-data to start a shell session as www-data.
  • Apache can list the content of the folder (read permission)
  • Apache has a "Allow" directive for that folder. There should be one for /var/www/, you can check default vhost as an example.

Additionally, you can look at the error.log file (usually located at /var/log/apache2/error.log) which will describe why you are getting 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 or systemctl restart apache2. On some system, the script will be called httpd. Just try to figure out.

Sign up to request clarification or add additional context in comments.

6 Comments

hmmm i get "client denied by server configuration"... any clues? thnx
no wait! I think I got it. I restarted apachectl and seems to work. Cant believe it was that simple. Thanks
the additional part solved my issue, get the actual error from the error log.
I was missing the allow directive. Thanks
I don't see any issues with what's named above, but still getting the error. Interestingly, the /var/log/apache2/error.log file has only two lines. First: "<date time> [mpm_prefork:notice] [pid 2302] " and so on. Second: "<date time>[core:notice] [pid 2302] AH00094: Command line:" and so on. Where else might I look?
|
35

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 Included. 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 

3 Comments

Great answer, I had the conflict between versions (I am 2.4+) which was causing the "client denied by server configuration" error.
It was ExecCGI missing for PHP. Thanks for the pointer!
For point 1, I needed to do until chmod 755 myusername to make it work.
8

restorecon command works as below :

restorecon -v -R /var/www/html/ 

3 Comments

what is this supposed to do?
apt install policycoreutils then man restorecon, restore files default SELinux security contexts (-v: show changes, -R recursive).
this should be upvoted
2

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! :)

Comments

2

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 

Comments

1

The server may need read permission for your home directory and .htaccess therein

1 Comment

Once I made the home directory of the user /home/username, the public_html folder was in, executable by group and others using: chmod 711 /home/username I was able to get rid of the 403 error. Only thought I needed execution rights for public_html as the folder inside of it was the Webroot as I understood reading petefreitag.com/item/793.cfm . But I was wrong.
1

Add

<Directory "/path/to/webroot"> Options Indexes FollowSymLinks Includes ExecCGI AllowOverride All Order allow, deny Allow from all Require all granted </Directory> 

What this does is tell Apache2 to override any previous configs, and allow (200) from all before denying. (403) It also requires all requests to be granted. This code will have to go in every vhost file, but it does work. I have been using this for over a year.

to your config file (e.g. /etc/apache2/sites-enabled/000-default.conf) Tested LAMP stack Debian 11

1 Comment

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
0

You can try disabling selinux and try once again using the following command

setenforce 0 

Comments

0

In my case it was failing as the IP of my source server was not whitelisted in the target server.

For e.g. I was trying to access https://prodcat.ref.test.co.uk from application running on my source server. On source server find IP by ifconfig

This IP should be whitelisted in the target Server's apache config file. If its not then get it whitelist.

Steps to add a IP for whitelisting (if you control the target server as well) ssh to the apache server sudo su - cd /usr/local/apache/conf/extra (actual directories can be different based on your config)

Find the config file for the target application for e.g. prodcat-443.conf

RewriteCond %{REMOTE_ADDR} <YOUR Server's IP> for e.g. RewriteCond %{REMOTE_ADDR} !^192\.68\.2\.98 

Hope this helps someone

Comments