On windows systems, entering correct credentials at the database configuration step of install.php will fail silently, redirecting back to the database configuration form. This problem has been noted here:
http://drupal.org/node/119525
and here:
http://drupal.org/node/122083
The problem is due to incorrect settings.php permissions. However, the necessary error messages never reach the user. Below are the comments I posted about this in the above nodes:
There are two problems. drupal_verify_install_file is supposed to make settings.php writable, but fails silently, since it uses a chmod command that windows doesn't get.
Second, drupal_rewrite_settings fails and sets a message with drupal_set_message(). However, install_settings_form_submit assumes that drupal_rewrite_settings succeeds and the first thing it does on return is to call a redirect. The result is that the error message is lost. :-( If either the error message were logged to the apache logs or drupal_rewrite_settings returned a success/fail code and it were handled properly, then the problem would have been obvious... No mercy for those of us trapped in MS-land.
Comments
Comment #1
csc4 commentedIsn't this a critical issue - Drupal 5 is uninstallable on Windows as things stand as the installation fails and there are no error messages - only people finding this post find any help at all!!
Could someone prioritise looking at this - at least make the errors visible even if the chmod can't be replaced with a Windows capable version?
Comment #2
chx commentedThere are several problems here. Many people are capable of running Drupal nicely on Windows. Second, as this bug is more of a nuisance than a showstopper, it's not critical. (And it's a Windows bug so a critical looks strange ;) )
Comment #3
simra commentedLet's compromise at normal. The bug is critical if you're a windows user and not a sophisticated user. If you're patient enough, you can google the fix or code-dive to find the problem. It's clearly not a minor bug because installation should work 'out-of-the-box'.
My $0.02.
Comment #4
csc4 commentedAnd if it doesn't work out of the box it should be documented why in the read me to save people attempting to Google.
But I guess if Windows users are second class Drupal users then it doesn't matter does it.
Comment #5
yched commentedLets' not over-dramatize : I, for one, never had any issue installing Drupal in Windows - and I guess if drupal was incompatible with windows, we'd know by know.
Comment #6
keith.smith commentedAs noted in #5, I regularly install 5.1 sites on Windows -- and to double check, did so again as recently as a few moments ago -- and did not encounter the problems that you note.
That said, there is a huge caveat in my testing: I use the LAMPP (or WAMP, really) stack, so this may indeed be an issue with IIS that does not exist with Apache. One of the threads you mention references that this is an error specific to IIS 6.0, and only occurs if PHP is installed in to work with IIS in a CGI context, rather than ISAPI. If this is the case, then that may be why there are not more issues being filed, since I would guess that many people install Drupal on Windows using Apache rather than IIS, and that further, those that use IIS for a 5.1 installation have used ISAPI rather that CGI when installing PHP.
I don't believe that I have ever grafted PHP on to IIS using CGI rather than ISAPI, and certainly have never done that and then installed Drupal. But, I'll put together a test environment and try some different Drupal installations with various IIS/PHP configurations.
In the meantime, though, can you confirm that you are using IIS, and if so, what version? What version of PHP and how was it installed? Are there any other details relevant to your installation that you believe could be helpful? I'm assuming that you can manually modify the IUSR permissions to settings.php as noted in the threads you reference and successfully get your site to work?
Comment #7
simra commentedThis is on Apache, and the most recent PHP.
Windows permissions are a bit of a black art to me, but my sense is that this is a problem when drupal is installed on a windows box that's on a domain (as opposed to a stand-alone system), where user permissions come into play.
In other words, if your machine is domain-connected then you'll run into problems, since files are by default created with permissions along the lines of 744 or maybe even 700. If it's not on a domain, which is probably the majority of windows users, you won't notice the problem.
Comment #8
keith.smith commentedOK. I can likely test this scenario as well.
So, as I understand it, your web server is running on a system that's also a domain controller for a domain, and you are using Active Directory to manage users and user permissions? When you are installing Drupal, are you doing so as the Administrator, or as some other domain based user? If you are using a different user other than Administrator, what permissions does this user have to the web directories that you are serving out through Apache (ie: does this user have the Full Control options checked in Properties->Security tab for your drupal installation directory, or Modify, Read & Execute, etc.)? If you are using a different user other than Administrator, can you try the installation while logged in as an administrative user to see if it still exists? Further, on your Properties->Security tab for your settings.php file, can you click the Advanced tap and see if you have a check-mark next to "Include inheritable permissions from the object's parent" on this file? If so, the file is inheriting the permissions applied to a directory above it on the tree; if not, then permissions set on this file have been overridden, likely manually.
Finally, is your drupal 5.1 site operational now? If so, exactly what workaround did you use to solve this issue? I mean, did you have to manually modify the permissions of setting.php, run the installation and then reset them? If so, what were the permissions when you first went to check the file, and what types of additional access did you have to grant?
I'll install a drupal 5.1 installation on a domain using active directory tomorrow am and see what happens, but will need to do if I should try as a domain user, or if this is something that appears to also be happening to you when you are logged in as the domain administrator.
Thanks for your help tracking this down.
Comment #9
keith.smith commentedsimra: I tested a new installation of Drupal 5.1 this morning, by downloading/decompressing the tarball, creating a database, and running the installer. I did this logged in as the Administrator on a Windows 2003 server, running Apache 2.2.4, MySQL 5.0.37 and PHP 5.2.1; the machine I was using is also a domain controller and access/user management is controlled through Active Directory.
My install worked properly, and I had to make no manual adjustments to settings.php or other files, or file permissions. At the end of the installation, settings.php had been modified correctly, and its' read-only flat had been set. AFAIK, everything worked properly.
I did not try installing Drupal as a non-administrative user, as I'm not altogether sure that the installer should, or can be expected to, work correctly in this situation.
Comment #10
csc4 commentedAs someone who had no problems installing 4.7 on IIS and spent TWO DAYS trying to understand why this was failing - I'd have appreciated a mention of the known problem in the README - as would the person asking today (http://drupal.org/node/152755) and all the others who have asked or just simply given up trying.
This problem was introduced with V5, is a clearly known problem (and chmod on a windows file was never likely to work was it? - plus the fact that if you have an install error YOU SHOULD SHOW IT not suppress it!) - and it's apparently not even worth documenting let alone fixing - and you feel complaining about that POV is over dramatising?
To reiterate - Drupal 5 on IIS is NOT installable following the documented process. IMNSHO that's a critical bug and deserves treating as one.
Comment #11
keith.smith commentedcsc4: OK, I certainly understand that it can be sometimes be annoying to install packages that don't work, or seem to not work, out of the box. Believe me, I suspect everyone here feels your pain.
That said, it seems as if there are multiple things going on in this issue.
In your post, you very clearly state that this is a problem you are experiencing with IIS. Simra references two additional nodes that also talk about this IIS related issue with settings.php permissions issues. But, in response to my question in #6, simra notes that he is on Apache. At this point, I'm uncertain what platform you are using.
I tested an Apache based installation on Windows this morning and everything seems to work OK -- I have not tested an IIS setup yet, but will do so if that's what you are using.
Actually, the most recent thread you just posted (http://drupal.org/node/152755) has about the most clear statement of the problem that I've read so far. That forum post is very clear that this is a permissions issue in IIS. Using some of that information, I'll try my best to try this out on a clean install in an IIS testbed and see what happens.
Comment #12
simra commentedHi Keith, thanks for trying to repro with apache.
The box is not a domain controller, but user credentials, file permissions, etc are managed by a remote controller (contrast this with a basic windows install that knows nothing of domains/permissions).
In my case, I was installing as a user who is a member of the administrators group. This might be an important point- in my limited experience I've seen permissions issues for administrative users that can't be resolved without actually logging in as the local administrator.
Off the top of my head I don't recall what user apache is running as, but it's most likely that it was running under the same administrative user account.
Sorry I can't be of much more help with the repro. If I can find the time to reproduce it I'll let you know, but at the moment it's unlikely I'll get to it in the near future.
I second the vote that something be done to address the chmod and lack of feedback to the user. There are situations in linux where this would be a problem too.
Comment #13
nagalingam commentedHi - I have the same/similar problem as well. Here are the background data:
Installing on my Windows XP machine which is connected and controlled by the corporate domain controller (prototyping use of drupal). I am an administrator of my local machine but certainly not the administrator of the domain. Using this same login, I have been able to successfully install and startup apache and mysql. PHP installation has also been validated (phpinfo via apache).
I extracted Drupal and copied it to the Apache htdocs as its own folder. Aka, in order to access install.php, I would have to type http://localhost/drupal51/install.php
It displays the following: "Your web server does not appear to support any common database types. Check with your hosting provider to see if they offer any databases that Drupal supports."
I have checked that mysql is running and the drupal database is already created!.
Comment #14
steph4e commentedHello - I also have the same issue as #13. However, I am installing on a Linux fedora core 6 server. I am running Apache 2.2.4, and MySQL version 5.0.27. I unzipped the latest Drupal release 5.1 per the instructionset, under my doc root /var/www/html. I changed the permissions of the settings.php to 777.
When I enter http:\\mywebserver/drupal-5.1/install.php, I get the following message:
Database configuration
"Your web server does not appear to support any common database types. Check with your hosting provider to see if they offer any databases that Drupal supports."
I have checked that mysql is running and the drupal database is already created!.
BTW - all the install instrauctions say that with the new release, an install script is included, but no mention is made of how to run the install script - and since I could only find an install.php file, I assumed that I type the location in the browser. Is this correct? Or is there another install script that I am missing?
Thanks in advance! Steve
Comment #15
stevenpatzis this what you really typed:
Comment #16
rolodmonkey commentedThere haven't been any comments on this in three years. I am going to assume that it is 'fixed'.