The database service won't start after installation
You just finished a fresh Fedora install and ran dnf install mariadb-server. The terminal prints a success message, but when you try to connect with mysql -u root, it throws a socket error. Or maybe you installed MySQL from the official repository and systemctl start mysqld hangs indefinitely. The database isn't broken. Fedora's default security posture and service management model just require a few explicit steps before the database accepts connections.
What is actually happening under the hood
Databases are stateful services. They do not just run in memory. They need a dedicated data directory, strict file permissions, and a listening socket or network port. Fedora ships with SELinux enforcing by default. It also uses systemd to manage service lifecycles. When you install a database package, the binaries and configuration templates land on disk, but the service remains inactive. The data directory is empty. The root account has no password set. Running the security script bridges the gap between a raw package install and a production-ready service. Think of it like buying a car. The package manager drops the chassis in your driveway. You still need to add fuel, turn the key, and lock the doors before it drives.
Fedora separates package-owned files from user-modified configuration. The base configuration lives in /usr/lib/mysql/ or /usr/share/mysql/. Those files are read-only and get overwritten during dnf upgrade. Your custom settings belong in /etc/my.cnf.d/. The daemon merges them at startup. Keeping this boundary clear prevents configuration drift and makes upgrades predictable.
Install and secure MariaDB
MariaDB is the default relational database on Fedora. It is a community-driven fork of MySQL that maintains compatibility while adding modern storage engines and replication features. The package manager handles dependencies automatically.
Here is how to pull the server package and its required libraries from the Fedora repositories.
sudo dnf install -y mariadb-server
# -y skips the interactive confirmation prompt
# mariadb-server pulls in the client tools and shared libraries automatically
# dnf resolves all dependencies and downloads the RPMs
The package lands on disk, but the service does not start automatically. You need to register it with systemd so it survives reboots and begins running immediately.
sudo systemctl enable --now mariadb.service
# enable creates the symlink in /etc/systemd/system for boot persistence
# --now tells systemd to start the unit immediately after enabling
# mariadb.service is the canonical unit name on Fedora
A fresh installation leaves the root account passwordless and exposes test databases to the network. The security script walks you through locking down the default configuration.
sudo mysql_secure_installation
# Press Enter when prompted for the current root password
# Switch to unix_socket authentication for local admin access
# Set a strong password for the root account
# Remove anonymous users and disable remote root login
# Drop the test database and flush privileges
The script modifies the internal MySQL grant tables. It does not touch your application data. If you ever need to adjust the configuration later, edit files in /etc/my.cnf.d/. Never edit files in /usr/lib/mysql/. Those ship with the package and get overwritten on every dnf upgrade.
Install and secure MySQL
Oracle MySQL is not included in the default Fedora repositories due to licensing differences. You must add the official MySQL repository RPM before installing the server. The repository RPM contains the metadata that points dnf to Oracle's package servers.
Here is how to register the MySQL 8.0 repository and install the server package.
sudo dnf install -y https://dev.mysql.com/get/mysql80-community-release-el9-1.noarch.rpm
# Downloads the repository definition file directly from Oracle
# el9 matches Fedora's RHEL 9 base compatibility layer
# The RPM places a .repo file in /etc/yum.repos.d/
Once the repository is registered, install the server package and register the service with systemd.
sudo dnf install -y mysql-server
sudo systemctl enable --now mysqld.service
# mysql-server installs the binaries and default configuration
# mysqld.service is the canonical unit name for Oracle MySQL
# systemd starts the daemon and creates the data directory
MySQL 8.0 generates a temporary root password during the first startup. You must retrieve it from the journal before you can log in.
sudo grep 'temporary password' /var/log/mysqld.log
# Extracts the auto-generated password from the startup log
# The password contains uppercase, lowercase, numbers, and symbols
# Copy it exactly. Whitespace breaks the authentication step
Run the security script to replace the temporary password and lock down the installation.
sudo mysql_secure_installation
# Paste the temporary password when prompted
# The VALIDATE PASSWORD COMPONENT will ask if you want to enforce strength rules
# Set a permanent root password
# Remove anonymous users and disable remote root login
# Drop the test database and reload privilege tables
Configure the data directory and permissions
The database daemon runs as the mysql system user. That user must own the data directory and have exclusive read-write access. If you create the directory manually, or if you restore a backup from another machine, ownership breaks and the service refuses to start.
Here is how to verify and correct directory permissions before the daemon attempts to mount the data files.
sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod 750 /var/lib/mysql
# Recursively fixes ownership for the data directory
# 750 grants full access to mysql, read-execute to group, nothing to others
# Incorrect permissions cause immediate startup failure
SELinux enforces mandatory access control on Fedora. The database expects the data directory to carry the mysqld_db_t context. Moving data to /home or /opt without relabeling triggers denials.
Here is how to restore the correct security context after moving or restoring data.
sudo restorecon -Rv /var/lib/mysql
# -R applies the fix recursively to all files and subdirectories
# -v prints each file as the context is corrected
# restorecon reads the default policy and reapplies the correct label
Do not disable SELinux to fix permission errors. Fix the context instead. The policy exists to prevent the database process from reading unrelated system files or writing to protected paths.
Verify the service is running
A successful installation means nothing if the daemon refuses connections. Check the systemd unit state first. It shows the active status, recent log lines, and any resource limits in one view.
Here is how to inspect the service state and recent journal entries.
systemctl status mariadb.service
# Replace mariadb.service with mysqld.service if you installed Oracle MySQL
# Look for Active: active (running) in green text
# Check the Main PID line to confirm the process is alive
If the status command shows active (running), test the actual database connection. The mysqladmin client sends a ping to the server and reports latency.
Here is how to verify the daemon accepts authentication and responds to queries.
mysqladmin -u root -p ping
# -u root specifies the administrative user
# -p prompts for the password you set during secure_installation
# A successful response prints mysqld is alive and shows response time
Run journalctl -xeu mariadb.service if the status command shows a failure. The x flag adds explanatory text and the e flag jumps to the end of the log. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Read the actual error before guessing.
Common pitfalls and error messages
Database installations fail for predictable reasons. Fedora's security defaults and network configuration are the usual suspects.
The client cannot find the socket file. This happens when the client and server expect different paths.
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
The server usually listens on /run/mariadb/mariadb.sock on Fedora. Create a symlink or pass --socket=/run/mariadb/mariadb.sock to the client. Check the [client] and [mysqld] sections in /etc/my.cnf.d/ to align the paths.
SELinux blocks the service from starting. Fedora enforces mandatory access control by default. If you moved the data directory to a non-standard location, the daemon will be denied access.
[FAILED] Failed to start MariaDB 10.11 database server.
Check the audit log for denials. Run sudo ausearch -m avc -ts recent to see blocked operations. Restore the correct context with sudo restorecon -Rv /path/to/data. Do not disable SELinux. Fix the context instead.
The firewall drops incoming connections. The database listens on port 3306 by default. Fedora's firewalld blocks it until you add a rule.
sudo firewall-cmd --permanent --add-service=mysql
sudo firewall-cmd --reload
# --permanent saves the rule across reboots
# --reload applies the persistent configuration to the running firewall
# Always reload after every rule change to prevent config drift
The systemd unit fails with a permission error. This usually means the mysql user does not own the data directory. The package manager creates the user automatically, but manual directory creation breaks ownership.
sudo chown -R mysql:mysql /var/lib/mysql
sudo systemctl restart mariadb.service
# Recursively fixes ownership for the data directory
# Restart forces the daemon to re-read permissions on startup
Choose your database engine
Use MariaDB when you want a drop-in replacement for MySQL with open-source licensing and modern storage engines. Use MySQL when your application stack requires Oracle-specific features or you need official vendor support contracts. Use PostgreSQL when you are building complex queries, need advanced JSON handling, or require strict SQL compliance. Stay on the default Fedora repositories for MariaDB to avoid dependency conflicts during system upgrades.