You upgraded your app and the database won't talk to the network
You installed PostgreSQL or MariaDB on your Fedora workstation to host a development database. You fire up your laptop, open your IDE, and try to connect to the server IP. The connection hangs for ten seconds and then fails with a timeout. Or you get Connection refused. You checked the service is running. You checked the IP is correct. The database is sitting there, perfectly healthy, but it refuses to talk to anyone outside the machine.
This is the default behavior. Fedora and the database engines both assume local-only access for security. The database binds to the loopback interface. The firewall drops packets destined for the database port. The host-based access control list inside the database rejects remote users. You need to change that assumption explicitly. You have to open the door on the application, tell the firewall to let traffic through, and grant permission in the database's access list. Skipping one layer leaves you stuck.
What's actually happening
Three separate systems are blocking your connection. The database server is configured to listen only on the loopback interface. The firewall is dropping packets destined for the database port. And the host-based access control list inside the database might be rejecting remote users.
Think of the database as a house. The application config is the front door. It is locked to the inside hallway. The firewall is the gate around the property. It is closed. The access control list is the bouncer. It only lets in people from the neighborhood. You need to open the door, open the gate, and tell the bouncer to accept visitors from the street.
If you open the gate but leave the door locked, traffic hits the wall. If you open the door but the gate is closed, the firewall drops the packet. If you open both but the bouncer rejects you, the connection is accepted and then immediately terminated. You must configure all three layers.
Config files in /etc/ or the data directory are user-modified. Files in /usr/lib/ ship with the package. Edit the configuration in the data directory or /etc/. Never edit /usr/lib/. Changes there get overwritten on the next package update.
Configure PostgreSQL for remote access
Here's how to configure PostgreSQL to accept remote connections. You need to edit the main configuration to bind to all interfaces, update the host-based authentication file to allow remote IPs, and open the port in the firewall.
Edit the postgresql.conf file to change the listen address. The default value is localhost. Change it to * to bind to all network interfaces.
# Edit the main configuration file in the data directory
sudo nano /var/lib/pgsql/data/postgresql.conf
Find the listen_addresses line. Remove the comment character and change the value.
# Change from 'localhost' to '*' to bind to all network interfaces
# This allows the server to accept connections on any IP address assigned to the machine
listen_addresses = '*'
Save the file. Next, edit pg_hba.conf to allow remote connections. This file controls which hosts can connect and what authentication method is used. The file processes lines top to bottom. The first match wins. Add your remote rule at the end of the file so it does not override local rules.
# Edit the host-based authentication configuration
sudo nano /var/lib/pgsql/data/pg_hba.conf
Add a line to allow connections from your network range. Use scram-sha-256 for strong authentication. Never use trust for remote connections. That allows anyone on the network to log in without a password.
# Allow connections from any IPv4 address using strong authentication
# Replace 0.0.0.0/0 with your specific subnet like 192.168.1.0/24 for better security
host all all 0.0.0.0/0 scram-sha-256
Reload the firewall after every rule change. The runtime and persistent configs diverge silently if you skip this.
Configure MariaDB for remote access
MariaDB requires a similar three-step process. You need to change the bind address, open the firewall, and ensure the database user is allowed to connect from remote hosts.
Edit the MariaDB server configuration. Fedora stores drop-in configs in /etc/my.cnf.d/. Edit server.cnf to change the bind address.
# Edit the MariaDB server configuration drop-in file
sudo nano /etc/my.cnf.d/server.cnf
Find the bind-address line. Change it from 127.0.0.1 to 0.0.0.0.
# Bind to all interfaces instead of just localhost
# This allows MariaDB to listen on the network interface for incoming connections
bind-address = 0.0.0.0
Save the file. MariaDB also requires user grants. A user created for localhost cannot connect remotely. You must create a user entry that allows connections from % or a specific IP.
# Log in to the local MariaDB shell to manage users
sudo mysql
Run the grant command inside the shell. This creates the user or updates the existing user to allow remote access.
-- Create a user that can connect from any host
-- Replace 'app_user' and 'strong_password' with your credentials
CREATE USER 'app_user'@'%' IDENTIFIED BY 'strong_password';
-- Grant privileges to the remote user
-- Adjust the database name and privileges as needed
GRANT ALL PRIVILEGES ON your_database.* TO 'app_user'@'%';
-- Apply the changes immediately
FLUSH PRIVILEGES;
Restart the service after editing the config. MariaDB reads the bind address only at startup.
Open the firewall and verify
Both databases require the firewall to allow traffic on their ports. Fedora uses firewalld. Use the --permanent flag to make the rule survive a reboot. Use the named service definition instead of raw ports. The service definition includes the correct port and protocol.
Here's how to open the firewall for PostgreSQL and reload the rules.
# Add the PostgreSQL service to the permanent firewall configuration
# This opens TCP port 5432 using the named service definition
sudo firewall-cmd --permanent --add-service=postgresql
# Reload the firewall to apply permanent rules to the running system
# This step is required. Without it, the runtime config does not match the permanent config
sudo firewall-cmd --reload
For MariaDB, use the mysql service name. MariaDB uses the same port as MySQL, so the service name is shared.
# Add the MySQL/MariaDB service to the permanent firewall configuration
# This opens TCP port 3306 using the named service definition
sudo firewall-cmd --permanent --add-service=mysql
# Reload the firewall to apply changes immediately
sudo firewall-cmd --reload
Restart the database services to apply the configuration changes.
# Restart PostgreSQL to pick up listen_addresses changes
sudo systemctl restart postgresql-16
# Restart MariaDB to rebind the network socket
sudo systemctl restart mariadb
Check the socket before blaming the network. ss tells you if the app is actually listening.
Verify it worked
Run ss to confirm the database is listening on all interfaces. The output should show 0.0.0.0:5432 or 0.0.0.0:3306. If you see 127.0.0.1:5432, the config change did not take effect.
# Show listening TCP sockets and the process owning them
# Look for 0.0.0.0:5432 for PostgreSQL or 0.0.0.0:3306 for MariaDB
sudo ss -tlnp | grep -E '5432|3306'
Verify the firewall allows the service.
# List active services in the default zone
# The database service should appear in the list
sudo firewall-cmd --list-services
Test the connection from a remote machine. If you see psql: error: connection to server at "192.168.1.50", port 5432 failed: Connection refused, the server isn't listening on the network interface. Check ss output. If you see FATAL: password authentication failed for user "app", the network path works but pg_hba.conf is rejecting the credentials. Check the authentication method in pg_hba.conf.
Run journalctl -xe to read the actual error before guessing. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
# Check PostgreSQL logs for connection errors
# Look for FATAL messages or authentication failures
sudo journalctl -xeu postgresql-16
# Check MariaDB logs for bind errors or access denied
sudo journalctl -xeu mariadb
Common pitfalls and security risks
Never use trust for remote connections. That allows anyone on the network to log in without a password. Use scram-sha-256 for PostgreSQL. Use mysql_native_password or caching_sha2_password for MariaDB. Restrict the IP range in pg_hba.conf or the firewall. 0.0.0.0/0 opens the port to the entire internet if your firewall is misconfigured.
SELinux enforces mandatory access control on Fedora. If you change the database port to a non-standard value, SELinux will block connections. You must add the new port to the SELinux policy.
# Add a custom port to the SELinux policy for PostgreSQL
# Replace 5433 with your custom port number
sudo semanage port -a -t postgresql_port_t -p tcp 5433
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. Disabling SELinux removes a critical security layer. Fix the policy instead.
Lock down the IP range. Open ports to the world invite scanners within minutes.
When to use this vs alternatives
Use PostgreSQL when your application requires strict data integrity and JSON support. Use MariaDB when you are maintaining compatibility with existing MySQL tooling. Use SSH tunneling when you need secure access without opening firewall ports. Use a dedicated VPN when multiple team members require persistent database access. Keep the database local-only when the application runs on the same host.