Problema

En entornos de Proxmox donde se ejecutan contenedores OCI dentro de LXC, el almacenamiento interno del contenedor desaparece al reiniciarlo o al migrarlo. Cuando la aplicación necesita guardar datos de forma permanente (logs, bases SQLite, configuraciones), el único recurso fiable es un directorio externo compartido mediante NFS o SMB. El reto consiste en exponer ese recurso al contenedor OCI sin perder la capacidad de gestión propia de LXC (snapshots, migraciones) y sin romper la ruta esperada por la imagen OCI.

Causa

  1. Aislamiento de LXC: por defecto, LXC crea un rootfs propio y no incluye volúmenes externos.
  2. OCI espera una ruta fija: la mayoría de imágenes OCI buscan su directorio de datos en /data o /var/lib/app. Si el bind‑mount apunta a otro punto, la aplicación falla al iniciar.
  3. Configuración incompleta del host: montar NFS/SMB en el nodo Proxmox sin declararlo en el archivo de configuración del contenedor deja el punto de montaje invisible para el contenedor.
  4. Permisos y UID/GID: NFS/SMB pueden mapear usuarios de forma diferente a la que usa el contenedor, provocando errores de escritura.

Solución

1. Preparar el recurso compartido en el host

  • NFS: exporta el directorio con *(rw,sync,no_subtree_check) o restringe a la IP del nodo.
  • SMB: crea un share con permisos de escritura para el usuario que usará el contenedor (normalmente root dentro del LXC).

2. Montar el share en el nodo Proxmox

Utiliza /etc/fstab para que el montaje sea persistente y se realice antes de que Proxmox inicie los contenedores.

# NFS (ejemplo)
192.168.1.10:/export/oci-data /mnt/oci-data nfs defaults,_netdev,auto 0 0

# SMB (ejemplo)
//192.168.1.20/oci-data /mnt/oci-data cifs credentials=/root/.smbcreds,iocharset=utf8,vers=3.0 0 0

Crea el archivo de credenciales para SMB:

cat > /root/.smbcreds <<EOF
username=proxmox
password=SuperSecreto
domain=WORKGROUP
EOF
chmod 600 /root/.smbcreds

Ejecuta mount -a y verifica con df -h que el punto está activo.

3. Añadir el bind‑mount al contenedor LXC

Edita el archivo de configuración del contenedor (/etc/pve/lxc/<CTID>.conf). Añade una línea mp0 (o mpX si ya existen) que apunte al directorio montado y lo re‑mapee a la ruta esperada por la imagen OCI.

mp0: /mnt/oci-data,mp=/data,backup=0
  • mp define la ruta dentro del contenedor.
  • backup=0 evita que Proxmox copie datos externos durante snapshots (opcional).

Si la imagen OCI usa otra ruta, ajusta mp= en consecuencia.

4. Alinear UID/GID

Para evitar problemas de permisos, sincroniza los IDs entre el host y el contenedor. La forma más sencilla es ejecutar el contenedor como root (UID 0) y montar el share con la opción uid=0,gid=0 en NFS o file_mode=0775,dir_mode=0775 en SMB. Si prefieres usuarios no privilegiados, crea el mismo UID/GID en el host y en el contenedor y agrega esas opciones al montaje.

5. Lanzar la imagen OCI dentro del LXC

Con Proxmox 9 y el soporte OCI, crea el contenedor usando pct create <CTID> local:vztmpl/oci-image.tar.gz. El contenedor ya verá /data como un directorio persistente gracias al bind‑mount. No necesitas modificar la propia imagen OCI.

Cuándo aplicar esta solución

  • Escenarios típicos: monitor de red, bases SQLite, aplicaciones que guardan logs o configuraciones pequeñas y que se ejecutan dentro de contenedores OCI en Proxmox.
  • Síntomas: datos desaparecen tras reinicio, errores de “cannot write to /data”, snapshots que no incluyen los archivos externos.
  • No aplicar: cuando la carga de trabajo requiere alto rendimiento de I/O (NFS/SMB pueden ser cuellos de botella) o cuando la aplicación necesita bloques de disco en vez de un directorio (en ese caso usar LVM o ZFS).

Código

# 1. Añadir export NFS en el servidor
# /etc/exports
/export/oci-data *(rw,sync,no_subtree_check)

# 2. Recargar exportaciones
exportfs -ra

# 3. En el nodo Proxmox, crear punto de montaje
mkdir -p /mnt/oci-data

# 4. Añadir a /etc/fstab (NFS)
192.168.1.10:/export/oci-data /mnt/oci-data nfs defaults,_netdev 0 0

# 5. Montar inmediatamente
mount -a

# 6. Editar configuración del contenedor (CTID=105)
nano /etc/pve/lxc/105.conf
# Añadir línea:
mp0: /mnt/oci-data,mp=/data,backup=0

# 7. Reiniciar contenedor para aplicar cambios
pct restart 105

Verificación

  1. Comprobar montaje en el host
    mountpoint /mnt/oci-data && df -h /mnt/oci-data
    Debe mostrar el share NFS/SMB activo.

  2. Entrar al contenedor
    pct enter 105
    Listar /data. Debería existir y contener los archivos del host.

  3. Crear archivo de prueba
    Dentro del contenedor: echo test > /data/prueba.txt
    Salir y en el host: cat /mnt/oci-data/prueba.txt
    El contenido debe coincidir.

  4. Reiniciar contenedor
    pct restart 105 y repetir el paso 2. El archivo sigue allí.

  5. Snapshot opcional
    vzdump 105 --dumpdir /backup
    Verifica que el snapshot no incluye /mnt/oci-data (si backup=0 está activo).

Notas adicionales

  • Latencia: NFS funciona bien en LAN con <1 ms de latencia. SMB puede ser más tolerante a firewalls, pero revisa la versión (vers=3.0 o superior) para evitar caídas de rendimiento.
  • Seguridad: evita exportar a * en entornos productivos; usa subredes o listas de control de acceso.
  • Snapshots: si necesitas que los datos externos formen parte de un backup completo, elimina backup=0 y usa una solución de backup a nivel de share (por ejemplo, rsync o snapshots de ZFS en el servidor NFS).
  • Migraciones: al mover el contenedor a otro nodo, asegúrate de que el mismo NFS/SMB esté montado en la ruta idéntica; de lo contrario, el contenedor fallará al arrancar.
  • SELinux/AppArmor: en hosts con políticas restrictivas, añade la etiqueta adecuada (:z o :Z en Docker, equivalente en LXC) para que el contenedor pueda acceder al punto de montaje.

Con estos pasos, cualquier contenedor OCI ejecutado dentro de LXC en Proxmox dispone de un directorio persistente, reutilizable y fácil de respaldar, sin sacrificar la agilidad que ofrece la virtualización ligera.