Solución de problemas

Solución de problemas

Lista de fallos típicos con su causa real y su comando para arreglarlo. Si no encuentras el tuyo, abre un issue o escribe a soporte@enterprisechat.es con la salida de:

sudo journalctl -u enterprisechat -n 100 --no-pager

(o equivalente Windows: Get-Content 'C:\Program Files\EnterpriseChat\logs\server-*.log' -Tail 100).

---

Instalación

install.sh: dpkg-deb: error: requested operation requires superuser privilege

Estás ejecutando el script sin sudo.

curl -fsSL https://enterprisechat.es/install.sh | sudo bash

SHA-256 NO COINCIDE

El servidor de descarga no devolvió el binario esperado. Reintenta; si persiste, es CDN caché obsoleto. Espera unos minutos.

Si siempre falla con el mismo hash distinto, posible compromiso. Verifica el SHA-256 manualmente contra releases de GitHub y avisa.

Falta el módulo Apache 'proxy_wstunnel'

Solo aplica a la extensión Plesk con tab Dominios:

sudo a2enmod proxy_wstunnel
sudo systemctl reload apache2

Después, vuelve al panel Plesk y reintenta el bind.

---

Servicio no arranca

Linux: systemctl status enterprisechat muestra "failed"

sudo journalctl -u enterprisechat -n 100 --no-pager

Causas más típicas:

• Address already in use :::5080 → otro proceso ocupa 5080.

  sudo ss -tlnp | grep 5080

  Mata el proceso o cambia el puerto del chat en appsettings.Production.json → Kestrel.Endpoints.Http.Url.

• SqliteException: database is locked → otro proceso del chat sigue corriendo. sudo systemctl stop enterprisechat, ps aux | grep EnterpriseChat, mata residuos, vuelve a arrancar.

• JWT SigningKey must be at least 32 chars → el appsettings.Production.json está corrupto o le falta esa clave. Restaura el backup o regenera la clave:

  sudo openssl rand -base64 48 | tr -d '\n' > /tmp/k
  # Edita appsettings.Production.json y pega el contenido de /tmp/k en
  # "EnterpriseChat":"Jwt":"SigningKey".

Windows: el servicio se para inmediatamente

Get-EventLog -LogName Application -Source EnterpriseChat -Newest 20

Mismos sospechosos que en Linux: puerto en uso, DB bloqueada, configuración corrupta. Edita C:\Program Files\EnterpriseChat\appsettings.Production.json con cuidado y reinicia.

---

No puedo iniciar sesión como admin

• "Credenciales inválidas": la contraseña inicial solo se mostraba una vez al instalar. Si la perdiste, reséla:

  # Linux
  sudo -u enterprisechat /opt/enterprisechat/EnterpriseChat.Server \
      --reset-admin-password "NuevaContraseña123"
  
  # Windows
  cd 'C:\Program Files\EnterpriseChat'
  .\EnterpriseChat.Server.exe --reset-admin-password "NuevaContraseña123"

  Detalles en Primer acceso.

• "Tu sesión ha caducado": normal si llevas más de 60 min en la pantalla de login. Recarga la página.

---

Cliente WPF no conecta

"No se puede conectar al servidor"

1. ¿Está corriendo el servidor? systemctl status enterprisechat / Get-Service EnterpriseChat.
2. ¿La URL es correcta? Prueba desde el navegador: <URL>/healthz → debe devolver {"status":"ok"}.
3. ¿Firewall? El puerto 5080 (o el HTTPS de tu reverse proxy) debe estar abierto desde donde está el cliente.

"Reconectando…" permanente

Síntoma típico de WebSocket bloqueado:

• Reverse proxy no pasa headers Upgrade/Connection. Mira Reverse proxy y TLS sección "Cliente conectado por dominio".
• Algún antivirus/firewall corporativo bloquea WebSocket. SignalR cae automáticamente a long-polling tras unos segundos — funciona pero con más latencia.

SmartScreen bloquea el .exe del cliente

Versiones alpha pueden no estar firmadas todavía. "Más información → Ejecutar de todas formas". En v1.0+ va firmado con cert EV y SmartScreen deja pasar.

---

Licencias

"edition": "Free" con cap 5 tras pegar clave Free registrada

• La clave no se guardó (revisa appsettings.Production.json).
• El servidor no la ha leído (¿reiniciaste el servicio?).
• La clave es de otra organización / revocada. Mira logs:

  sudo journalctl -u enterprisechat | grep -i licens

"License validation failed: timeout"

El servidor no tiene salida HTTPS a enterprisechat.es. Comprueba:

curl -fsSI https://enterprisechat.es/health

Si no responde: revisa firewall outbound, DNS, proxy corporativo.

Si tu red nunca podrá tener salida a internet, plan Enterprise con clave offline firmada — ver Comprar licencia Pro.

"Licencia caducada" tras renovar Pro

La clave se valida cada 30 min. Tras pegar una clave nueva, el cambio puede tardar hasta 30 min en propagarse. Para forzar la revalidación inmediata:

• Extensión Plesk: tab Estado → Refrescar licencia.
• Manual: systemctl restart enterprisechat (o Restart-Service EnterpriseChat).

---

Reverse proxy / dominio

502 Bad Gateway en https://chat.tuempresa.com

El reverse proxy no llega al backend:

curl -I http://127.0.0.1:5080/healthz

Si NO responde: el servicio está caído. Arranca.

Si responde 200: el reverse proxy está mal configurado. Revisa el bloque ProxyPass / proxy_pass de tu vhost.

Página genérica de Plesk en vez del chat

Tu reverse proxy nunca se aplicó. En Plesk:

plesk sbin httpdmng --reconfigure-domain chat.tuempresa.com

Y verifica:

apachectl -t        # o nginx -t si usas nginx

nginx: [emerg] duplicate location "/"

Tu config nginx declara dos location /. El de Plesk + el tuyo. Usa regex en el tuyo:

location ~ "^/" {
    proxy_pass http://127.0.0.1:5080;
    # ...
}

→ Reverse proxy y TLS sección B.

---

Backup / restauración

Tras restaurar, los tokens de los clientes ya no valen

La clave JWT (Jwt.SigningKey) del backup no coincide con la actual. Soluciones:

• Restaura también appsettings.Production.json del backup (recomendado).
• O fuerza a todos los clientes a re-login (sus sesiones se invalidan).

sqlite3: command not found al hacer backup

sudo apt-get install -y sqlite3       # Debian/Ubuntu
sudo dnf install -y sqlite            # Alma/Rocky

---

Nada de lo anterior aplica

Recopila:

sudo journalctl -u enterprisechat -n 200 --no-pager > /tmp/chat-logs.txt
cat /opt/enterprisechat/appsettings.Production.json | grep -v SigningKey > /tmp/chat-config.txt
curl -s http://127.0.0.1:5080/license > /tmp/chat-license.txt

Abre un issue con esos 3 ficheros adjuntos.