Installing MariaDB on Fedora 44 is a practical job for anyone who needs a reliable database server for development, testing, or a small production system. If you want a clean Install MariaDB Fedora 44 process, the safest path is to use Fedora’s package manager, verify the service, and secure the default setup before you put any real data into it.

This guide walks you through the full process in a way that makes sense for beginners and still stays useful for intermediate Linux users. You will learn not only how to install MariaDB, but also why each step matters, so you can avoid common mistakes that lead to broken services, weak security, or package conflicts.

Fedora ships MariaDB packages through its repositories, and MariaDB also documents DNF-based installation as the normal path on Fedora and other RPM-based systems. That means you do not need a weird workaround or a third-party installer for a standard setup.

The biggest mistake people make is stopping after the install command finishes. A proper Install MariaDB Fedora 44 setup should include updates, service checks, secure configuration, a local login test, and basic hardening so the database is ready for real work.

Prerequisites

• Fedora 44 installed and updated enough to use DNF properly.
• Sudo access or root access to install packages and manage services.
• Internet access to download repository metadata and packages.
• A working terminal with basic shell access.
• Optional: a text editor like nano, vim, or vi for configuration review.

Step 1: Update Your System

Refresh package metadata

sudo dnf upgrade --refresh

This command refreshes repository metadata and upgrades installed packages. You need it because Fedora systems can fall behind package changes, and stale metadata can create install errors or dependency confusion.

Why this matters

Updating first reduces the chance of package conflicts and makes sure you install against current repository data. It also improves security because you start from the latest patched system instead of mixing old packages with new ones.

Expected result

You should see DNF checking repositories, resolving packages, and completing without major errors. If updates are available, Fedora will install them before you move on.

Step 2: Check for Existing Database Packages

Look for MySQL or MariaDB packages

rpm -qa | grep -Ei 'mariadb|mysql'

This command shows any installed MariaDB or MySQL packages. You need to know this before installing because Fedora documentation notes that MariaDB and MySQL packages can conflict with each other.

Why this matters

If MySQL or another database stack is already installed, MariaDB may refuse to install cleanly. Checking first saves time and helps you spot package overlap before DNF gets into a conflict loop.

What to do if you find conflicts

If you see MySQL packages or older database components you do not need, remove them carefully before continuing. Do not force an install over a conflicting database stack unless you fully understand the impact.

Step 3: Install MariaDB Server

Install the server package

sudo dnf install mariadb-server mariadb

This installs the main server package plus the client tools. MariaDB’s DNF documentation recommends using package management for RPM-based systems, and Fedora supports MariaDB directly through its repositories.

Why this matters

The server package provides the database engine. The client package gives you the command-line tools you need to connect, test, and administer the database from the same machine.

Expected output

You should see DNF resolve dependencies, download packages, and finish with a success message. If DNF warns about conflicts, review your installed MySQL or MariaDB components before retrying.

Note on package names

On Fedora, package naming can vary slightly depending on repository state and release. Use the Fedora package manager and trust the repository names you see in your own system output rather than guessing package names from old tutorials.

Step 4: Start and Enable MariaDB

Start the service now

sudo systemctl start mariadb

This launches MariaDB immediately. You need it because installing the package does not always start the service on its own.

Enable it at boot

sudo systemctl enable mariadb

This makes MariaDB start automatically after every reboot. That matters on servers because you do not want a database to stay offline after a restart.

Combine both actions

sudo systemctl enable --now mariadb

This single command starts MariaDB now and also enables it for future boots. It is a clean, efficient choice for a normal Install MariaDB Fedora 44 setup.

Why this matters

A database server is only useful when the service is actually running. Enabling it at boot keeps your apps stable after updates, reboots, or power loss.

Step 5: Verify the Service

Check status

sudo systemctl status mariadb

This command shows whether MariaDB is active, failed, or still starting. It also gives you a quick look at recent log lines.

Why this matters

You should confirm the service before moving on to security or database creation. If MariaDB failed to start, fixing that now is much easier than troubleshooting after you have already built an app on top of it.

What healthy output looks like

You want to see active (running) in the status output. If you see failed, check the journal:

sudo journalctl -u mariadb --no-pager

That log can show file permission issues, startup errors, or port conflicts.

Step 6: Secure the Installation

Run the secure setup script

sudo mariadb-secure-installation

MariaDB documents this script as a way to improve installation security by setting a root password, removing anonymous users, removing test databases, and limiting remote root access.

Why this matters

A fresh database install is not production ready. The default setup can include accounts or databases that are fine for testing but weak for real use.

