Você reiniciou seu servidor Linux e seu site WordPress simplesmente parou de funcionar? Aquela mensagem frustrante “Error establishing a database connection” apareceu do nada, mesmo com o MariaDB rodando normalmente?

Pois é… passei por isso recentemente e a solução não foi óbvia a princípio, mas depois de descobrir foi “num pode ser que era isso”. Se você usa Podman para rodar seus containers, esse post pode te salvar algumas horas de debugging.

O Cenário

Tenho um servidor Fedora 43 rodando:

• WordPress em um container Podman
• MariaDB instalado diretamente no host (fora do container)
• O container conecta ao banco via host.docker.internal
• Tudo funcionava perfeitamente… até eu reiniciar o servidor.

O Problema

Após o reboot, o site começou a mostrar apenas:

Error establishing a database connection

Primeira coisa que verifiquei: o MariaDB está rodando?

sudo systemctl status mariadb

? mariadb.service - MariaDB 10.11 database server
     Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: disabled)
     Active: active (running) since Sun 2025-11-30 04:49:10 UTC; 12min ago
     Status: "Taking your SQL requests now..."

Rodando normalmente. Então o problema não era o banco.

Investigando o Container

Verifiquei o status do container:

podman ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

NAMES             STATUS                     PORTS
fogonacaixadagua  Up 17 minutes (unhealthy)  127.0.0.1:3008->80/tcp, 9000/tcp

Unhealthy. O healthcheck do container estava falhando. Os logs confirmaram o problema:

podman logs fogonacaixadagua --tail 10

127.0.0.1 -  30/Nov/2025:05:06:03 +0000 "GET /index.php" 500
127.0.0.1 -  30/Nov/2025:05:06:15 +0000 "GET /index.php" 500

Todas as requisições retornando erro 500. O container com o WordPress estava no bueno.

Verificando a Configuração

No wp-config.php, a configuração de conexão estava correta:

define('DB_HOST', 'host.docker.internal');

E no docker-compose.yml (usado com podman-compose):

services:
  wordpress:
    extra_hosts:
      - "host.docker.internal:host-gateway"

O hostname estava resolvendo corretamente dentro do container:

podman exec fogonacaixadagua getent hosts host.docker.internal

10.89.0.1         host.docker.internal  host.docker.internal

O MariaDB estava escutando em todas as interfaces:

sudo ss -tlnp | grep 3306

LISTEN 0      80      0.0.0.0:3306       0.0.0.0:*    users:(("mariadbd",pid=1093,fd=23))

Então por que não conectava?

O Teste Decisivo

Tentei conectar na porta 3306 de dentro do container:

podman exec fogonacaixadagua nc -zv host.docker.internal 3306

nc: host.docker.internal (10.89.0.1:3306): Host is unreachable

Host is unreachable. O container não conseguia alcançar o host na porta do banco. Isso cheirava a firewall.

A Causa Raiz: Firewalld

Verifiquei as zonas do firewall:

sudo firewall-cmd --list-all

FedoraServer (default, active)
  interfaces: eth0
  services: dhcpv6-client http https ssh
  ...

Percebeu o problema? A interface eth0 está na zona, mas e a interface do Podman?

ip addr show | grep -E 'podman|10.89'

4: podman1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    inet 10.89.0.1/24 brd 10.89.0.255 scope global podman1

A interface podman1 existe com o IP 10.89.0.1, mas não estava associada a nenhuma zona do firewall. Por padrão, o firewalld bloqueia tráfego de interfaces não associadas.

A Solução

Adicionar a interface podman1 à zona trusted (que permite todo o tráfego):

sudo firewall-cmd --zone=trusted --add-interface=podman1 --permanent
sudo firewall-cmd --reload

success
success

O parâmetro --permanent é essencial aqui. Sem ele, a regra seria perdida no próximo reboot e voltaríamos à estaca zero.

Verificando a Correção

Testei a conectividade novamente:

podman exec fogonacaixadagua nc -zv host.docker.internal 3306

host.docker.internal (10.89.0.1:3306) open

E o site:

curl -sL -o /dev/null -w '%{http_code}' https://fogonacaixadagua.com.br/

200

Funcionando!

Por Que Isso Acontece?

Quando o servidor reinicia, o firewalld carrega suas configurações antes do Podman criar suas interfaces de rede. Interfaces virtuais como podman1 são criadas dinamicamente pelo Podman, e o firewalld não as associa automaticamente a nenhuma zona.

Sem estar em uma zona permissiva, todo o tráfego originado do container para o host é bloqueado – incluindo a conexão com o MariaDB.

Alternativas à Zona Trusted

Se você não quer colocar a interface na zona trusted (que permite todo o tráfego), pode criar uma zona específica ou adicionar regras mais granulares:

# Criar zona específica para containers
sudo firewall-cmd --permanent --new-zone=containers
sudo firewall-cmd --permanent --zone=containers --add-service=mysql
sudo firewall-cmd --permanent --zone=containers --add-interface=podman1
sudo firewall-cmd --reload

Ou adicionar apenas a porta necessária na zona padrão:

sudo firewall-cmd --permanent --zone=FedoraServer --add-rich-rule='rule family="ipv4" source address="10.89.0.0/24" port port="3306" protocol="tcp" accept'
sudo firewall-cmd --reload

Resumo

Sintoma

“Error establishing a database connection” após reboot

Causa

Interface podman1 não associada a zona do firewall

Solução

firewall-cmd --zone=trusted --add-interface=podman1 --permanent

Comandos Úteis para Diagnóstico

# Verificar status do container
sudo podman ps -a

# Ver logs do container
sudo podman logs <container_name> --tail 50

# Testar resolução de hostname dentro do container
sudo podman exec <container_name> getent hosts host.docker.internal

# Testar conectividade de porta
sudo podman exec <container_name> nc -zv host.docker.internal 3306

# Listar zonas e interfaces do firewall
sudo firewall-cmd --get-active-zones

# Ver configuração completa de uma zona
sudo firewall-cmd --zone=<zone_name> --list-all

Espero que esse post te ajude a resolver esse problema rapidamente. É uma daquelas situações onde tudo parece estar funcionando, mas um detalhe de configuração de rede acaba quebrando tudo.

Se você passou por algo parecido ou tem dúvidas, deixa um comentário!