Bug 503894 - Unable to connect to MySQL database from Digikam on openSUSE Tumbleweed after update
Summary: Unable to connect to MySQL database from Digikam on openSUSE Tumbleweed after...
Status: RESOLVED NOT A BUG
Alias: None
Product: digikam
Classification: Applications
Component: Database-Mysql (other bugs)
Version First Reported In: 8.6.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-05-07 19:26 UTC by Tomas
Modified: 2025-07-01 23:58 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 8.7.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas 2025-05-07 19:26:35 UTC
SUMMARY
DigiKam on openSUSE Tumbleweed fails to connect to MySQL database after the latest update, although the connection works fine from a Windows client. (If I do roll back to previous version, the connection is OK).

STEPS TO REPRODUCE
1. Configure DigiKam to use a MySQL/MariaDB database.
2. Attempt to connect to the database from Digikam on openSUSE Tumbleweed.
3. Observe that DigiKam fails to connect, while the same credentials work with the mysql command-line client on the same machine and from a Windows client.

OBSERVED RESULT

DigiKam fails to connect to the MySQL database with an "Database connection test was not successful. 
Error was: TLS/SSL error: Certificate verification failure: The certificate is NOT trusted. QMYSQL: Unable to connect" error despite successful connections from both the mysql command-line client (CLI) and a Windows client DigiKam.

EXPECTED RESULT
Digikam should be able to connect to the MySQL database without any issues.

SOFTWARE/OS VERSIONS

Client:
plasmashell 6.3.4
digikam 8.6.0 (Release  3.1)
kernel 6.14.4-1-default

Server:
mysql  Ver 15.1 Distrib 10.11.9-MariaDB, for Linux (x86_64) using  EditLine wrapper
openSuse Leap 15.4
kernel 6.4.0-150600.23.47-default

ADDITIONAL INFORMATION

MySQL/MariaDB service is running and accessible.
The user  has the correct privileges for access from any host (%).
Firewall has been disabled and does not affect the connection.
The issue started after a recent system update on openSUSE Tumbleweed
Comment 1 Maik Qualmann 2025-05-07 19:39:35 UTC
This isn't something digiKam can fix. If it occurred after a system update, this is where the problem should be located.
Do you use MySQL over the Internet? If locally, why is it encrypted?

Maik
Comment 2 Maik Qualmann 2025-05-07 19:44:33 UTC
Perhaps one more hint: to create an encrypted connection with digiKam, you must specify the appropriate connections options (certificates, keys, etc.).

Maik
Comment 3 Maik Qualmann 2025-05-07 19:47:05 UTC
A typical connection option to use an SSL server (from the Qt Doc):

"SSL_KEY=client-key.pem;SSL_CERT=client-cert.pem;SSL_CA=ca-cert.pem;CLIENT_IGNORE_SPACE=1"

