Initial database install tests successful but fails to set up

[IT Management]

Hi all - 

I'm in process of the initial install of Confluence (hosting it on a VM alongside a Jira installation on the same server, both using MS SQL which is located on this machine as well).  

I reach the point where I am at "Set up your database", and fill in the details using Setup type of "By connection string".  User in this instance has every right known to man for its SQL Database, and the login can successfully log in through MS SQL Mgt Studio.  

Back in "set up your database" screen, when 'Test connection" is pressed, we get a successful result.  

However, when "Next" is pressed, "The following error(s) occurred": 

"Configuring database failed
com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user 'ConfMaster'. ClientConnectionId:55217c47-7d43-4ef6-953e-11bdec629479"

Which makes absolutely no sense, since it just successfully logged in and connected in the prior screen.  

To compound the frustration, the %Atlassian%\Confluence\logs directory sees no entry for the problem.  Not one of the files present has an addition to it as a result of the error.  

In the Event Viewer, MS SQL provides an error worth noting:  "Login failed for user 'ConfMaster'. Reason: Password did not match that for the login provided. [CLIENT: 127.0.0.1]"

So...Confluence setup appears to be accepting my credentials in the "Set up your database" screen, tests them successfully, and then proceeds to mangle my password when trying to log into the system when it wants to create all the tables, procs, etc. needed for Confluence to function.  

Anyone seen anything like this?  

Many thanks - 

  T

[IT Management]

I seem to have solved it - though it was rather from a sledgehammer perspective than one with finesse.  I re-created the database, with the default user set up as dbo of the new database.  This enabled all permissions, and that seems to have secured things here.

Thanks for all the help, everyone - 

  T

[AnnWorley]

Thanks for letting us know how you resolved it at last. That's great news for a Friday. Have a great weekend.

~Ann

[IT Management]

Thanks for the replies, guys.  I'll try mixed-mode today, and Nic, in answer to your question, the password does contain a single "!" (no particularly special stuff like umlauts or anything).  It's my domain policy to require at least one, but I generally stay pretty tame in my choices of specials :).  

  T

[IT Management]

Just checked, and I'd already installed MS SQL under mixed-mode auth...any other ideas?

[AnnWorley]

I know you checked the logs, but I wanted to make sure you checked the atlassian-confluence.log in <confluence_home_dir>/logs. Maybe there's a more detailed message.

Editorial: It seems bizarre that the password could be ok for the test but not to set up the schema. I am looking forward to finding out what's going on.

[IT Management]

Sorry for the delay...just got back to this after putting out some fires.  This morning I tried again while observing the logs directory, and this one popped when I tried and got the failure again:

Full log can be downloaded here

pertinent excerpts:

"16-Jan-2018 08:55:05.114 WARNING [ContainerBackgroundProcessor[StandardEngine[Standalone]]] org.apache.catalina.valves.StuckThreadDetectionValve.notifyStuckThreadDetected Thread "http-nio-8090-exec-3" (id=38) has been active for 60,514 milliseconds (since 1/16/18 8:54 AM) to serve the same request for http://localhost:8090/setup/setupdbtype.action and may be stuck (configured threshold for this StuckThreadDetectionValve is 60 seconds). There is/are 1 thread(s) in total that are monitored by this Valve and may be stuck."

"

16-Jan-2018 08:55:53.352 SEVERE [http-nio-8090-exec-3] org.apache.catalina.core.StandardHostValve.custom Exception Processing ErrorPage[errorCode=500, location=/500page.jsp]
org.apache.jasper.JasperException: An exception occurred processing JSP page /500page.jsp at line 119

