Lo estás montando mal: el error de NFS que rompe homelabs
La confusión: “¿por qué mi VM no puede ver mi almacenamiento sin más?”
Empieza de forma bastante sencilla. Tienes una VM de Proxmox con poco almacenamiento, quizá 100GB, y un NAS en perfecto estado ahí al lado con terabytes libres. El objetivo parece obvio: conectar las dos cosas y seguir adelante.
Y entonces te das contra el muro. ¿Dónde está la ruta? ¿Hay que particionar más espacio? ¿Redimensionar discos cada vez? De repente algo que debería ser enchufar y listo se convierte en un laberinto de montajes, permisos y consejos contradictorios.
Ese es el primer error: dar por hecho que NFS funciona como el almacenamiento local. No es así. Con NFS, el trabajo consiste en exponer bien el almacenamiento, no en redimensionar discos.
La primera división: VM o LXC (y por qué importa más de lo que crees)
Casi de inmediato, la conversación se divide en dos bandos según uses una VM o un LXC, porque la respuesta lo cambia todo.
Para las VMs, el consejo es refrescantemente aburrido: monta el recurso compartido NFS dentro de la VM con /etc/fstab y listo. Un comentarista lo dijo sin rodeos: “En una VM lo haces con fstab… y luego mount -a.”
Los LXC son donde la cosa se pone rara. Ahora tienes que lidiar con las fronteras del contenedor, los puntos de montaje y el mapeo de permisos. La pregunta crece de “conectar el almacenamiento” a “¿cómo paso el almacenamiento de forma segura a través de capas de abstracción?”, y ahí es donde la mayoría de los montajes empiezan a desmoronarse.
El enfoque limpio: montar en el host y pasarlo hacia abajo
Una de las recomendaciones más repetidas corta por lo sano: no montes NFS dentro del contenedor. Móntalo en el host Proxmox y después pásalo al LXC. Parece trabajo extra, pero lo simplifica todo.
Un usuario lo explicó paso a paso: monta el recurso del NAS en algo como /mnt/proxmox_nfs en el host y luego añade un punto de montaje en la configuración del LXC para que el contenedor pueda acceder a él.
Este enfoque consigue dos cosas:
- Mantiene centralizada la lógica de red y de almacenamiento
- Evita problemas raros de permisos en el contenedor
No es vistoso, pero funciona de forma constante, y en un homelab la constancia suele ganar a la astucia.
La pesadilla de los permisos: “¿por qué Plex lo ve y nada más lo ve?”
Aquí es donde las cosas se rompen de verdad. Montas el recurso, aparece y Plex puede leerlo. Tus otras aplicaciones no reciben nada: ni acceso ni errores, solo silencio.
Eso se debe a los permisos de usuario dentro de los contenedores. Un comentario frustrado lo resumió a la perfección: un LXC puede acceder al NAS, pero otros “usan un usuario root que no puede acceder”, incluso con bind mounts.
Esto nadie te lo cuenta de entrada: montar es fácil, y lo difícil son los permisos. Estás lidiando con discrepancias de UID/GID entre:
- El NAS
- El host Proxmox
- Los usuarios del contenedor
Si no cuadran, el acceso se rompe aunque todo parezca correcto.
El debate de seguridad: contenedores privilegiados o no privilegiados
Luego llega la discusión que nunca se resuelve del todo.
Hay quien dice que uses contenedores privilegiados sin más, porque son más fáciles, hay menos fricción y todo funciona. Otros responden con dureza: “Un LXC privilegiado es una idea terrible.” Y no les falta razón.
Los contenedores privilegiados difuminan la frontera de aislamiento. Facilitan el montaje, pero a costa de la seguridad. Los contenedores no privilegiados, en cambio, son más seguros pero requieren más configuración, sobre todo en torno a los permisos.
Un usuario defiende con fuerza los LXC no privilegiados y sostiene que son “seguros a tope” si se configuran bien y que evitan los quebraderos de cabeza de las VMs para cosas como compartir la GPU.
Así que vuelves a elegir, esta vez entre comodidad y aislamiento.
La división de arquitectura: un contenedor o muchos
Justo cuando crees que lo tienes resuelto, aparece otro debate: ¿lo ejecutas todo en un contenedor o repartes los servicios entre varios LXC?
Algunos defienden la separación, con un contenedor por aplicación, que es más limpio, más seguro y más fácil de gestionar a largo plazo. Otros prefieren agrupar servicios para simplificar la red y la configuración de la VPN.
Una opinión lo resume bien: los contenedores separados son más fáciles en general, pero combinarlos puede tener sentido según tu forma de trabajar. No hay una única respuesta correcta, solo compromisos.
Baño de realidad: NFS no es la parte difícil
NFS en sí es sencillo. Defines un recurso compartido, lo montas y listo. Como señaló un comentarista, básicamente es:
IP:/path/to/share → /mnt/path
La complejidad viene de todo lo que lo rodea:
- Dónde lo montas (host, VM o LXC)
- Cómo lo expones (bind mounts, archivos de configuración)
- Quién puede acceder (permisos, mapeo de usuarios)
Por eso parece más difícil de lo que debería. Montar el almacenamiento es lo fácil; integrar los sistemas que lo rodean es el trabajo de verdad.
La conclusión: deja de pelearte con la capa equivocada
Si hay una lección aquí, es que la mayoría de la gente se atasca con NFS porque está resolviendo el problema equivocado. Intenta:
- Redimensionar discos de VM en lugar de usar almacenamiento en red
- Montar directamente dentro de los contenedores en lugar de usar el host
- Ignorar los permisos hasta que todo se rompe
El camino más fluido casi siempre es:
- Montar NFS en el host Proxmox
- Pasarlo a los LXC con puntos de montaje
- Arreglar bien los permisos
No es la ruta más rápida, pero no te va a morder más adelante. En un homelab, esa es la diferencia entre algo que funciona hoy y algo que sigue funcionando el mes que viene.