Maik
Comment 4 Tomas 2025-05-07 19:51:05 UTC
(In reply to Maik Qualmann from comment #1)
> This isn't something digiKam can fix. If it occurred after a system update,
> this is where the problem should be located.
> Do you use MySQL over the Internet? If locally, why is it encrypted?
> 
> Maik

No, the MySQL is hosted on server in local network.
Comment 5 Tomas 2025-05-07 19:52:24 UTC
(In reply to Maik Qualmann from comment #3)
> A typical connection option to use an SSL server (from the Qt Doc):
> 
> "SSL_KEY=client-key.pem;SSL_CERT=client-cert.pem;SSL_CA=ca-cert.pem;
> CLIENT_IGNORE_SPACE=1"
> 
> Maik

 Thank you. I don't need to use ssl to connect to the server. It looks like ssl is required after the upgrade.
Comment 6 Maik Qualmann 2025-05-07 20:00:49 UTC
I'm using openSUSE Tumbleweed, and so far, SSL hasn't been automatically enabled for the MariaDB server. It must be a bug in the server configuration. Simply disable SSL again or submit a bug report to openSUSE if one doesn't already exist.

Maik
Comment 7 Maik Qualmann 2025-05-07 20:08:54 UTC
Good thing I haven't updated yet:

https://bugzilla.opensuse.org/show_bug.cgi?id=1227311

Maik
Comment 8 Maik Qualmann 2025-05-07 20:10:42 UTC
Oh, that was a bug from 2024...

Maik
Comment 9 Tomas 2025-05-08 15:08:58 UTC
I've fully disabled ssl on mariadb server, but I still can´t connect. It seems to me, that Digikam some how enforces the ssl (on client side)... is it possible?

MariaDB [digikam]> SHOW VARIABLES LIKE 'have_ssl';
+---------------+----------+
| Variable_name | Value    |
+---------------+----------+
| have_ssl      | DISABLED |
+---------------+----------+
1 row in set (0,002 sec)

MariaDB [digikam]> SHOW VARIABLES LIKE 'require_secure_transport';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| require_secure_transport | OFF   |
+--------------------------+-------+
1 row in set (0,001 sec)
Comment 10 Maik Qualmann 2025-05-08 16:29:12 UTC
No, digiKam doesn't initiate an SSL connection. I'll update my Thumbleweed and then we'll see.

Maik
Comment 11 Tomas 2025-05-09 19:00:18 UTC
I've opened a  bug report in opensuse bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1242910 but still did not succeed.
Comment 12 Maik Qualmann 2025-05-09 19:15:25 UTC
I'm also up to date with Tumbleweed and haven't noticed any changes. However, my MariaDB is on the same machine as digiKam. Because I'm testing AppImages, I'm using the local 127.0.0.1 address instead of localhost.

Is Tumbleweed a client for you, and the MariaDB server on a different machine?

Maik
Comment 13 Tomas 2025-05-09 19:16:36 UTC
MariaDB is on different machine (openSuse Leap).
Comment 14 Maik Qualmann 2025-05-09 20:12:52 UTC
According to the Qt docs, "MYSQL_OPT_SSL_MODE=SSL_MODE_DISABLED" is specified. The problem is that this connection option is only supported by MySQL, not MariaDB. When I look at the Qt source code, I don't see a valid option for MariaDB.

Maik
Comment 15 Tomas 2025-05-09 21:06:25 UTC
Yes, the MYSQL_OPT_SSL_MODE=SSL_MODE_DISABLED didn´t work. I've set up the ssl, so I can now connect to db. It might be useful to update the Digikam documentation and make it clear, that for remote mariadb is required to use ssl.
Comment 16 Tomas 2025-05-10 08:47:44 UTC
I guess this is a new mariadb feature and not a bug. Thank you for your time and help.
Comment 17 Karsten de Freese 2025-06-21 18:50:29 UTC
Tomas, I hope it's ok if I jump into this ticket -
I ran into the same problem after last Tumbleweed update. Would mind directing me to some information what needs to be done to set up ssl / TLS correctly? I understand that mariadb does this for a long time already by default (using self-generated certificates), so I guess I'd need to change my digikam database configuration?
Thanks -
Karsten
Comment 18 Chad B. 2025-06-22 19:07:55 UTC
I second the request for info on how to properly configure this setup.  I have DigiKam 8.6 running on Windows 11 connecting to a MariaDB instance running 10.3.39 on a remote AlmaLinux 8.10 system.  That system does have some LetsEncrypt certificates on it, but would prefer to configure the database connection to not rely on the certs.  I'd greatly appreciate the additional info needed to use this.  The initial database creation worked well, as did the initial photo directory location, however after that subsequent starts of DigiKam result in the same mysql.dll error as was earlier reported.
Comment 19 Karsten de Freese 2025-06-27 22:32:12 UTC
I've been able to resolve my problem in the meantime
- 1st of all, I was wrong in assuming that the mariadb version installed on my server already provides TLS connections with self-generated certificates - this is only with a very recent version of mariadb I cannot use for other reasons (not supported with nextcloud)
- So I configured mariadb TLS with the certificates I'm using for a web server on the same machine. This did the trick, and digikam connects to its databases again. No changes needed in digikam's database configuration.
Comment 20 Chad B. 2025-06-29 16:14:26 UTC
Could someone that's managed to get this working provide additional details about how they performed the mariadb configuration?  I've been beating my head against a wall trying and so far I've been entirely unsuccessful.  I'd really like to get this resolved so I can get this working across multiple systems accessing the same images.
Comment 21 Karsten de Freese 2025-06-29 19:06:29 UTC
hi Chad,
have a look at 
https://mariadb.com/docs/server/security/securing-mariadb/securing-mariadb-encryption/data-in-transit-encryption/secure-connections-overview

Assuming you already have TLS certificates (e.g. from letsencrypt) set up on the server that hosts the mariadb server, these are the steps that worked for me:

 - on the server, locate the / a mariadb configuration file (there may be more than one, which may all be evaluated)
   => in my case (under debian), I used '/etc/mysql/mariadb.cnf'
- look for the section '[mariadb]' (if there is none, create it by putting [mariadb] at the beginning of an empty line)
- In this section (so it existed) you should find a few commented-out lines, such as
  #ssl_cert = /etc/my.cnf.d/certificates/server-cert.pem
  #ssl_key = /etc/my.cnf.d/certificates/server-key.pem
  #ssl_ca = /etc/my.cnf.d/certificates/ca.pem
- Add the links to your existing TLS certificates - in my case these were
  ssl_cert = /etc/letsencrypt/live/<name of the server>/cert.pem
  ssl_key = /etc/letsencrypt/live/<name of the server>/privkey.pem
  => note that I have not added the link to the ca.pem - this should not be needed for letsencrypt certificates
- now restart mariadb to evaluate the modified configuration using your OS'es mechanism - in my case:
  sudo systemctl restart mariadb
- if you wish, you may check if TLS was actually enabled:
  - login to mariadb with your admin account: 
    sudo mariadb -u <admin name, e.g. root> -p
    => you will be prompted for your admin password
  - on the mariadb prompt, enter 
    SHOW GLOBAL VARIABLES LIKE 'have_ssl';  (the semicolon needs to be there)
- you should see something like 
+----------------------+-----------+
| Variable_name | Value    |
+----------------------+-----------+
| have_ssl            | YES       |
+----------------------+-----------+
- exit mariadb:
  exit;

That's it - digikam should now start, assuming that its databases had been created correctly.
Comment 22 Chad B. 2025-07-01 23:58:15 UTC
So this is still NOT working.  Same database server on 8.4 works just skippy.  8.5, 8.6, or 8.7 all fail.  I've configured SSL:
MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'have_ssl';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| have_ssl      | YES   |
+---------------+-------+
MariaDB [(none)]> status
--------------
mysql  Ver 15.1 Distrib 10.3.39-MariaDB, for Linux (x86_64) using readline 5.1
SSL:                    Cipher in use is TLS_AES_256_GCM_SHA384

I set up a single database `digikam`.  I dropped the old one entirely, and did all the grants per the setup.  
MariaDB [digikam]> show tables;
+--------------------+
| Tables_in_digikam  |
+--------------------+
| AlbumRoots         |
......
+--------------------+
32 rows in set (0.000 sec)

So clearly the initial tables are able to be created.
Alas, Event Viewer still shows:
Faulting application name: digikam.exe, version: 8.6.0.0, time stamp: 0x67d47119
Faulting module name: libmysql.dll, version: 8.0.40.0, time stamp: 0x679767b8
Exception code: 0x80000003
Fault offset: 0x000000000006e722
Faulting process id: 0x1f7c
Faulting application start time: 0x01dbeae03b70658f
Faulting application path: C:\Program Files\digiKam\digikam.exe
Faulting module path: C:\Program Files\digiKam\libmysql.dll

No idea why it keeps doing this, but it would seem that since it's starting with a blank database, and adding tables, the communication to the DB is at least somewhat functional.  Literally as I start digikam it'll show up in the task list for about 2-3 second before it silently quits.  I'm installing the "debug" version of 8.7 so if there's anything that can be done to help with troubleshooting this "not a bug" that'd be great.  It's been crazy hard to set up an external database, as there's not much troubleshooting info for an external database.  I need an external DB because I'm going to be using different systems to manage the same photos, so having the common external database is the only realistic option for me, but the days of head scratching have left me exhausted and frustrated.