Lxc-Containers

Problema En entornos de self‑hosting es frecuente combinar varios repositorios de respaldo (NAS, servidores remotos, contenedores LXC) y usar la opción mirror de Zerobyte para mantener copias idénticas. Cuando se configura un backup scheduler que escribe en un repositorio SFTP y, a la vez, se intenta replicar ese mismo backup a otro repositorio SFTP con credenciales distintas, Zerobyte muestra el mensaje: Both use SFTP backends with different credentials. Consider creating a new backup scheduler with the desired destination instead. El síntoma impide que la cadena de espejo (mirror) funcione y obliga a recurrir a soluciones ad‑hoc como bind mounts o copias manuales. El problema no es exclusivo de una instalación concreta; ocurre siempre que Zerobyte intenta enlazar dos destinos SFTP bajo el mismo scheduler. ...

Problema En entornos de Proxmox VE es frecuente clonar el nodo o migrar los volúmenes a un nuevo disco para renovar hardware o redistribuir capacidad. Después de la operación, varios usuarios descubren que sus LXC containers no arrancan. Los logs suelen mostrar errores al montar los volúmenes de Local‑LVM, como “mount: unknown filesystem type 'ext4'” o “Failed to activate logical volume”. El síntoma típico es: pct start 101 lxc-start: failed to mount /dev/pve/vm-101-disk-0 Este patrón no está limitado a una versión concreta de Proxmox; ocurre siempre que la capa de almacenamiento (LVM) pierde la correspondencia entre los UUID de los volúmenes y la configuración guardada en /etc/pve/lxc/. El contenedor queda “atascado” porque el hipervisor no encuentra el dispositivo esperado. ...

Problema Muchos usuarios que autohospedan Navidrome quieren evitar la gestión de credenciales locales y delegar la autenticación a un proveedor externo (por ejemplo, Authentik). El reto surge cuando el reverse proxy no está configurado para reenviar la información de sesión o cuando el flujo OAuth2 no se completa porque falta un contenedor de “auth‑proxy”. El síntoma típico es que Navidrome muestra la página de login pero nunca redirige al usuario, o que la cabecera X-User esperada por Navidrome está vacía. ...

Problema En entornos de homelab o producción ligera es frecuente ejecutar servicios (DNS, VPN, monitoreo) dentro de contenedores LXC gestionados por Proxmox. Un patrón recurrente es que, tras semanas o meses de operación, el contenedor comienza a fallar: los procesos se reinician, los logs muestran “no space left on device” y, como consecuencia, la red deja de responder. El síntoma visible suele ser una pérdida de conectividad DNS o una caída del propio servicio, aunque el host sigue funcionando. ...

Problema En entornos domésticos o de pequeña oficina es frecuente delegar la resolución de nombres internos a un Pi‑hole instalado en un contenedor LXC. El objetivo es que cualquier dispositivo que consulte DNS obtenga tanto la filtración de publicidad como los registros locales (por ejemplo test.lan). Cuando los dispositivos siguen enviando consultas al router y el router reenvía a un servidor externo (Cloudflare, Google), los nombres internos no se resuelven y el navegador muestra “server IP address could not be found”. El síntoma típico es: ...

Problema En entornos donde Proxmox hospeda un NAS basado en ZFS y expone los datasets mediante NFS o SMB, es frecuente mover la capa de servicios (SMB/NFS) a un contenedor LXC. El contenedor utiliza bind‑mounts o mp0 para acceder a los datasets del host. El reto surge al intentar respaldar tanto la configuración del LXC como los datos reales que residen fuera del rootfs del contenedor. Un backup que solo incluye el contenedor deja los volúmenes montados sin protección; incluirlos dentro del contenedor inflaría el tamaño del backup y complicaría la restauración. ...

Problema En muchos homelabs el hipervisor y el sistema operativo base son piezas separadas que requieren mantenimiento manual: actualizaciones de kernel, configuración de Secure Boot, cifrado de disco y gestión de paquetes. Esa complejidad genera dos patrones de falla recurrentes. Primero, la exposición accidental de datos por configuraciones de seguridad incompletas (TPM sin LUKS, Secure Boot desactivado). Segundo, la pérdida de disponibilidad tras una actualización del host que rompe módulos críticos (por ejemplo, ZFS o drivers) y no hay forma rápida de volver al estado anterior. Cuando se añaden más de veinte servicios, la probabilidad de que alguna de esas piezas falle aumenta exponencialmente, y el tiempo dedicado a “mantener el host” compite con el tiempo dedicado a los propios servicios. ...