.htaccess: Option FollowSymLinks not allowed here

I have defined the apache template with the following for the directory specific:

<Directory ${HOME}/public_html>
Options -Indexes +IncludesNOEXEC +FollowSymLinks
allow from all
AllowOverride All

But everytime when I create a new virtual server, the AllowOverride All gets appended with the following result:

<Directory /home/test/public_html>
Options -Indexes +IncludesNOEXEC +SymLinksifOwnerMatch +ExecCGI
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
AddHandler fcgid-script .php
AddHandler fcgid-script .php5
FCGIWrapper /home/test/fcgi-bin/php5.fcgi .php
FCGIWrapper /home/test/fcgi-bin/php5.fcgi .php5

How can I remove Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch from being automatically added? This causes error 500 with the following error:

.htaccess: Option FollowSymLinks not allowed here

Actually you should not prevent those Options from being added, since they are part of a security fix that could cause all your websites to be compromised if one of them gets hacked.

Then is there anyway to alter the options that are being added? Because it doesn’t work well with the Options used in .htaccess which Drupal needs it.

Also, I just realized that the whole directive in the directory is being altered. I’m having trouble to find the file that’s causing the alteration :frowning:

I’ve just found out that there are other forum posts similar to this, after I used the correct keyword to search.

I guess this seems to be a huge fix to the security hole for FollowSymlinks. In fact, there is a discussion going on in Drupal to change FollowSymLinks to SymLinksifOwnerMatch: http://drupal.org/node/1269780

For those who are hosting your current clients, you can easily update the .htaccess for them to use SymLinksIfOwnerMatch by executing the following bash command:

find /home -name “.htaccess” -type f -exec sed -i ‘s/FollowSymLinks/SymLinksIfOwnerMatch/g’ {} “;”

Do backup your files first before you perform this, just in case something goes wrong :slight_smile:

Will be updating the post title for better understanding on the issue.

I too am having this issue, no matter what I put in the apache directives, virtualmin appends the same line as the OP posts.

It will also append this line if a backup is restored… incredibly irritating…

oh and by the way, some websites do not work with SymLinksIfOwnerMatch - namely, magento. It REQUIRES FollowSymLinks to function properly…

this current behaviour is creating a nightmare for me


As already mentioned, the change was part of a patch release of Virtualmin recently. It is not recommended to use FollowSymLinks. While I understand that some scripts dont’ work with the recommended, secure method, it may be better to contact the developer of the scripts and ask them to adjust their scripts to help them to enforce better security measures, rather than working on a way to make your system less secure. Though, I do understand that it is a bummer if you are using scripts which don’t work quite right with the currently enforced settings.

*** Generally speaking, SymLinksIfOwnerMatch won’t be a problem if you have a dedicated copy of a script and related files within the domain’s directory and therefore not Symbolically linked. ***

Magento works with SymLinksIfOwnerMatch, you just need to update the Magento .htaccess files to use that rather than FollowSymLinks.

Any Virtualmin site that uses FollowSymLinks can be exploited to allow that user to read all files in /home. That was creating a nightmare of a different sort :slight_smile:

To solve the issue you’re seeing, I’d recommend just updating Magento’s .htaccess files.

However, if you don’t wish to do that, and you are okay with the security issues that exist, you can always prevent Virtualmin from applying that fix in the future by editing the file /etc/webmin/virtual-server/config and adding the line allow_symlinks=1 to the end of the file.



