Suddenly access denied by server configuration?

Richard G

Verified User
Joined
Jul 6, 2008
Messages
12,560
Location
Maastricht
I did not do anything special with my servers, except upgrading ofcourse.

Now one of my users has an issue with his site/script.
In januari all ran fine, he did not change anything and since he was ill, he could not do anything and did not visit the site either.

This week he visited again for the first time and the site is not reachable anymore. The error log says this:
Code:
AH01797: client denied by server configuration: /home/user/domains/domain.be/public_html/index.shtml, referer: http://www.domain.be/
However, there is no index.shtml present in there.

Next to that when I remove the .htaccess file, we get a page error and in the url bar it says:
https://domain.be/domains/domain.be/public_html/

which is also odd. Looks like some path or rewrite error, but the user has not touched the site since january.

Is there some Apache, PHP or DA upgrade which could cause this behaviour? Since it says access:compat error? Is this module suddenly disabled after an upgrade or something?
Until now, no other users experience issues.
 
Last edited:
Is there something different in the virual host?
 
Not as far as I know, i did not change anything.
Just to be sure everything was alright I ran the "rewrite_confs" command this afternoon, but no changes with the issue.

I've installed the same script on a hobby account without issues. The user put back a working back-up of last year, but still a problem.
So it might be something which was used in the script, which suddenly gave these errors, probably after a minor apache or php update this year.

We'll do a script update on his account later this evening and see if that will fix the issues.
 
Check for .htaccess in upper directory...

Also check for "Custom HTTPD configuration" - there is an option in DA for that in the user level.
 
There is a .htacces file in /home/user/ but has only this content:
Code:
##------Forceer HTTPS verbinding geheel domein------##
 RewriteEngine On
 RewriteCond %{HTTPS} !=on
 RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
 ##
So this should not be an issue as far as I know.

The "custom HTTPD configuration" is only present in admin sections.
Users only have Apache handlers and Custom Error Pages but there are none installed.

Going to try the script update now.
 