Common prompts and what to answer

• Current root password: Press Enter if none exists.
• Change root password: Usually n on modern MariaDB setups if you will use socket authentication.
• Remove anonymous users: y.
• Disallow root login remotely: y.
• Remove test database: y.
• Reload privilege tables: y.

Why these choices matter

Removing anonymous access and test data closes easy attack paths. Disabling remote root login protects the highest-privilege account from network-based guessing or misuse.

Important note

MariaDB notes that many modern installations use Unix socket authentication by default, so a root password may not always be needed in the same way older tutorials describe. Still, running the script and reading each prompt carefully remains a smart baseline step.

Step 7: Log In and Test

Connect locally

mariadb -u root -p

This tries a local login to the server. If your setup uses socket authentication, you may not need the -p flow in the same way old guides describe, but this is still a useful test command.

Why this matters

A successful login proves more than just a running service. It confirms the client tools, local authentication, and server socket are all working together.

Run a simple SQL test

SELECT VERSION();
SHOW DATABASES;
EXIT;

SELECT VERSION(); confirms the running server version, and SHOW DATABASES; proves you can talk to the server properly.

Expected output

You should get a MariaDB version string and a list of databases, including system databases. If login fails, the problem is usually credentials, auth method, or a service startup issue.

Step 8: Create a Database and User

Create a database

CREATE DATABASE appdb;

This creates a clean database for your project. It is better than mixing application data into system areas or using the default test database.

Create a dedicated user

CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'StrongPasswordHere';

This makes a separate account for your application. MariaDB’s security guidance favors careful account management and removing unnecessary access paths.

Grant privileges

GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;

These commands give the user access only to the database it needs. That is important because least privilege limits damage if the app account is ever compromised.

Why this matters

You should avoid using root for applications. Root has full control, while a dedicated user keeps permissions focused and easier to manage.

Step 9: Configure MariaDB Fedora 44 for Remote Access

Check the bind address

sudo grep -R "bind-address" /etc/my.cnf /etc/my.cnf.d/

This helps you see whether MariaDB listens only on localhost or on a wider interface. Fedora and MariaDB both expect you to think carefully before exposing the server to the network.

Why this matters

By default, a database should not listen openly to the internet. Remote access should be a deliberate choice, not an accidental one.

If you need remote access

If your app runs on another host, update the MariaDB config carefully and restart the service after changes. Then create a user limited to the app host instead of opening root to the world.

Example remote user

CREATE USER 'appuser'@'192.168.1.50' IDENTIFIED BY 'StrongPasswordHere';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'192.168.1.50';
FLUSH PRIVILEGES;

This keeps access tied to one trusted address. That is much safer than allowing % from anywhere.

Step 10: Open the Firewall If Needed

Allow the MariaDB port

sudo firewall-cmd --add-service=mysql --permanent
sudo firewall-cmd --reload

This opens the standard MySQL and MariaDB service name in firewalld. You only need it if remote clients must connect.

Why this matters

The service may be running correctly, but the firewall can still block access. If your remote connection fails, the firewall is one of the first places to check.

Expected output

You should see a success message from firewalld. After that, test the port from the remote machine, not just locally.

Step 11: Review Configuration Files

Find the main config

sudo ls -l /etc/my.cnf /etc/my.cnf.d/

This shows the main MariaDB config locations on Fedora. Most system-wide tuning happens through files in that path.

Why this matters

You should know where settings live before you edit anything. That makes future troubleshooting easier and helps you avoid random edits in the wrong file.

Best practice

Change only one thing at a time. After each config change, restart MariaDB and test again so you know exactly what caused the result.

Troubleshooting

1. MariaDB will not start

sudo systemctl status mariadb
sudo journalctl -u mariadb --no-pager

This usually means a config error, port conflict, or permission issue. The logs will tell you where the startup failed.

2. DNF reports package conflicts

If DNF complains about MySQL and MariaDB conflicts, check installed packages first. Fedora documentation confirms the two stacks can clash, so you may need to remove the conflicting one before installing MariaDB.

3. Login fails after install

If mariadb -u root -p does not work, check whether socket authentication is active. MariaDB notes that modern versions often use Unix socket authentication, so the login method may differ from older tutorials.

4. Remote connection times out

Check firewall rules, bind address, and the user host in the grant statement. A network timeout usually means the server is not listening publicly or the firewall is still blocking traffic.

5. mariadb-secure-installation asks unexpected prompts

Read the prompts carefully and do not rush through them. MariaDB documents that the script adjusts root access, anonymous users, test databases, and privilege tables, so each choice affects real security.