I have a Magento website and I use the best panel: Virtualmin! I do not want to change it, but as you know Virtualmin doesn’t work (500 ERROR) with FollowSymLinks which is in the .htaccess ;(

I know, I can change it to: SymLinksIfOwnerMatch, but there as some security issues ;( Do security issues affect a website or Virtualmin?

I have a dedicated server with 1 admin only, so the others can not log in into Virtualmin panel.

The most important think is having a secured Magento.

What should I do:
Should I change option into: SymLinksIfOwnerMatch or change Virtualmin…

Please advice

Virtualmin doesn’t work (500 ERROR) with FollowSymLinks which is in the .htaccess

Well, Virtualmin configures Apache not to allow that, as allowing it enables users on your system to be able to read any files in /home.

I know, I can change it to: SymLinksIfOwnerMatch, but there as some security issues ;( Do security issues affect a website or Virtualmin?

I would highly recommend changing the htaccess file to “SymLinksIfOwnerMatch”, I’m not aware of any security issues with that. It’s actually the other way around, not using that is a huge security issue.

You can disable this security fix if you want, though that’s not something I’d recommend.

It may not matter as much though if all the users on your system are trusted.


Had the same issue with Virtualmin. In my case it worked by changing to SymLinksIfOwnerMatch…

find /home -name “.htaccess” -type f -exec sed -i ‘s/FollowSymLinks/SymLinksIfOwnerMatch/g’ {} “;”

Solved it for me

If anyone’s still struggling with this, I think I’ve found a better solution, at least for my situation.

I’m using Virtualmin to manage a VPS that contains several sites, all owned by me or my friends. I use a variety of common content management systems, including Drupal and Magento, both of which try to enable FollowSymLinks in their .htaccess files. Whenever these CMS systems are updated (e.g. using Drush or Magento Connect Manager), my sites stop working with an unhelpful 500 error until I remember that I have to hack the .htaccess files each time.

In my humble opinion, both Drupal and Magento should be fixed to use SymLinksIfOwnerMatch instead. Appropriate bugs/enhancement requests exist for both platforms but don’t hold your breath waiting for a resolution.

Meanwhile I investigated the “security vulnerability” that would be caused by enabling FollowSymLinks for these domains on my VPS and it doesn’t seem to be too serious. Basically it means one hacked user might be able to access another’s files, which would be very bad on shared hosting but not so bad on a VPS owned by one person. So I want to override the Virtualmin behaviour for the affected domains.

The way I found to do this is to go to Services > Configure Website > Edit Directives for the Virtualmin domain in question, find the line that says “AllowOverride All Options=…” under Directory /home/[domain]/public_html and add FollowSymLinks to the end of the list of options so it becomes
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch,FollowSymLinks

It’s still a good idea to change a newly-updated .htaccess file for Drupal or Magento to enable SymLinksIfOwnerMatch instead of FollowSymLinks, but at least you won’t get a 500 error in the meantime. In fact I think all you need to do is comment out the Options +FollowSymLinks line since Virtualmin enables SymLinksIfOwnerMatch by default.

Hope this helps someone.

No, please do NOT do this. Do not purposely disable security features just because they are inconvenient. You are just asking for trouble by doing this! All you need to do is remove the invalid syntax from the htaccess file.

Not sure what you mean by “invalid syntax” - I think you meant “forbidden option” or something.

Just to be clear, I’m NOT advocating any change in Webmin/Virtualmin. I was only discussing situations like mine where there’s only one user on a VPS.

I think Drupal and Magento should change though - there’s no security risk in using SymLinksIfOwnerMatch as far as I know.

This issue has been floating around for some time. I wanted to draw attention to Apache’s viewpoint which is that You should avoid using .htaccess files completely if you have access to httpd main server config file. which can be found at http://httpd.apache.org/docs/current/howto/htaccess.html .

As admins we do have access to the main configuration files so we should be focusing on other solutions, such as using Include which can be found at http://httpd.apache.org/docs/2.4/mod/core.html#include .

I am still getting my head round how to tie everything up properly but using SymLinksIfOwnerMatch with Include in your .conf will be secure and prevent unneeded .htaccess lookups.

Some will be setting up bare bone servers for clients who may not be given configuration access so this will not apply but just wanted to float this to see if any have a solid workflow for setting this up for those who do have configuration access rights…

I’m not a bash scripter but something like this does the job for me.
No error checking, so take care.
If someone is skilled enough to make this script more robust, be my guest!

Add this function to your .bashrc or .profile script (I think .bashrc is most appropriate)

function sedsymlinks(){ base="/home/" public="/public_html" files="/sites/default/files" rootpath=$base$1$public/.htaccess filepath=$base$1$public$files/.htaccess

echo ‘-------START-------’
echo 'changing .htaccess +FollowSymLinks to +SymLinksIfOwnerMatch in '$rootpath
sed -i -e ‘s/+FollowSymLinks/+SymLinksIfOwnerMatch/g’ $rootpath
head -16 $rootpath
echo ‘---------0----------’
echo 'changing .htaccess +FollowSymLinks to +SymLinksIfOwnerMatch in '$filepath
sed -i -e ‘s/+FollowSymLinks/+SymLinksIfOwnerMatch/g’ $filepath
head -16 $filepath
echo ‘---------END--------’

To activate your new .profile file

source .profile

To change your .htaccess files


Kind regards,

aerozeppelin solution worked. Thanks :slight_smile:

According to Daniel Cid, +FollowSymlinks is a security concern. Attackers who would manage to compromise a confined website can get full root level access to that server.

Steps to reproduce that security concern at https://blog.sucuri.net/2013/05/from-a-site-compromise-to-full-root-access-symlinks-to-root-part-i.html

His proposed resolution is to change to +SymLinksIfOwnerMatch

Virtualmin fixed that security concern since the security announcement:
“All existing virtual servers using the FollowSymLinks option will be converted to SymLinksifOwnerMatch, to protect against malicious links into other domain’s directories.”

I see the Apache documentation for FollowSymLinks and SymLinksIfOwnerMatch says:

“This option should not be considered a security restriction, since symlink testing is subject to race conditions that make it circumventable.”


It still seems a wise precaution to reduce the attack surface though.

There doesn’t seem to be any way to selectively ignore .htaccess options and prevent upgrades causing a nasty 500 error, you have to ignore the entire file. As others have said, you can move all the options from .htaccess to httpd.conf. In theory you also get a performance benefit but it’s likely to be tiny. However it’s not generally possible to just cut and paste them, some mods are probably required.

An example of a modified set of directives for Drupal is here

Magento is a bigger job because there are lots of .htaccess files. There’s a converter script on github that may be useful but I haven’t tried it yet. https://github.com/preinheimer/htaccessConverter