Roundcube no cPanel quebrando com DB Error [14] unable to open database file

Roundcube no cPanel quebrando com “DB Error: [14] unable to open database file” — Diagnóstico Técnico e Correção Definitiva

Em incidente recente em servidor cPanel, o webmail na porta :2096 passou a exibir:

Oops... something went wrong!
An internal error has occurred. Your request cannot be processed at this time.

No log, a causa real:

DB Error: [14] unable to open database file
(SQL Query: INSERT INTO "session" ...)
in /usr/local/cpanel/base/3rdparty/roundcube/program/lib/Roundcube/rcube_db.php

O ponto-chave é simples: o Roundcube até sobe, mas falha no momento de gravar sessão. Isso quase sempre significa problema de escrita no SQLite e não “bug aleatório do webmail”.

---

1) O que o erro 14 significa no contexto real

No SQLite, código [14] = SQLITE_CANTOPEN. No Roundcube/cPanel, se a falha ocorre no INSERT INTO session, o problema costuma estar em:

• arquivo .rcube.db inacessível;
• diretório sem permissão para criar arquivo temporário/journal;
• disco sem inode livre;
• filesystem montado como somente leitura (ro).

Ou seja: não basta “ler” o banco, precisa escrever no mesmo contexto de diretório.

---

2) Primeira linha de investigação: conta e banco .rcube.db

Cada conta de e-mail usa SQLite individual:

/home/USER/etc/domain.com/email@domain.com.rcube.db

2.1 Validar estrutura da conta

ls -lah /home/USER/etc/domain.com/

2.2 Corrigir ownership e permissões

chown -R USER:mail /home/USER/etc
chmod 750 /home/USER/etc
chmod 640 /home/USER/etc/domain.com/*.db

Esse é o baseline que mais resolve incidente real em produção sem quebrar isolamento.

2.3 Suspeita de corrupção do banco da conta

Não delete direto. Preserve evidência e permita recriação limpa:

mv /home/USER/etc/domain.com/email@domain.com.rcube.db \
   /home/USER/etc/domain.com/email@domain.com.rcube.db.bak

No próximo login, o Roundcube recria o banco da interface. Importante: isso afeta preferências/sessões, não apaga mensagem de e-mail da Maildir.

---

3) CloudLinux/CageFS: camada que costuma mascarar o problema

Com CloudLinux ativo, permissões podem parecer corretas no host, mas o usuário enjaulado não conseguir escrita no contexto esperado.

Rebuild operacional:

cagefsctl --remount USER
cagefsctl --force-update

Quando erro some após remount/update, a causa raiz estava no ambiente virtualizado do usuário e não no Roundcube em si.

---

4) Segunda linha: saúde de /tmp e recursos de escrita

Roundcube/PHP/SQLite dependem de arquivos temporários.

4.1 Permissão correta de /tmp

ls -ld /tmp

Esperado:

drwxrwxrwt root root

O t (sticky bit) é obrigatório nesse fluxo multiusuário.

4.2 Espaço e inode

df -h /tmp
df -i /tmp

Incidente clássico: “tem espaço em GB, mas inode zerado”. Sem inode, SQLite não cria lock/journal e explode com erro 14.

---

5) Terceira linha: integridade do filesystem

Se partição for remontada em ro, qualquer app que precise escrita começa a quebrar em cascata.

mount | grep -E ' / | /home | /tmp '

Se houver ro, pare troubleshooting de aplicação e trate storage/filesystem primeiro.

---

6) SELinux: bloqueio silencioso em stack RHEL-like

Ambientes AlmaLinux/Rocky/RHEL com SELinux Enforcing podem bloquear escrita no path da conta.

getenforce

Teste rápido (somente diagnóstico):

setenforce 0

Se resolver, normalize contexto:

restorecon -Rv /home/USER/etc

Depois retorne para Enforcing e valide novamente.

---

7) Último recurso: reparo de pacote/binário

Se infraestrutura está íntegra e só Roundcube segue quebrando:

/scripts/check_cpanel_rpms --fix

ou:

dnf reinstall cpanel-roundcube

Use como etapa final, não como primeira reação. Reinstalar pacote sem validar I/O só mascara causa raiz.

---

8) Checklist executivo de resposta rápida

1. df -h, df -i, repquota para eliminar falta de recurso.
2. ownership/permissão de /home/USER/etc e .rcube.db.
3. estado de /tmp (1777 + sticky bit + inode livre).
4. mount para confirmar rw.
5. cagefsctl --remount/--force-update em CloudLinux.
6. validação de SELinux e restorecon se necessário.
7. só então considerar rebuild/reinstall do Roundcube.

---

Conclusão

DB Error: [14] no Roundcube quase nunca é “defeito do webmail”. É sintoma de escrita negada em alguma camada da infraestrutura.

Quando você trata por ordem de camada (conta -> temp -> FS -> segurança -> pacote), o MTTR cai de horas para minutos e evita restart cego em produção.

Este post está licenciado sob CC BY-NC.