Troubleshooting JDBC driver issue on migrating confluence to a HostJane server running Ubuntu 22.04

[Ben Christensen]

This concerns Confluence Data Center version. I'm aware Confluence 8.x requires mysql-connector-java-8.0.xx-bin.jar for MySQL 8.0+, but it seems a wrong or missing JDBC driver on a new HostJane EC2 Ubuntu 22.04 LTS environment is preventing Confluence from connecting to the database, causing the migration to fail.

After migration to HostJane, Confluence fails to start with the error:

No suitable driver found for jdbc:mysql://localhost:3306/confluence

Everything else should be the same, it was working fine on my old (smaller) Ubuntu 22.04 server. I contacted the hosting support and they said this confluence issue occurs if the MySQL JDBC driver is outdated or not copied to the install directory: /confluence/WEB-INF/lib.

Their solution was to tell me to download the latest MySQL Connector/J (e.g., 8.0.33) and place it in the lib directory, basically update confluence.cfg.xml in <confluence-home>/confluence.cfg.xml.

<property name="hibernate.connection.url">jdbc:mysql://localhost:3306/confluence?useUnicode=true&amp;characterEncoding=utf8mb4</property>

No changes after doing that, I need to migrate the data center version, don't want to use confluence cloud. Any suggestions on how to fix the JDBC driver issue?

[Philipp Sendek · Accepted solution]

Hi @Ben Christensen and welcome to the Community!

If this is the only problem, I recommend following the instructions on this page to properly setup mysql and Confluence: https://confluence.atlassian.com/doc/database-setup-for-mysql-128747.html

Additionally, here's how I would migrate Confluence from one system to another which would avoid any differences that you need to tackle individually:

If you want to save the hassle of creating a user account and other surrounding factors, I would propose the following:

1. Install Confluence on the new server with the same version you've been using on your old server.
2. Backup your data and install directory as well as the database (as dump using mysql_dump) from the old server and copy it to the new server.
3. Extract (and override) the installation you've done on the new system with your backups and import the database.
4. Set the correct user in the setup_user.sh (might be named slightly differently) script in the $INSTALL/bin directory
5. Run the script with the correct paths as parameters (it will then go ahead and set the correct directory and file permissions with the OS user which might differ between your old and your new system)

If your database is still locally installed, you won't have to change anything in the $DATA/confluence.cfg.xml.

Once you've started your Confluence (and I haven't forgotten anything from the top of my head), your Confluence should be running again.

I hope that helps and you can start enjoying Confluence on your new system. :-)

[Ben Christensen]

You're right @Philipp Sendek I'm basically going to have to start again. The cause was the required JDBC driver .jar file was inaccessible in the Confluence installation directory due to mismatching file permissions between my old Ubuntu server and the new one.

<confluence-install>/confluence/WEB-INF/lib

(I found out the new hostjane PHP server is actually running a Bitnami packaged Debian image, not Ubuntu: https://aws.amazon.com/marketplace/pp/prodview-6g3gzfcih6dvu

- https://cloud.hostjane.com/cloud/ (where I got my new one: https://www.hostjane.com)

Very frustrating because I did actually everything right to configure MySQL correctly in the steps you sent (which took me 4 hours) but when I dropped the old .jar (https://confluence.atlassian.com/doc/database-jdbc-drivers-171742.html) into that <installation-directory>/confluence/WEB-INF/lib directory, it failed and Confluence won't start on the new hostjane one. 

 I basically am going to have to stay with my old host and upgrade server, with matching requirements. Sorry for wasting your time. My bad :(

[Philipp Sendek]

No problem, I'm glad you've figured it out.
When working with permissions or knowing that permissions are an issue, keep the setup_user.sh script in mind as it always sets the directory and file permissions correctly. I've seen instances where admins basically granted write permissions to any of the directories in $INSTALL which poses a security risk as it can lead to binaries and .sh files to be altered from within the application (e.g. by a script runner script, a malicious app, etc.)