Skip to main content

Istalación istancia adicional Nextcloud (Debian 13, Nginx, PHP-FPM)

Contexto

Instalación de una segunda instancia de Nextcloud (micasanc) en un servidor Debian 13 ya en producción, donde existe una instancia funcional (nube42). Objetivo: instancia aislada, pool PHP propio, datos en disco externo, base de datos independiente, preparada para uso profesional.

La instalación acabó funcionando correctamente, pero el proceso fue innecesariamente largo por varios factores que conviene documentar para evitar repetir errores.

Estado final (correcto)

  • Servidor web: Nginx
  • PHP: PHP 8.4 con pool dedicado (micasa)
  • Base de datos: MariaDB / MySQL
  • Usuario sistema: micasa
  • Grupo web: www-data
  • Directorio web: /var/www/micasanc
  • Directorio datos: /media/ext/micasanc
  • Cron: sistema (cada 5 minutos)
  • Correo: Mailgun (dominio taller42.org)
  • Redis: TCP (127.0.0.1:6379)
  • Instalación web: completada correctamente
  • Estado Nextcloud: operativo y estable

Errores clave cometidos (y lecciones)

1. Diagnóstico sin “estado real”

Se empezó a tocar configuración sin fijar primero el estado exacto del sistema:

  • Permisos reales
  • Usuario efectivo de PHP-FPM
  • Rutas reales usadas por PHP
  • Configuración efectiva (phpinfo())

Lección: antes de tocar nada, confirmar siempre: sudo -u <user> php -r "phpinfo();"

2. Mezcla innecesaria de pools y permisos

El problema principal no era Nextcloud, ni SSL, ni Nginx, ni Redis: era un conflicto de permisos entre www-data y micasa.

Errores derivados:

  • Internal Server Error
  • session_start(): failed to read session data
  • bucles de redirección
  • FastCGI permission denied

Lección:

  • Pool dedicado implica coherencia total de permisos
  • Grupo web consistente (www-data)
  • Nada de parches parciales

3. session.save_path no efectivo

Aunque el pool tenía: php_admin_value[session.save_path] = /media/ext/micasanc/sessions

PHP seguía usando /var/lib/php/sessions.

Detectado solo tras: sudo -u micasa php -r "phpinfo();" | grep session.save_path

Lección: confirmar siempre la configuración cargada, no la escrita.

4. Redis: módulo sí, configuración no

El módulo estaba cargado y Redis funcionaba, pero fallaba al activar toda la configuración en Nextcloud.

Solución:

  • Probar Redis desde PHP con el mismo usuario del pool
  • Confirmar conectividad antes de activar locking

en el config.php hay que estar atento en no solapara database, ejemplo correcto de configuración:

'redis' =>
  array (
    'host' => '127.0.0.1',
    'port' => 6379,
    'password' => 'PASSWORD_REDIS_AQUI',
    'timeout' => 1.5,
    'dbindex' => 1,
  ),

El 'dbindex' varia segun el entorno (0, 1, 2, etc.)

Prueba válida:

sudo -u micasa php -r '
$r=new Redis();
$r->connect("127.0.0.1",6379);
$r->auth("PASSWORD");
$r->ping();
echo "OK\n";
'

5. Logs mal ubicados

Ruta correcta del log: /media/ext/micasanc/nextcloud.log

No: /media/ext/micasanc/data/nextcloud.log

Lección: verificar rutas reales antes de operar.

6. Cron

Línea funcional:

*/5 * * * * php -f /var/www/micasanc/occ background:cron >> /var/www/micasanc/cron.log 2>&1

Resultado: Nextcloud detecta cron correctamente.

Configuración clave innegociable

Prefijo de tablas

dbtableprefix = ncmc_

Decisión explícita.

Redis

Usado vía TCP, no socket.

Resultado final

Sistema estable, sin errores activos, cron y Redis funcionando, correo operativo y permisos coherentes.

El 90% del problema fue latencia y ausencia de diagnóstico inicial limpio.

Próximo paso

  • Probar instalación en Debian 13 limpio
  • Validar reproducibilidad
  • Preparar servicio profesional
Back to top