I have been getting 403 errors for a new virtual server, and seem to have isolated it to this problem:
[Thu Oct 08 20:02:34.284519 2020] [authz_core:error] [pid 17001] [client 192.0.91.177:25093] AH01630: client denied by server configuration: /home/[redacted]
After having found all of the information about the 1630 error (and making sure all directives for access were in 2.4 and not 2.2 format), the error still occurs because the directory is wrong. It should be /home/[example] but it’s coming across as /home/[hostname.com].
What I can’t seem to understand is where it gets that directory from. The directives in the virtualmin->server->Services->Configure Website and Configure SSL Website both have the correct directory (and “Require all granted” instead of Allow/deny directives), and webmin->Servers->Apache Webservers->Global Configuration (in the Edit Config File) doesn’t have /home/[hostname.com] as a Directory entry anywhere that I can find.
Your authz configuration is pointing to that other directory, maybe via an automatically generated path based on the domain in the URL or similar. Virtualmin didn’t setup authz, so it won’t know about this. So…check your Apache config for authz, it’s probably in /etc/httpd/conf.modules.d, but could be anywhere in /etc/httpd.
In conf.modules.d the only .conf file with references to authz is 00-base, and it has seven LoadModule directives for core, dbd, dbm, groupfile, host, owner, and user. In conf.d autoindex and awstats both reference authz, as Required modules (autoindex) and in IfModule statements (awstats). It is not referenced in either file in conf/, those are all of the directories under /etc/httpd with config files.
Google has also been unhelpful, as I have not been able to locate any information about where a config file for authz might be found, or what it might be called.
I had removed all .htaccess file beforehand. I had actually added them because that came up as a potential solution for the 1630 error, but I hadn’t at that point noticed that the paths were completely wrong in the error log.
I finally located it. The setting in automatic virtual hosts was set from “none” to /home/%0/public_html ; changing this setting back to “None” resolved this issue.