The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.In issue #1269780, currently titled "Remove symlinks option from .htaccess" it was decided after lengthy discussion to remove the "Option +FollowSymLinks" from the .htaccess file, which was present in D6 and D7 versions. This has caused a regression for a different group of users in D8.
The original change was made to accommodate shared hosting providers, many of which now require SymLinksIfOwnerMatch instead of FollowSymLinks, to suit their security concerns.
This has caused a regression in at least one major Linux distribution, OpenSuse, which will not allow the D8 installer to run without one of the SymLinks options present in .htaccess - either FollowSymLinks or SymLinksIfOwnerMatch.
The error messages produced on screen in the original problem with FollowSymLinks and in this regression with neither option are very unhelpful and risk putting off newcomers to Drupal, and wasting considerable time of those who should know better. The messages logged in the system log are correct and helpful, but the onscreen messages do not lead there easily.
We now have three possibilities for the symlink option at initial installation:
- +FollowSymLinks - This will prevent numerous people on shared hosting from installing
- +SymLinksIfOwnerMatch - I don't think we have found anyone who cannot do the initial install with this option
Changes made to .htaccess are overwritten by version updates, which can be a problem in many different situations, so that updating, as opposed to installation, is a slightly different problem. In the previous issue it was established that only a very few people with complex setups will need +FollowSymLinks. They are likely to be expert users who can look after their own versions of .htaccess and backup / restore as needed when updating core. It is really disheartening to less skilled users to have severe errors when installing the bare application and we should prevent that happening. At present we only know of OpenSuse causing problems but it is too early in D8's release to know that others will not affected.
We should use +SymLinksIfOwnerMatch in the supplied version of .htaccess and alter documentation to suit.
Comments
Comment #2
AFowleComment #3
AFowleComment #4
AFowleComment #5
damien_vancouver commentedHey @AFowle,
First off, I think we have to untangle two different problems here.
This is problem 1: 500 errors for OpenSUSE on installation. This is I think what caused your problems and is due to SuSE changing the default Apache configuration of no Options FollowSymLinks on the Apache default root.
Apache is just doing what it's told to here, and the real problem is that the OpenSuSE configuration change is not well documented, it's not obvious to people that they must set one of the symlinks options (FollowSymLinks or SymLinksIfOwnerMatch) in order for mod_rewrite to work. I don't think we should be adjusting the Drupal configuration to one that potentially causes 500 errors for one group of people at the expense of another. As we saw from #1269780: Remove symlinks option from .htaccess there are people in both groups and that's how we got to the compromise of not setting either directive.
That compromise works for all distros except OpenSuSE. I filed a bug there about the missing instructions and the good news is that the bug is already accepted and the new configuration will be appearing ASAP in their rolling release and will be in the next real release. See status of that bug here: https://bugzilla.novell.com/show_bug.cgi?id=955701 and the commit has made it to the "review" state, here: https://build.opensuse.org/request/show/347288
So I think we can assume the documentation problem is fixed on the OpenSuSE side and hopefully will be into an end release soon to help people avoid this pitfall. At the end of the day though, this problem is specifically a misconfiguration where Apache is behaving as it's told to. Our previous directive did work around this, but at the expense of 500 errors for some people. We'd need to decide as a group that going back to potential 500 errors makes more sense than just putting up with and documenting the difficult SuSE installs.
As you know I use SymLinksIfOwnerMatch, so while this change would work for me, I don't think it's necessarily in the best interests of everybody, based on discussion in #1269780: Remove symlinks option from .htaccess.
Problem 2 that is somewhat mixed in with this is Options +MultiViews #2619250: Make .htaccess usage work for the widest possible configurations without relaxing security and document pitfalls. As a result of the change of not setting a symlinks directive, we tried to replicate the old state in private files directories by turning off the other Options:
became
However this ran us afoul of another Apache configuration gotcha: setting "AllowOverride All" does not allow overriding of MultiViews, you need to set "Allow Override=All,MultiViews" which is kind of a weird thing to set if you don't know about this problem. Hence, more 500 errors in some configurations. We are fixing this second problem by removing the Options -MultiViews on the Drupal side. Work on that issue is #2619250: Make .htaccess usage work for the widest possible configurations without relaxing security and document pitfalls.
For this issue, let's limit ourselves then to discussion of Options +SymLinksIfOwnerMatch vs. not setting a symlinks option at all.
Comment #6
geek-merlinAs it breaks installation i'd say this is at least major.
Some googlefood:
* The old FollowSymlinks option throws a 500 with "Option FollowSymLinks not allowed here"
* No option throws a 500 with "Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden"
+1 for this approach SymLinksIfOwnerMatch as it won't break in all known environments.
The only concern i can remember from the original issue is that the change can break installations in some very special constellations, if people symlink to a dir with different owner. There are valid use cases for that, but people who do that are able to read change notices and act accordingly.
Comment #7
giorgio79 commentedSeems this fell off the radar.
Comment #16
papagrandeIs this still a problem in Drupal 10? With no comment for four years, it would seem folks are working with the current settings.
If not, please add steps to reproduce including operating system and versions.
Bumping the priority down because of the lack of comment or progress.
Comment #17
quietone commented@AFowle, thanks for making this issue to improve Drupal core.
There has been no discussion here for 5 years, except to ask for more information 4 months ago. Since that has not been supplied it is time to close this.
Thanks everyone!