Script update not possible, since you have to be able to login to the admin panel.
Which is not possible due to the white page issue. :(

The virtual host files, those are in /usr/local/directadmin/data/users/username/http.conf right?
I checked this with other accounts and except for the accountname there are no differences, so it's not the virtual host either.
 
Fixed.

It was indeed what I suspected, something in the script which suddenly became incompatible, also a backup did not work which made me think further.
A new install of a new version on the same account under a different subdirectory worked.
After that I found a developer option in a config which did show errors instead of a white screen. That way I could create a temp solution which made the site working again (with some not shown errors).
So now user has to upgrade the site.

Thank you Awd and wattie for the help though!
 
Problem is NOT fixed.

So I installed a new version script for my friend, next to that I installed a fresh script on a test account of myself. Both keep getting the same error in the log like this:
Code:
[authz_core:error] [pid 8915] [client 66.249.xxx.xxx:42941] AH01630: client denied by server configuration: /home/user/domains/domain.be/private_html/index.shtml

And loads like this:
Code:
[authz_core:error] [pid 6623] [client 54.36..xxx.xxx:38836] AH01630: client denied by server configuration: /home/user/domains/domain.be/public_html/data/system/modules/user/avatar/img/biglion369

Also seen with private_html in the log which is symlinked to public_html.

I went in Firefox console and found this error, but don't know if it has something to do with it.
Translated it myself from Dutch to English:
Code:
Error on source-allocation: request failed with status 404 Source-URL: http://myhobby.domain.com/script/static/js/jquery/jquery.js Resourceallocation-URL: jquery.min.map
We don't have a clue why the Resourceallocation-url (bron toewijzings-url) is that jquery.min.map as that file does not exists in the users account.

I did found another error, another deny thing.
That was allowmethods did not allow OPTIONS to be used, so I added this to the http_methods in custombuilds options.conf but that did not clear this problem.

Now it must be something which is blocked in Apache or something by DA. Because to test, I had this script installed on a cpanel server.
There it works without a single error also with Apache 2.4.33 and PHP 5.6.36 with mod_ruid2 as on my DA server. Same on fresh installs.

So the strange index.shtml error and the authz_core:error ('s) must come from some piece of configuration on the DA server with apache.
Even on my testdomain with that index.sthml, no custom httpd configuration, no other .htaccess then the default of the script. Installed exactly the same as on the cpanel server.
 
Now I found the cause, but I'm even more confused. This is from the scripts .htaccess file.

If I disable this (like I did below, then the strange index.shtml errors (and probably the other auth_core errors) are gone from the log.

Code:
# Deny access to all CGI, Perl, Python, Bash, SQL, Template, INI configuration, cache, log, temporary and text files
#<FilesMatch "\.(cgi|pl|py|sh|bash|sql|tpl|ini|cache|log|tmp|txt)">
#    # Apache 2.4+
#    <IfModule mod_authz_core.c>
#        Require all denied
#    </IfModule>

#    # Apache 2.2
#    <IfModule !mod_authz_core.c>
#        Deny from all
#    </IfModule>
#</FilesMatch>

Now I investaged further and it is the sh statement. If I remove sh from the line, the error is gone! That should not happen, correct?

But this confuses me. Why does this have such big effect on DA servers with apache and not on Cpanel server with apache? Same apache, same php, and mod_ruid2?
 
Last edited:
Not sure why it worked in other environments, but the regular expression in your case matches the .sh from the index.shtml. I think if you add an anchor ($) to the end of the expression, that might just work. It should tell Apache to only match .sh not .shmtl since the anchor prevents any more characters from being matched. See the example here https://httpd.apache.org/docs/2.4/mod/core.html
 
But where is that index.shtml coming from then? Must be from apache some way, because the script is only using php files.

This also still does not explain why these errors occur only on the DA configured server:
Code:
[authz_core:error] [pid 29214] [client 54.36.xxx.xxx:39680] AH01630: client denied by server configuration: /home/user/domains/domain.be/public_html/data/system/modules/user/avatar/img/crazyleopard197
 
This is completely normal.
Code:
<FilesMatch "\.(cgi|pl|py|sh|bash|sql|ini|cache|tpl|log|tmp|txt)">

It means it's matching .cgi, .pl, .py, .sh etc. index.shhtml also matches the rule :) It has a ".sh" in the name. If you'd like it to match .sh ending only, you should add $ to the end of the rule.
 
and what if you install the script in public.html and link it with symbolic link or the aother way around? Does it generate the same errors?
I see public.html and private.html folders in the errors.
 
Last edited:
Yes, same errors. I see private_html and public_html errors in almost all sites which got SSL enabled. Probably because of the private_html -> public_html symlink.

We discovered what was the issue.
It's indeed as Toml and SMTalk said, it's blocked by the .htaccess.

So I wondered why because there is no index.shtml on the complete server. But apache is trying to load index.sthml if exists. So Apache looks if it exists which causes the block to kick in and generates the access denied in the logs.

The blocks to the avatars were caused by a block to cache entry in the .htaccess and by variuos requests to avatars which did not exist anymore.
 
I have a theory on where the errors are coming from. I can see in my httpd.conf file (default DA) that the DirectoryIndex is as follows:
Code:
     DirectoryIndex index.html index.htm index.shtml index.php index.php5 index.php4 index.php3 index.phtml index.cgi index.pl
If you don't have an index.html or an index.htm in that directory, it will then look for index.shtml which could then trigger the error based on the FilesMatch matching the .sh in index.shtml.
 
That's just what I said toml, only a bit shorter. :)
Richard G said:
But apache is trying to load index.sthml if exists. So Apache looks if it exists which causes the block to kick in and generates the access denied in the logs.
So it's ignorable.
In cpanel they order index.php first these days, that's why this did not occur on that server.
 
Back
Top