116:
117: if (sysInfoService != null)
118: {
119: confluenceInfo = sysInfoService.getConfluenceInfo();
120: memoryInfo = sysInfoService.getMemoryInfo();
121: dbInfo = sysInfoService.getSafeDatabaseInfo();
122: sysinfo = GeneralUtil.convertBeanToMap(sysInfoService.getSystemProperties());

"

"16-Jan-2018 08:55:55.175 WARNING [ContainerBackgroundProcessor[StandardEngine[Standalone]]] org.apache.catalina.valves.StuckThreadDetectionValve.notifyStuckThreadCompleted Thread "http-nio-8090-exec-3" (id=38) was previously reported to be stuck but has completed. It was active for approximately 107,320 milliseconds."

[AnnWorley]

I am seeing this in the log: 

Caused by: com.atlassian.confluence.tenant.VacantException: Confluence is vacant, a call to tenanted [public abstract org.hibernate.Session org.hibernate.SessionFactory.getCurrentSession() throws org.hibernate.HibernateException] is not allowed.

Is it possible that the server cannot resolve it's own host name as described in: Confluence generates Confluence is vacant error on install?

 Please post a link to your <Confluence_Home_dir>logs/atlassian-confluence.log as well, in case there is more information there.

[IT Management]

The copy of atlassian-confluence.log present is from six days prior, so probably unrelated to yesterday's bomb, but it's here:

https://drive.google.com/open?id=1Yg7Uun4qysLSQRGCxLaJyzy6m8VUXrgS

The machine definitely can reach itself, both on the home loopback address and through name resolution on the network - there's a working copy of Jira on it already...

Edit:  it also pings successfully against its machine name, against "localhost", and direct IP of 127.0.0.1

[AnnWorley]

Now it looks like the database login is successful but the permissions are insufficient:

2018-01-16 08:55:51,797 ERROR [http-nio-8090-exec-3] [engine.jdbc.spi.SqlExceptionHelper] logExceptions The SELECT permission was denied on the object 'BANDANA', database 'Confluence', schema 'dbo'.
 -- url: /setup/setupdbtype.action | traceId: 00da98ac8f0b9226 | userName: anonymous | referer: http://localhost:8090/setup/setupdbtype-start.action | action: setupdbtype

There was previously a collation issue, hopefully this was resolved back on the 10th but I wanted to double check with you.

2018-01-10 10:09:54,643 ERROR [http-nio-8090-exec-8] [atlassian.confluence.setup.DefaultDatabaseVerifier] verifyCollationOfDatabase The collation of database is not set correctly!
 -- referer: http://localhost:8090/setup/setupstandarddb-start.action?database=mssql | url: /setup/setupstandarddb-testconnection.action | traceId: 000c4653d58a63e0 | userName: anonymous | action: setupstandarddb-testconnection

Please make sure your DBAs set up the database and user as described in: Database Setup for SQL Server

Ideally a new database should be spun up for the new install as the schema seems to have been at least partially created:

2018-01-10 10:21:46,622 ERROR [http-nio-8090-exec-1] [confluence.setup.actions.SetupStandardDatabaseAction] setupDatabase Unable to bootstrap standard database
 -- url: /setup/setupstandarddb.action | traceId: 00720bb9f55a0f8e | userName: anonymous | referer: http://localhost:8090/setup/setupstandarddb-start.action?database=mssql | action: setupstandarddb
com.atlassian.config.bootstrap.BootstrapException: Schema creation complete, but database tables don't seem to exist. 

Please let me know how it goes.

[IT Management]

Hi again - yes, both collation and permissions were cleared up prior to the current one :).  Still beating my head against a stone with this login failure, though...

[AnnWorley]

Well, you are being a good sport considering how frustrating this is.

I wonder if that error screen "Login failed for user 'ConfMaster'" is cached in the browser? Please try another browser or clear the cache and try the setup, if you haven't already. Is there a corresponding login error in the atlassian-confluence.log each time? You mentioned earlier that there isn't such an error - if the database rejects the credentials that should be logged, so perhaps it's a browser issue.

My fingers are crossed.

[Sven Liang Jensen]

I am also stuck with a connection to SQL database error, and got this tip from ASH (Atlassian): 

"JIRA 7.7 requires Microsoft JDBC 6.2.1 Driver for SQL Server.   Are you using the same driver?"

I saw your initial error message had a reference to JDBC.

"Configuring database failed
com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user 'ConfMaster'. ClientConnectionId:55217c47-7d43-4ef6-953e-11bdec629479"

A shot in the dark, but since you have struggled so long it might be worth the try?

Hope you will find a solution soon.

Best regards,

Sven

[IT Management]

Hi to both, and thanks for helping - answers in order:

1 - seems like it probably was cached, because as soon as I pulled a CTRL+F5, the browser gives me a major 500 dump.  Says the root cause is in the stack trace for Apache Tomcat...would this be useful?

2 - Pretty sure it's a viable version, as Jira / Jira Core are running fine on the same server already.  Where would I check this out?

Thanks - 

  T

[Nic Brough -Adaptavist-]

This is a very long shot, but something I ran into ages ago - does your user name and/or password contain special characters?

I've seen an MS database let me create an Atlassian user with something like user: Charlie!  password: ezL5%£023Ç3@ and then fail to log in because of the Ç character.

[AnnWorley]

It does seem quite odd that the test connection step would work but SQL server reports a bad password when the schema is being set up. I understand how that is frustrating.

Searching the error you got from Event Viewer, I found several suggestions that SQL server needs to be in mixed mode for authentication under some circumstances. Our documentation recommends:

 ...change the Authentication Mode of the SQL server from 'Windows Authentication Mode (Windows Authentication)' to 'Mixed Mode (Windows Authentication and SQL Server Authentication)'.

There are two sets of logs in Confluence. The logs in <confluence_install_dir/logs are for the underlying Tomcat web server. For setup and other application errors, the log to examine is the atlassian-confluence.log in <confluence_home_dir>/logs.

I am not sure how Confluence could mangle your password en route to the database that is on the same server. Since Confluence 6.6.1 just came out earlier this week I tested the setup wizard with a local database to rule out new bugs, but did not run into the issue you are experiencing. I am hoping the bad password error is misleading and the mixed mode authentication will fix it.