• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question Upstream Apache directive blocking .htaccess file directives

Bod

New Pleskian
Server operating system version
Debian 12
Plesk version and microupdate number
Version 18.0.59 Update #2
I have a .htaccess file that uses the RewriteEngine but as soon as I set this to on, I get a 403 error.

This entry is in the /etc/apache2/apache2.conf file:

Code:
<Directory /var/www/>
    <Files ~ (\.pl$)>
        SetHandler cgi-script
        Options ExecCGI
        allow from all
    </Files>
    AddHandler cgi-script .pl
    Options ExecCGI Indexes FollowSymLinks SymLinksIfOwnerMatch
    AllowOverride All
    Require all granted
</Directory>

The error log shows Options FollowSymLinks and SymLinksIfOwnerMatch are both off, so the RewriteRule directive is also forbidden due to its similar ability to circumvent directory restrictions which doesn't make sense to me. In the conf file we are setting FollowSymLinks and SymLinksIfOwnerMatch so what are they being reported as being off?

I have restarted Apache after making the changes to the conf file.
Any suggestions what else I should be looking at?

I have limited knowledge of Apache so any feedback on the above directive would be appreciated as well as some help troubleshooting the .htaccess file :)
 
You'll for sure need to remove "FollowSymlinks" and only leave "SymLinksIfOwnerMatch", because by default symbolic links are only allowed for the same owner. If you have the normal "FollowSymlinks" in the statement, it will fail.

About the other entries: I do not know more. 403 is a permission issue. It could either result from the Handler (which might not exist) or it could be ModSecurity interfering with a request. It is also possible that the physical file permissions don't allow access.
 
Thanks Peter.

I am pretty sure it is not a permission error on the .htaccess file. Apache must be able to open it to generate the error it gives! Besides, if I take out the contents of the file and just leave a blank file, the 403 error goes. So it's what is in the file that is clashing with the upstream directives rather than the file itself.

I've taken out FollowSymlinks from the conf file as you suggested, but no change to the behaviour.
 
I didn't mean to say it's a permission issue with the .htaccess file, but that it could be an issue with the file permissions of files that are addressed by a request.
 
it could be an issue with the file permissions of files that are addressed by a request
Could it as the files are correctly served when the .htaccess is removed/renamed?
 
We have still made no progress with this problem.
Has anyone else seen a similar issue? How did you solve it?
 
Back
Top