I have installed the latest MySQL Workbench from the Tumbleweed repository using Yast. It starts OK, but then I’m prompted to enter a password using the gnome keyring. This doesn’t accept either the root, database or user passwords, so prevents connection to MySQL.
The MySQL Workbench installation instructions on the MySQL website indicates that users with KDE and not Gnome need to manually start the gnome-keystring daemon. I haven’t, however, been able to find any such daemon on the system. It doesn’t appear in services, even though it shows as being installed on the system in Yast and what I did find in /usr/bin didn’t start anything. (I did de-install gnome-keystring and re-install it, but it made no difference.)
Any suggestions on what needs to be done to get this working will be most appreciated. Thanks.
How about that…
For the longest time MySQL workbench was deprecated (given up, not maintained) but it looks like it’s enjoying a resuscitation by Oracle.
The “new” MySQL Workbench looks to have some really cool new features it didn’t have before including enhanced data migration tools https://www.mysql.com/products/workbench/
Been a long while since I used it a very long time ago, but IIRC you should enter the MySQL Administrator’s password for that database.
For that to work, of course you need to** configure a password** and** enable remote root login**, which isn’t done by default. The remote login is required because MySQL Workbench is an “external application” even if it’s running on the same machine.
To configure your MySQL/Mariadb, you should run the security configuration script or if you either want a way to save your security configuration or support a large number of databases, you may want to create a here doc, which is described both specifically and generally in an article I wrote
Apologies for the time it’s taken to respond. I hadn’t realised that anyone had done so - I hadn’t selected the email notification option. Thank you also for the information and links regarding the Here documents.
I have run the mysql_secure_connection script on the command line and have selected ‘n’ for the disallow remote login option. I have created a new user called ‘workbench’ with all privileges and have specified any (%) host, but still get the ‘unsupported option provided to mysql_options()’ message. This is also true if I use ‘root’.
You mention configure a password and** enable remote root login **in your post. Is this an additional password to the ones I’m using? Is there a way to check what I’m actually sending to the database? The mysqld log doesn’t show anything nor does one that I created for general_log.
I am attempting to connect via Standard TCP/IP to localhost:3306. I usually use a socket connection, but that doesn’t work either.
Further to my previous post, I have been able to connect remotely to the MySQL database from another computer using the new credentials from the command line, so the remote login aspect is working, but still no success with workbench.
Here’s some additional information from the Workbench logfile that may be useful. Though, I suppose one would need to be intimately familiar with the do_connect method to understand why there is an exception.
"16:21:27 [INF] WBContext UI]: Initializing workbench context UI with these values:
base dir: /usr/share/mysql-workbench
plugin path: /usr/lib64/mysql-workbench/plugins
struct path: /usr/share/mysql-workbench/grt
module path: /usr/lib64/mysql-workbench/modules
library path: /usr/share/mysql-workbench/libraries
user data dir: /home/mwhite/.mysql/workbench
open at start:
open type:
run at startup:
run type:
Force SW rendering: No
Force OpenGL: No
quit when done: No
16:21:27 [INF] WBContext]: WbContext::init
16:21:28 [WRN] grt]: Could not load wb.model.grt.so: Could not open module /usr/lib64/mysql-workbench/modules/wb.model.grt.so (/usr/lib64/mysql-workbench/modules/wb.model.grt.so: undefined symbol: _ZN9Scintilla8WordListD1Ev)
16:21:30 [INF] WBA]: Looking for extension modules for WBA…
16:21:30 [INF] WBA]: 0 extension modules found
16:21:30 [WRN] grt]: Could not load db.mysql.diff.reporting.wbp.so: Could not open module /usr/lib64/mysql-workbench/plugins/db.mysql.diff.reporting.wbp.so (/usr/lib64/mysql-workbench/plugins/db.mysql.diff.reporting.wbp.so: undefined symbol: _Z17build_catalog_mapN3grt3RefI16db_mysql_CatalogEERSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS0_I14GrtNamedObjectEESt4lessIS9_ESaISt4pairIKS9_SB_EEE)
16:21:30 [WRN] grt]: /home/mwhite/.mysql/workbench/connections.xml:25: link ‘b424bd52-e26e-11e7-a0cb-902b3441ed70’ <object GrtObject> key=owner could not be resolved
16:21:30 [INF] WBContext]: System info:
MySQL Workbench Community (GPL) for Linux/Unix version 6.3.10 CE build 12092614 (64 bit)
Configuration Directory: /home/mwhite/.mysql/workbench
Data Directory: /usr/share/mysql-workbench
Cairo Version: 1.15.8
OS: x86_64
CPU: 2x Intel(R) Celeron(R) CPU G540 @ 2.50GHz (2494.159MHz) - 3.75GiB RAM
No video adapter info available
Distribution: openSUSE Tumbleweed
Fips mode enabled: no
16:21:31 [WRN] WBModule]: OS not found on supported OS list. OS string: ’ x86_64’
16:28:35 [ERR][SQL Editor Form]: SqlEditorForm: exception in do_connect method: Exception: Unsupported option provided to mysql_options()
16:28:35 [ERR] GRTDispatcher]: exception in grt execute_task, continuing: Exception: Unsupported option provided to mysql_options()
16:28:35 [ERR] GRTDispatcher]: worker: task ‘execute sql queries’ has failed with error:.Unsupported option provided to mysql_options()
16:28:35 [ERR] WQE backend]: Got an exception during connection: Unsupported option provided to mysql_options()
16:28:35 [ERR][SQL Editor Form]: SQL editor could not be connected: Unsupported option provided to mysql_options()
16:28:35 [ERR][SQL Editor Form]: Your connection attempt failed for user ‘workbench’ from your host to server at localhost:3306:
Unsupported option provided to mysql_options()
Please:
1 Check that mysql is running on server localhost
2 Check that mysql is running on port 3306 (note: 3306 is the default, but this can be changed)
3 Check the workbench has rights to connect to localhost from your address (mysql rights define what clients can connect to the server and from which machines)
4 Make sure you are both providing a password if needed and using the correct password for localhost connecting from the host address you’re connecting from "
16:21:30 [WRN] grt]: **Could not load db.mysql.diff.reporting.wbp.so**: Could not open module /usr/lib64/mysql-workbench/plugins/db.mysql.diff.reporting.wbp.so (/usr/lib64/mysql-workbench/plugins/db.mysql.diff.reporting.wbp.so: undefined symbol: 16:21:30 [WRN] grt]: /home/mwhite/.mysql/workbench/connections.xml:25: link 'b424bd52-e26e-11e7-a0cb-902b3441ed70' <object GrtObject> **key=owner could not be resolved**
The first might be a non-critical error related to displaying detailed information,
The second error is more likely the critical error for why you are unable to connect to your database.
Suggests you should review your connection settings, if you are properly specifying the database owner.
Thank you for your response. I shall attempt to resolve the issue with that file.
When you mention database, do you mean the application or the dbname? I had the impression from the WB connection screen that I could choose my database instance, once I’d connected. Please clarify what you mean by database owner.
I have assumed that my linux username and password is the one to which the stored key is assigned, especially since I don’t receive an error message when I enter that password to unlock the keychain.
That could have been a coincedence of you using the same credentials for mysql that you’ve been using for your linux box. But … mysql’s users aren’t the same as your linux users.
The MySQL credentials are not the same as my linux server credentials.
I have installed MySQL with half a dozen database instances on a local server on a private network. I have, therefore, generally used the MySQL root login for localhost applications. I have now, however, created a new MySQL user account ‘workbench’ and granted it all privileges, so that it can be used from a remote location. i.e. either from MySQL-Workbench or from somewhere else on the local network. I have checked that these credentials provide access to the database.
My reference to linux username and password relates to the pop up which appears when I launch MWB and attempt to connect to the localhost database. “Enter password to unlock your login keyring”. It appears that the keyring is directly associated with the linux login user, as the entry of anything other than the user account password results in an error.
This is where it becomes difficult to debug (as a humble user). One enters the database account name ‘workbench’ and is forced to store the corresponding password in keyring. It’s then a matter of pure faith that what gets stored and subsequently sent to the database is in fact correct. How does this relate to the error message “key=owner cannot be resolved”? Who is the owner and of what key? Where does that come from?
Is anyone able to explain what is supposed to be going on, in words of not too many syllables?
When you launch Workbench, you may be required to provide elevated credentials (Been a long while since I’ve used Workbench, and may not be relevant since Workbench appears to be re-written).
But,
When you set up a database connection to your database, then that database will have its own “database owner.” Typically, I’ve personally made the database owner the same as the MySQL administrator for convenience(That’s the default whenever I create a new database while logged in as the MySQL administrator) and haven’t been motivated to explore configuring differently, but for all the other RDBMS I’ve dealt with the database owner is not the same as the RDBMS administrators.
Needless to say,
You should inspect your database grant tables, and particularly for access to your specified database. You should be able to use the MySQL Admin locally on your machine to do this before using the information you gather to configure Workbench.
The MySQL documentation that describes the base information,
If that is not enough, there is probably a detailed step-by-step posted by someone for your situation.
It specifies Mysql@localhost:3306 as the hostIdentifier, but I don’t use anything like that to create any of the database instances. I just use the root login through phpMyAdmin. I understand, of course, that that is not recommended practice, but is that a possible problem? Should I be using a specific administrator account and not root?
I’m sure you should be trying the MySQL Admin password and not the root password.
And, then if that doesn’t work, then you need to query the system and grant tables listed described in my last post… You will need to connect to your database successfully using <some> working method, it can be PHPMyAdmin or it can be simply opening a console on the same machine… Then log in as the MySQL admin using the password you set when you ran the MySQL security script and query the system and grant tables.
I am happy to use either command line or phpMyAdmin to manage the database - in this case the command line. The following is a listing of the grants for workbench and root.
MariaDB (none)]> show grants for workbench;
±------------------------------------------------------------------------------------------------------------------------------------+
| Grants for workbench@% |
±------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON . TO ‘workbench’@’%’ IDENTIFIED BY PASSWORD ‘15835BED4333EC105A5D72CC86C971C1C7AE8557’ WITH GRANT OPTION |
| GRANT ALL PRIVILEGES ON test. TO ‘workbench’@’%’ |
±------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
MariaDB (none)]> show grants for root@localhost;
±---------------------------------------------------------------------------------------------------------------------------------------+
| Grants for root@localhost |
±---------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON . TO ‘root’@‘localhost’ IDENTIFIED BY PASSWORD ‘*291A70FB44DF85B9D2C7EF0C80C820DA9F4D1EE0’ WITH GRANT OPTION |
| GRANT PROXY ON ‘’@’%’ TO ‘root’@‘localhost’ WITH GRANT OPTION
root is the default account used to the set up the MySQL databases, as per MySQL documentation https://dev.mysql.com/doc/refman/5.7/en/default-privileges.html. There is no mention of Mysql@localhost, as shown in the connections.xml file, so don’t understand its presence or implications.
There is a link to a utility entitled ‘Configure Server Management’ that appears when one selects a new connection in WorkBench. I have successfully used this to establish a connection to a remote MySQL database using the same credentials. So believe that the username, password and grants are entirely valid.
However, if I use the standard login screen presented by WB with those same credentials it fails. In addition, by using tcpdump to monitor the connection, it’s apparent that WB doesn’t send any form of connect string to the host and database before failing. Thereby, indicating that there’s something awry in the build and, at least at this juncture, not something related to account name and permissions.
Should this be reported as a bug? If so, to whom should I report it?