MySQL Workbench on Fedora is a different program now. Oracle retired the C++ and GTK Workbench 8.0 and replaced it with Workbench 26, an Electron desktop app built on MySQL Shell, shipped as one generic RPM that installs under /opt/MySQL Workbench and weighs about 1 GiB on disk.
The old install path is gone as well. Fedora has no Workbench package, the Oracle repository that its release RPM enables returns 404 for Workbench, and the old mysql84-community-release instructions stop at Fedora 43. This guide installs MySQL 9.7 from the Fedora repositories, installs Workbench from the signed RPM with the signature actually enforced, then connects, queries and inspects the server through the new administration pages.
Tested October 2026 with MySQL Workbench 26.7.0 on Fedora 45 and Fedora 44 (GNOME, SELinux enforcing).
What changed for Workbench on Fedora
Oracle’s Workbench 26 announcement states that Workbench 8.0 has reached end of life and will get no new releases, and that the new Workbench supports MySQL 8.4 LTS and newer, including MySQL 9.7 LTS. The table below records what the test machines showed for each part of the install path:
| Item | Fedora 45 | Fedora 44 |
|---|---|---|
mysql-workbench in Fedora repositories | No match | No match |
Oracle release RPM mysql97-community-release-fc<N> | 404 | Installs, enables repo mysql-tools-9.7-lts-community |
Its baseurl mysql-tools-9.7-community repodata | 404 | 404, skipped by dnf |
mysql-tools-community repodata | 404 | 200, but lists 0 packages |
| Generic Workbench RPM from dev.mysql.com | Installs, 2 dependencies | Installs, 2 dependencies |
| MySQL 9.7 server from Fedora | mysql-server (9.7.2) | mysql9.7-server (9.7.1) |
| Default MySQL server package | 9.7 | 8.4 |
The Fedora 44 rows are the trap. The Oracle release RPM installs cleanly and enables a tools repository, so dnf install mysql-workbench looks like it should work, yet it ends with No match for argument: mysql-workbench. Checking the Oracle repository paths directly shows why:
for r in mysql-tools-9.7-community mysql-tools-community; do for f in 44 45; do echo "$r/fc/$f $(curl -s -o /dev/null -w "%{http_code}" https://repo.mysql.com/yum/$r/fc/$f/x86_64/repodata/repomd.xml)"; done; done
Only one of the four paths answers, and it is not the one the release RPM configures:
mysql-tools-9.7-community/fc/44 404
mysql-tools-9.7-community/fc/45 404
mysql-tools-community/fc/44 200
mysql-tools-community/fc/45 404
The Workbench RPM file does sit in the mysql-tools-community/fc/44 directory, but the repository metadata beside it is empty, so a hand-written .repo file pointing there finds nothing either:
B=https://repo.mysql.com/yum/mysql-tools-community/fc/44/x86_64
P=$(curl -s $B/repodata/repomd.xml | grep -oP "repodata/[0-9a-f]+-primary\.xml\.gz")
curl -s $B/$P | gunzip | grep -o "packages=\"[0-9]*\""
curl -s $B/ | grep -oE "mysql-workbench-[0-9.]+-1\.x86_64\.rpm" | sort -u
The metadata declares zero packages while the directory listing shows the RPM:
packages="0"
mysql-workbench-26.7.0-1.x86_64.rpm
The working route on both releases is the generic RPM that the Workbench download page lists when the operating system selector is set to the generic Linux option. It is built on an EL8 host against an older glibc baseline, carries no Fedora release tag, and pulls only two small libraries from the Fedora repositories. If you already installed the Oracle release RPM on Fedora 44, remove it with sudo dnf remove -y mysql97-community-release, otherwise every dnf run prints the 404 errors and the Oracle server repository stays enabled beside the Fedora packages. If a later Oracle repository does publish indexed Workbench packages, the same signing key applies, which is covered in the guide to third-party repository 404 errors on Fedora.
Step 1: Install MySQL 9.7 from the Fedora repositories
Skip this step if Workbench will only manage remote servers. For a local server, the package name differs between the two releases because Fedora 45 moved the default mysql-server package to the 9.7 series, while Fedora 44 keeps 8.4 as the default and ships 9.7 as a parallel package. On Fedora 45:
sudo dnf install -y mysql-server
On Fedora 44, install the versioned package to get the same LTS series:
sudo dnf install -y mysql9.7-server
Both releases pull eight packages, including mysql-selinux for the SELinux policy module. Start the service and confirm the version:
sudo systemctl enable --now mysqld
systemctl is-active mysqld
mysqld --version
Fedora 45 reported this build, and Fedora 44 reported a slightly older 9.7 point release from its updates repository:
active
/usr/libexec/mysqld Ver 9.7.2 for Linux on x86_64 (Source distribution)
The server listens on 3306 for the classic protocol and on 33060 for the X Protocol that MySQL Shell can also use. Readers who need the older series can follow the MySQL 8 on Fedora guide instead.
Step 2: Close the empty root password
The Fedora package initializes the data directory with an empty root password. Any local account on the machine can log in as the MySQL root user without sudo, which was confirmed on both releases:
mysql -u root -e "SELECT CURRENT_USER()"
An unprivileged shell gets straight in as the MySQL root user, with no password prompt at all:
CURRENT_USER()
root@localhost
Switching root to socket authentication closes that hole and keeps sudo mysql working for administration. The auth_socket plugin ships with the Fedora build but is not loaded by default, so install it first:
sudo mysql -e "INSTALL PLUGIN auth_socket SONAME 'auth_socket.so'"
sudo mysql -e "ALTER USER 'root'@'localhost' IDENTIFIED WITH auth_socket"
sudo mysql -e "SELECT user, host, plugin FROM mysql.user WHERE user='root'"
The root account now authenticates through the Unix socket:
user host plugin
root localhost auth_socket
Running the same login test again as a normal user is now refused, while sudo mysql still opens a root session. The setting survived a systemctl restart mysqld on the test box:
ERROR 1698 (28000): Access denied for user 'root'@'localhost'
Step 3: Create a Workbench account and a sample schema
Socket authentication cannot be used over the TCP connection that Workbench opens, so Workbench needs its own password account. Replace the example password with a strong value of your own:
sudo mysql -e "CREATE USER 'wbadmin'@'localhost' IDENTIFIED BY 'Wb-Example-Pass-2026'; GRANT ALL PRIVILEGES ON *.* TO 'wbadmin'@'localhost' WITH GRANT OPTION;"
This grant gives full administrative rights, which the User Accounts and Server Status pages need. For a query-only account, grant privileges on a single schema instead. Add a small schema to query:
sudo mysql -e "CREATE DATABASE inventory; CREATE TABLE inventory.servers (id INT AUTO_INCREMENT PRIMARY KEY, hostname VARCHAR(64) NOT NULL, os VARCHAR(32), ram_gb INT, added TIMESTAMP DEFAULT CURRENT_TIMESTAMP); INSERT INTO inventory.servers (hostname, os, ram_gb) VALUES ('web01','Fedora 45',8),('web02','Fedora 44',8),('db01','Rocky Linux 10',32),('cache01','Debian 13',4);"
sudo mysql -t -e 'SELECT id, hostname, os, ram_gb FROM inventory.servers'
The query returns the four sample rows that the Workbench editor will show later:
+----+----------+----------------+--------+
| id | hostname | os | ram_gb |
+----+----------+----------------+--------+
| 1 | web01 | Fedora 45 | 8 |
| 2 | web02 | Fedora 44 | 8 |
| 3 | db01 | Rocky Linux 10 | 32 |
| 4 | cache01 | Debian 13 | 4 |
+----+----------+----------------+--------+
Step 4: Download and verify the Workbench RPM
The download page lists the current file name, so the version can be read from it instead of being typed by hand. Store it in a variable:
VER=$(curl -s "https://dev.mysql.com/downloads/workbench/?os=2" | grep -oP "mysql-workbench-\K[0-9.]+(?=-1\.x86_64\.rpm)" | sort -uV | tail -1)
[ -n "$VER" ] && echo $VER || echo "version not detected"
At the time of testing, the download page offered a single current release:
26.7.0
Download the RPM into the home directory. The -f flag makes curl fail with a 404 instead of saving an error page if the version was not detected:
cd ~
curl -fsSLO https://dev.mysql.com/get/Downloads/MySQLGUITools/mysql-workbench-${VER}-1.x86_64.rpm
ls -lh mysql-workbench-${VER}-1.x86_64.rpm
The listing confirms the file arrived intact in size:
-rw-r--r--. 1 klinsmann klinsmann 265M Oct 10 20:16 mysql-workbench-26.7.0-1.x86_64.rpm
Unlike many vendor RPMs, this one is signed. Before the key is imported, rpm -K fails and the verbose form names the signing key:
rpm -K mysql-workbench-*.x86_64.rpm
rpm -Kv mysql-workbench-*.x86_64.rpm | grep "RSA/SHA256"
The key ID b7b3b788a8d3785c belongs to MySQL Release Engineering:
mysql-workbench-26.7.0-1.x86_64.rpm: digests SIGNATURES NOT OK
Header OpenPGP V4 RSA/SHA256 signature, key ID b7b3b788a8d3785c: NOKEY
Legacy OpenPGP V4 RSA/SHA256 signature, key ID b7b3b788a8d3785c: NOKEY
Import the 2025 MySQL signing key from repo.mysql.com and list it:
sudo rpmkeys --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2025
rpmkeys --list | grep -i mysql
The fingerprint ends in the same key ID that the package reported:
bca43417c3b485dd128ec6d4b7b3b788a8d3785c MySQL Release Engineering <[email protected]> public key
Run the same signature check again now that the key is in the rpm database:
rpm -K mysql-workbench-*.x86_64.rpm
Both digests and the signature now pass, so the file is the one that MySQL Release Engineering signed:
mysql-workbench-26.7.0-1.x86_64.rpm: digests signatures OK
The background on why Fedora 45 treats an unverified package more strictly than Fedora 44 is in the rpm NOKEY guide for Fedora.
Step 5: Install Workbench with the signature enforced
dnf does not check signatures on local RPM files by default, because localpkg_gpgcheck is 0 on both releases. A plain dnf install of this file prints Warning: skipped OpenPGP checks for 1 package from repository: @commandline even when the key is present. Turn the check on for this transaction:
sudo dnf install -y --setopt=localpkg_gpgcheck=1 ./mysql-workbench-${VER}-1.x86_64.rpm
The transaction completes with no skipped-check warning, which means dnf verified the signature against the imported key:
Package Arch Version Repository Size
Installing:
mysql-workbench x86_64 0:26.7.0-1 @commandline 1.0 GiB
Installing dependencies:
libXScrnSaver x86_64 0:1.2.5-2.fc45 fedora 51.8 KiB
Transaction Summary:
Installing: 2 packages
Total size of inbound packages is 265 MiB. Need to download 25 KiB.
After this operation, 1 GiB extra will be used (install 1 GiB, remove 0 B).
--------------------------------------------------------------------------------
Running transaction
Complete!
On a machine that never had Workbench, dnf also pulls libxcrypt-compat, which makes two dependencies on both releases. The output above lists one because libxcrypt-compat was already installed on the test box from an earlier run. The package installs the Electron app to /opt/MySQL Workbench, registers /usr/bin/mysql-workbench through the alternatives system, and adds a desktop entry:
readlink -f /usr/bin/mysql-workbench
du -sh "/opt/MySQL Workbench"
grep -E "^(Name|Exec|Comment)=" /usr/share/applications/mysql-workbench.desktop
The binary lives under a directory name that contains a space, which matters for any script that calls it by full path:
/opt/MySQL Workbench/mysql-workbench
1019M /opt/MySQL Workbench
Name=MySQL Workbench
Exec="/opt/MySQL Workbench/mysql-workbench" %U
Comment=Graphical MySQL development and administration tool based on MySQL Shell
Step 6: Connect Workbench to MySQL 9.7
Start Workbench from the GNOME overview by searching for workbench, or run mysql-workbench from a terminal. The first window states the supported server range directly:

Click the + beside Database Connections. Set a caption, leave the method as mysql with host localhost and port 3306, then enter wbadmin as the user and inventory as the default schema:

Click Store Password, type the password into the prompt and confirm. Then click Test Connection. A notification in the corner reports the result:

Click OK to save the connection, then click its tile to open it. The header shows the account, the server build and the auto-commit state. Type a query into the SQL editor and run it with Ctrl+Enter:

Fedora 44 connected to its own MySQL 9.7 server with the same settings:

The stored password does not go into the desktop keyring, even though one is running (oo7 on Fedora 45, gnome-keyring on Fedora 44). Workbench saves it through the MySQL Shell credential store, which on the test machines wrote ~/.mylogin.cnf with mode 600 at the moment Store Password was clicked. mysql_config_editor print --all lists it as a login path named [wbadmin@localhost:3306]. That file is obfuscated rather than encrypted, so treat it like any other credentials file. Connection definitions are kept in ~/.config/MySQL Workbench.
Step 7: Use the administration pages
The left pane lists the administration pages above the schema tree. Server Status collects host, port, socket, directories, log state and enabled features on one page:

Binary logging is on, which is the upstream MySQL default, and the error log is at /var/log/mysql/mysqld.log. User Accounts summarizes the password policy and every account with its authentication plugin, lock state and privilege counts:

This capture was taken before Step 2 was applied, so root still shows caching_sha2_password. After the change, the same row shows auth_socket. The Database menu holds the full set of administration tools in this release:

None of the seven menus (File, Edit, View, Run, Database, Window, Help) on the test machines contains a data modeling entry: no EER diagrams, no forward or reverse engineering, and no schema synchronization. Oracle describes the new Workbench as a ground-up rebuild in which some Workbench 8 features are not available yet, so anyone whose workflow depends on EER modeling should check the Release Notes link on the welcome screen before relying on this version for it. Oracle lists SQL Notebooks, a redesigned Visual Explain and a SQL formatter as the main development additions; those were not tested here.
Step 8: Update or remove Workbench
With no working repository, updates are manual. Repeat Step 4 to fetch and verify the newest file, then run the same install command from Step 5. dnf upgrades the installed package when the local file is newer. That path could not be exercised here, because only one Workbench release existed at the time of testing:
sudo dnf install -y --setopt=localpkg_gpgcheck=1 ./mysql-workbench-${VER}-1.x86_64.rpm
Oracle ships Workbench as a single release series and recommends always running the latest version. To remove it, run:
sudo dnf remove -y mysql-workbench
On Fedora 44, dnf removed libXScrnSaver and libxcrypt-compat as unused dependencies. On Fedora 45 it removed libXScrnSaver and kept libxcrypt-compat. On Fedora 44 an empty directory tree with 0 bytes of files remained under /opt/MySQL Workbench, and the per-user data stayed in place. Clear the leftovers and the signing key if no other MySQL packages need it:
sudo rm -rf "/opt/MySQL Workbench"
rm -rf "$HOME/.config/MySQL Workbench"
sudo rpmkeys --delete bca43417c3b485dd128ec6d4b7b3b788a8d3785c
The saved password lives in ~/.mylogin.cnf. That file also holds any login paths created with mysql_config_editor, so check it with mysql_config_editor print --all (part of the MySQL client package from Step 1) before deleting it:
rm -f "$HOME/.mylogin.cnf"
With the account file gone, nothing from Workbench remains in the home directory.
Measured on Fedora 45 and Fedora 44
The numbers below come from the two test machines, both on the Workstation desktop with GNOME on Wayland:
| Measurement | Fedora 45 | Fedora 44 |
|---|---|---|
| RPM download | 265 MiB | 265 MiB |
Installed size (du) | 1019 MiB | 1019 MiB |
| Dependencies from Fedora | libXScrnSaver, libxcrypt-compat | libXScrnSaver, libxcrypt-compat |
| Bundled MySQL Shell | 26.7.1 | Same RPM, not checked |
| Display protocol | Native Wayland | Native Wayland |
| Server tested | MySQL 9.7.2 | MySQL 9.7.1 |
| Connection test | Succeeded | Succeeded |
| SELinux denials for Workbench and mysqld | 0 | 0 |
| Saved password location | ~/.mylogin.cnf | ~/.mylogin.cnf |
The Rocky Linux and AlmaLinux version of this setup is in the MySQL Workbench guide for Rocky and AlmaLinux. For a client that also handles PostgreSQL and MariaDB, see DBeaver on Fedora.
THERE IS NO WORKBENCH PACKAGE FOR FEDORA 41 and 42, this article wasted a lot of my time troubleshooting until i figured out the package has not been made and does not exist. How about you actually test before publishing.
Use third or second method.
BEWARE, this command: “sudo dnf install ./mysql-workbench-community-8.0.42-1.fc40.src.rpm” will install the source code, not the actual application, and it will also make it so you cant install the application, because it will think its already installed, PLUS you cant easily remove source packages in Fedora, so you will have a hard time undoing this if you do.
The second and third method doesn’t works neither.