View Issue Details

IDProjectCategoryView StatusLast Update
0014151mantisbtinstallationpublic2012-04-29 14:40
ReporterKonstB Assigned Todregad  
Status closedResolutionunable to reproduce 
Product Version1.2.10 
Summary0014151: Failed install on PostgreSQL

I have a hosting with PostgreSQL support.
My hoster do not provide me with administrative password, but allow to create new databases via web interface.
So I have created empty database and point it on admin/install.php page.
But installation failed on "Attempting to connect to database as admin" with message "Does administrative user have access to the database? ( Database connection failed )"
How to understand the reason, why connection failed?
<b>Does installation works with already created, but empty database?</b>
Or how to create the database manually?

TagsNo tags attached.


related to 0009951 closeddregad Database creation under PostgreSQL fails to create a new database 




2012-04-14 20:01

developer   ~0031656

To install Mantis, you need an account which has sufficient privileges on your database (see

Alternatively, you might be able to generate the SQL from the install script and run that through your interface.

As this is not a technical issue with MantisBT, but you are asking how to set it up, I am resolving this issue now. Please use the Forums for further support.



2012-04-15 13:02

reporter   ~0031658

Hmm, I think this is a technical issue, and you have to check installation on PostgreSQL, because I have found the reason.
The problem is in \admin\install.php, line 304.
$t_result = @$g_db->Connect( $f_hostname, $f_admin_username, $f_admin_password );
This does not work for PostgreSQL without database name. The command:
$t_result = @$g_db->Connect( $f_hostname, $f_admin_username, $f_admin_password, $f_database_name );
works fine.
This trick helps me to pass this check and successfully install Mantis.
The only warning I have got is
"POSSIBLE PROBLEM: change php.ini to disable register_globals setting"
Is this critical?



2012-04-16 05:01

developer   ~0031659

The 'register_globals' message is just a warning, so it's up to you to ignore it (or not). It is recommended to have it OFF for security reasons [1].

With regards to the main problem, can you please confirm which version of MantisBT you're working with, as the '$g_db->Connect' statement is actually at line 303 in 1.2.10.

Anyway I believe that your proposed fix could potentially break the installation process for other RDBMS. To make sure I have a good understanding of your usage scenario, can you please clearly explain your DB setup (i.e. what input parameters you provide to install.php)

Can you also have a look at 0009951 and tell me whether that is the same issue you are facing, and if information provided there is of any help.




2012-04-16 05:08

developer   ~0031660

Last edited: 2012-04-16 07:47

View 4 revisions

Maybe a better fix (not tested)

diff --git a/admin/install.php b/admin/install.php
index 548cd79..a2a438c 100644
--- a/admin/install.php
+++ b/admin/install.php
@@ -292,6 +292,10 @@ if( 2 == $t_install_state ) {
$g_db = ADONewConnection( $f_db_type );
$t_result = @$g_db->Connect( $f_hostname, $f_admin_username, $f_admin_password );

  • if( !$t_result ) {
  • $t_result = @$g_db->Connect( $f_hostname, $f_admin_username, $f_admin_password, $f_database_name );
  • }
  • if( $t_result ) {
            # check if db exists for the admin




2012-04-16 06:01

reporter   ~0031661

Last edited: 2012-04-16 06:02

View 2 revisions

I use 1.2.10. May be I have shifted the line during my experiments with code.

My setup scenario:
First I have created manually the database "ppp_mantis" and user for it with full rights (this was done by script of my provider, so I do not know the exact details).

The paramenters for install.php:
Type of Database : PGSQL
Hostname (for Database Server) : (localhost did not worked for some reason, I do not know why)
Username (for Database) : mantisuser
Password (for Database) : mantisuserpw
Database name (for Database) : ppp_mantis
Admin Username (to create Database if required) : mantisuser
Admin Password (to create Database if required) : mantisuserpw

Yes, I know, that my fix works only if DB already exists. But I have done some experiments and found that ADO command:
$t_result = @$g_db->Connect( $f_hostname, $f_admin_username, $f_admin_password );
fail withot DB name in my case.
May be the problem is connected with some options of PostgreSQL, otherwise I do not know how to create a new DB via ADO.

0009951 describes a little other problem with DB OWNER setting



2012-04-16 06:17

developer   ~0031662

Thanks for feedback.

I assume then that "mantisuser" has fullrights on ppp_mantis schema. Will try to make some tests later on as time allows.

In the meanwhile, can you confirm if my suggested alternate fix works for you ?



2012-04-16 06:59

reporter   ~0031663

Where to find your alternate fix? In you comment it is not complete.



2012-04-16 07:48

developer   ~0031664

Copy/paste error. Apologies.



2012-04-17 07:09

developer   ~0031674


I made the following test on my local dev box.

  1. Initial setup, using pgadmin (trying to emulate what your provider's script does):
    • created new login role 'test14151' with password 'test', with no special privileges
    • created new, empty db 'db14151' with login role 'test14151' as owner
  2. Mantis install
    • ran install.php with
    • hostname: localhost
    • username: test14151, password: test
    • database: db14151
    • admin user: test14151, password: test

The install script ran fine, and the schema was created successfully. I am therefore not able to reproduce your problem with the information provided

Without additional details as to how your host has setup your DB and user account in terms of privileges, I'm afraid I will not be able to help you more. Can you provide the SQL scripts used to create your setup, or a configuration report ?



2012-04-19 02:29

reporter   ~0031689

It looks like this is a configuration option.
I ask my provider for details.



2012-04-19 05:26

reporter   ~0031692

My provider said, that this behaviour is managed by user configuration options in Postgress. I failed to get more information ((



2012-04-19 05:34

developer   ~0031693

In that case, I am afraid that there is no chance for me to troubleshoot this problem.

Since you were able to create your database in the end, then I am again resolving this issue. Feel free to reopen it (again) if you are able to get more info on the detailed PostgreSQL setup they are using.



2012-04-19 07:36

reporter   ~0031695

The only thing that they have said, was: each user have access to only one database (db name coincides with user login).
And forwarded me to Postgress docs!!!
Is this enough information?



2012-04-19 08:28

developer   ~0031696

Not really no, I'm sorry.

Issue History

Date Modified Username Field Change
2012-04-12 13:27 KonstB New Issue
2012-04-14 20:01 dregad Note Added: 0031656
2012-04-14 20:01 dregad Status new => resolved
2012-04-14 20:01 dregad Resolution open => no change required
2012-04-14 20:01 dregad Assigned To => dregad
2012-04-15 13:02 KonstB Note Added: 0031658
2012-04-15 13:02 KonstB Status resolved => feedback
2012-04-15 13:02 KonstB Resolution no change required => reopened
2012-04-16 05:01 dregad Note Added: 0031659
2012-04-16 05:02 dregad Relationship added related to 0009951
2012-04-16 05:08 dregad Note Added: 0031660
2012-04-16 05:08 dregad Note Edited: 0031660 View Revisions
2012-04-16 05:09 dregad Note Edited: 0031660 View Revisions
2012-04-16 06:01 KonstB Note Added: 0031661
2012-04-16 06:01 KonstB Status feedback => assigned
2012-04-16 06:02 KonstB Note Edited: 0031661 View Revisions
2012-04-16 06:17 dregad Note Added: 0031662
2012-04-16 06:17 dregad Product Version => 1.2.10
2012-04-16 06:59 KonstB Note Added: 0031663
2012-04-16 07:47 dregad Note Edited: 0031660 View Revisions
2012-04-16 07:48 dregad Note Added: 0031664
2012-04-17 07:09 dregad Note Added: 0031674
2012-04-19 02:29 KonstB Note Added: 0031689
2012-04-19 05:26 KonstB Note Added: 0031692
2012-04-19 05:34 dregad Note Added: 0031693
2012-04-19 05:34 dregad Status assigned => resolved
2012-04-19 05:34 dregad Resolution reopened => unable to reproduce
2012-04-19 07:36 KonstB Note Added: 0031695
2012-04-19 08:28 dregad Note Added: 0031696
2012-04-29 14:40 atrol Status resolved => closed