Mirrors/ProxMenux
1
0
Fork 0
mirror of https://github.com/MacRimi/ProxMenux.git synced 2026-06-14 12:27:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

complete i18n migration to /[locale]/ with EN+ES content

Browse Source 
Full rewrite of the docs site under app/[locale]/ with next-intl
in localePrefix:"always" mode. Every page now exists at both
/en/<path> and /es/<path>; the root / shows a meta-refresh + JS
redirect to /<defaultLocale>/ so GitHub Pages serves something
on the apex URL.

Highlights:
- 107 doc pages migrated to file-per-page JSON namespaces under
  messages/en/ and messages/es/. Spanish content is fully
  translated (no copy-of-English placeholders).
- New documentation for the Active Suppressions section in the
  Settings tab and the per-event Dismiss dropdown in the Health
  Monitor modal.
- New screenshots: dismiss-duration-dropdown.png and an updated
  health-suppression-settings.png.
- Pagefind integrated for client-side search; index is built on
  every CI deploy (not committed).
- RSS feeds: per-locale at /<locale>/rss.xml plus root /rss.xml
  for backward compat.
- Removed the dead app/[locale]/guides/[slug]/ route — every
  guide now has its own static page and no markdown source
  remains.
- Fixed orphan link /guides/nvidia -> /guides/nvidia-manual in
  docs/hardware/nvidia-host.
- Removed obsolete components (footer2, calendar, drawer).

Verified locally with `npm ci && npm run build`: 2804 files in
out/, 231 pages indexed by pagefind, root redirect intact, both
locale roots and the new Active Suppressions docs render OK.
This commit is contained in:
MacRimi
2026-05-31 12:41:10 +02:00
parent 875910b4d7
commit 5ca3463bf6
649 changed files with 83958 additions and 11096 deletions
Download Patch File Download Diff File Expand all files Collapse all files

123
web/messages/es/docs/storage-share/host-iscsi.json Normal file
View File

@@ -0,0 +1,123 @@
{
"meta": {
"title": "Host: añadir target iSCSI como almacenamiento de Proxmox | ProxMenux Documentation",
"description": "Registra un target iSCSI como almacenamiento de Proxmox usando ProxMenux. Gestiona la instalación de open-iscsi, el descubrimiento del portal vía sendtargets, la selección del target y pvesm add iscsi. Proporciona dispositivos de bloque raw para imágenes de disco de VM.",
"ogTitle": "Host: añadir target iSCSI como almacenamiento de Proxmox | ProxMenux Documentation",
"ogDescription": "Registra un target iSCSI como almacenamiento de Proxmox con descubrimiento guiado. Usa pvesm add iscsi y proporciona dispositivos de bloque raw para discos de VM."
},
"header": {
"title": "Host: añadir target iSCSI como almacenamiento de Proxmox",
"description": "Registra un target iSCSI (de una SAN, TrueNAS / FreeNAS, Synology, un target Windows Server, cualquier array que hable iSCSI) como almacenamiento de Proxmox. Las LUNs exportadas aparecen como dispositivos de bloque y pueden alojar imágenes de disco de VM con un rendimiento cercano al local sobre la red.",
"section": "Almacenamiento y compartición · Host"
},
"intro": {
"title": "Qué hace",
"body": "ProxMenux envuelve <code>pvesm add iscsi</code> en un flujo guiado: instala <code>open-iscsi</code> si hace falta, pide el portal iSCSI (IP:puerto), ejecuta <code>iscsiadm --mode discovery --type sendtargets</code> contra él, te deja elegir un IQN de target y registra el almacenamiento iSCSI en Proxmox. El servicio <code>iscsid</code> mantiene después la sesión iSCSI viva entre reinicios."
},
"vocab": {
"heading": "Vocabulario iSCSI (referencia rápida)",
"headerTerm": "Término",
"headerMeaning": "Significado",
"rows": [
{
"term": "Portal",
"meaningRich": "El endpoint del servicio iSCSI en el servidor del target — una IP (o hostname) más un puerto TCP. El puerto por defecto es <code>3260</code>; ProxMenux lo asume si no especificas uno."
},
{
"term": "Target",
"meaningRich": "Un único \"servidor\" exportado dentro del portal, identificado por su IQN (<em>iSCSI Qualified Name</em>). Un portal puede alojar muchos targets."
},
{
"term": "IQN",
"meaningRich": "La forma canónica es <code>iqn.YYYY-MM.reverse.domain:identifier</code>, por ejemplo <code>iqn.2024-08.com.truenas:proxmox-pool</code>. Tanto el target como el initiator tienen su propio IQN."
},
{
"term": "LUN",
"meaningRich": "Un dispositivo de bloque dentro de un target (Logical Unit Number). Un único target puede exponer varias LUNs; cada LUN aparece como su propio disco en Proxmox y puede convertirse en un disco de VM."
},
{
"term": "Initiator",
"meaningRich": "El cliente que conecta a un target — en este caso, tu host Proxmox. El initiator tiene su propio IQN guardado en <code>/etc/iscsi/initiatorname.iscsi</code>. Los targets normalmente solo aceptan sesiones de IQNs de initiator preautorizados."
}
]
},
"opening": {
"heading": "Abrir la herramienta",
"body": "Desde el menú principal de ProxMenux, abre <strong>Storage &amp; Share Manager → Add iSCSI Target as Proxmox Storage</strong>. Verás este submenú con cuatro opciones:",
"imageAlt": "Menú iSCSI Host Manager — Add / View / Remove / Test connectivity"
},
"howRuns": {
"heading": "Cómo se ejecuta el script (flujo Add)",
"body": "El flujo tiene dos fases con una separación clara entre \"configurar el initiator, descubrir targets\" y \"registrar realmente el almacenamiento en Proxmox\". A diferencia de NFS / Samba, no hay auto-descubrimiento en la subnet — debes conocer la dirección del portal (iSCSI no es amigable con broadcast)."
},
"add": {
"heading": "Añadir target iSCSI como almacenamiento de Proxmox",
"items": [
"<strong>Entrada del portal</strong> — escribe la IP o hostname del servidor del target iSCSI. Se asume el puerto <code>3260</code> a menos que escribas <code>host:port</code>.",
"<strong>Descubrimiento de targets</strong> — ProxMenux llama a <code>iscsiadm --mode discovery --type sendtargets --portal &lt;ip:port&gt;</code>. El servidor responde con cada IQN que permite ver a este initiator. Si el descubrimiento falla, el script muestra el error exacto de <code>iscsiadm</code> y lista las causas comunes (IP incorrecta, firewall, IQN del initiator no autorizado).",
"<strong>Selección del target</strong> — si hay un solo target se selecciona automáticamente; con varios targets se muestra un menú.",
"<strong>Storage ID</strong> — por defecto es <code>iscsi-&lt;último segmento del IQN, máx. 20 caracteres&gt;</code>. Solo letras, dígitos, <code>-</code> y <code>_</code>.",
"<strong>Content type</strong> — a diferencia de NFS / Samba, el contenido iSCSI está <strong>fijado a <code>images</code></strong>. iSCSI expone dispositivos de bloque raw, no un sistema de archivos, así que Proxmox solo te deja alojar discos de VM ahí."
],
"authTitle": "Autorizar el initiator de Proxmox en el target",
"authBody1": "Antes de que el flujo Add funcione de principio a fin, el target iSCSI debe conocer tu host Proxmox. Obtén tu IQN de initiator:",
"authBody2": "Después añade ese IQN a la lista de acceso del target (en TrueNAS: <em>Sharing → Block → Initiators Groups</em>; en Synology: <em>SAN Manager → iSCSI → Target → Edit → Initiators</em>; etc.). Si el initiator no está autorizado, el descubrimiento de <code>iscsiadm</code> devuelve una lista vacía o un error de autenticación."
},
"manual": {
"heading": "Equivalente manual",
"body": "El flujo entero se traduce a estos comandos:"
},
"view": {
"heading": "Ver almacenamientos iSCSI configurados",
"body": "Lista cada entrada iSCSI en Proxmox (<code>pvesm status | awk ''$2 == \"iscsi\"''</code>) con portal, IQN del target, content type y estado en vivo."
},
"remove": {
"heading": "Eliminar almacenamiento iSCSI",
"body": "Ejecuta <code>pvesm remove &lt;storage-id&gt;</code> tras confirmar portal, target y contenido. Solo se elimina el registro en Proxmox — <strong>el propio target iSCSI no se toca</strong> y las sesiones existentes en el lado del kernel pueden persistir hasta el siguiente reinicio.",
"warnTitle": "Discos de VM existentes en este iSCSI primero",
"warnBody": "Eliminar un almacenamiento iSCSI mientras las VMs todavía tienen discos en él deja a esas VMs apuntando a un almacén desaparecido. Proxmox marcará el error, pero los datos de la LUN siguen intactos en el target — puedes volver a registrar el almacenamiento después para recuperar los discos. Aun así, mueve o haz backup de las VMs primero por seguridad."
},
"test": {
"heading": "Probar conectividad iSCSI",
"body": "Ejecuta una pasada de diagnóstico: comprueba que <code>iscsiadm</code> está instalado, imprime tu IQN de initiator, confirma que <code>iscsid</code> está corriendo, hace ping a cada portal registrado, prueba su puerto e informa de <code>pvesm status</code> más si hay una sesión iSCSI activa (<code>iscsiadm --mode session</code>). Una sesión activa más un portal alcanzable pero \"inactive\" en Proxmox normalmente significa un estado obsoleto — prueba <code>pvesm set &lt;id&gt; --disable 0</code>."
},
"troubleshoot": {
"heading": "Solución de problemas",
"portalTitle": "\"Cannot reach portal\" pero la IP del servidor responde en otra parte",
"portalBody": "El ping falló en la dirección del portal. Comprueba que estás llegando a la interfaz de la <em>red de almacenamiento</em> (iSCSI suele vivir en una VLAN / subnet separada de la red de gestión). Verifica también el DNS si escribiste un hostname.",
"discoverTitle": "\"iSCSI discovery failed\" desde iscsiadm",
"discoverIntro": "El script muestra el error exacto. Causas más comunes:",
"discoverItems": [
"IP / puerto del portal incorrectos (revisa, el valor por defecto es 3260).",
"El servicio iSCSI no está corriendo en el servidor del target.",
"El firewall bloquea el 3260 entre Proxmox y el target.",
"<strong>El IQN del initiator no está autorizado en el target.</strong> Causa más frecuente en arrays empresariales. Añade tu IQN de Proxmox a la ACL de initiators del target primero."
],
"noTargetTitle": "No se encuentran targets pero el descubrimiento tuvo éxito",
"noTargetBody": "El servidor aceptó tu initiator pero no le expone ningún target. Revisa los controles de autenticación / acceso del target — algunos arrays permiten descubrimiento a todos los IQNs pero filtran qué targets puede ver cada IQN.",
"noLunTitle": "Las LUNs no aparecen en /dev/disk/by-path tras el registro",
"noLunBody": "<code>pvesm add iscsi</code> tuvo éxito pero el kernel no ve dispositivos de bloque. Comprueba <code>iscsiadm --mode session</code> — si no hay sesión activa, inicia una manualmente con <code>iscsiadm --mode node --login</code>. Si hay sesión pero no aparecen LUNs, fuerza un rescan: <code>iscsiadm --mode session --rescan</code>. Si sigue sin haber nada, probablemente el target todavía no tiene LUNs asignadas a este IQN (configura el mapeo de LUN en el target).",
"chapTitle": "Autenticación CHAP",
"chapBody": "ProxMenux no expone los campos de usuario / contraseña CHAP en el flujo interactivo. Si tu target requiere CHAP, registra con ProxMenux primero (el descubrimiento con CHAP puede fallar, pero <code>pvesm add</code> escribirá la entrada igualmente), luego añade credenciales manualmente: <code>pvesm set &lt;id&gt; --username &lt;chap-user&gt;</code> y edita <code>/etc/iscsi/iscsid.conf</code> con la contraseña, después <code>systemctl restart iscsid</code>. Es una carencia del script actual — documentada aquí para que sepas qué hacer."
},
"related": {
"heading": "Relacionado",
"items": [
{
"href": "/docs/storage-share/host-nfs",
"label": "Share NFS como almacenamiento de Proxmox",
"tail": " — alternativa a nivel de archivo. Más sencillo de configurar, más flexible (backup / ISO / tmpl / images), ligeramente más lento para discos de VM en vivo."
},
{
"href": "/docs/storage-share/host-samba",
"label": "Samba / CIFS como almacenamiento de Proxmox",
"tail": " — otra opción a nivel de archivo; evítalo para discos de VM en vivo por la semántica de locking."
},
{
"href": "/docs/storage-share/host-local-disk",
"label": "Añadir disco local como almacenamiento de Proxmox",
"tail": " — cuando el disco es local al host Proxmox, no está en otra máquina sobre la red."
}
]
}
}

186
web/messages/es/docs/storage-share/host-local-disk.json Normal file
View File

@@ -0,0 +1,186 @@
{
"meta": {
"title": "Host: añadir disco local como almacenamiento de Proxmox | ProxMenux Documentation",
"description": "Formatea un disco local SATA / SAS / NVMe en un host Proxmox y regístralo como almacenamiento Proxmox directory o ZFS pool. Detección segura de discos, gate de confirmación para operaciones destructivas, fstab basado en UUID, creación de ZFS pool y pvesm add dir / zfspool por dentro.",
"ogTitle": "Host: añadir disco local como almacenamiento de Proxmox | ProxMenux Documentation",
"ogDescription": "Formatea un disco local y regístralo como almacenamiento Proxmox directory o ZFS pool con un flujo guiado y filtrado por seguridad."
},
"header": {
"title": "Host: añadir disco local como almacenamiento de Proxmox",
"description": "Coge un disco físico del host Proxmox, opcionalmente formatéalo (ext4 / xfs / btrfs / zfs) y regístralo como almacenamiento de Proxmox — bien como directory (pvesm add dir) o como ZFS pool (pvesm add zfspool). ProxMenux filtra la lista de discos para que no puedas elegir el disco raíz ni nada en uso, y hace explícito cada paso destructivo antes de ejecutarlo.",
"section": "Almacenamiento y compartición · Host"
},
"intro": {
"title": "Qué hace",
"body": "Otras herramientas de <em>Host</em> en esta sección tratan con almacenamiento de <strong>red</strong> (NFS / Samba / iSCSI). Esta trata con discos <strong>locales</strong> — unidades físicas conectadas a tu host Proxmox que quieres usar para discos de VM, backups, ISOs o templates. ProxMenux prepara el disco (partición + formato + montaje) y lo registra en Proxmox para que la UI pueda colocar contenido ahí."
},
"destructive": {
"title": "Herramienta destructiva para la ruta 'format'",
"body": "La ruta <em>Format</em> <strong>borra cada partición y byte del disco seleccionado</strong>. ProxMenux muestra la lista de discos con un banner de advertencia, filtra los discos ya en uso y exige una confirmación explícita antes de ejecutar cualquier <code>wipefs</code> / <code>sgdisk</code> / <code>mkfs</code>. Aun así — lee la ruta del dispositivo en voz alta dos veces antes de escribir \"yes\"."
},
"compare": {
"heading": "Directory vs ZFS pool — cuál elegir",
"headerDir": "Directory (ext4 / xfs / btrfs)",
"headerZfs": "ZFS pool",
"rows": [
{
"label": "Tipo de almacenamiento Proxmox",
"dirRich": "<code>dir</code>",
"zfsRich": "<code>zfspool</code>"
},
{
"label": "Formato de disco de VM",
"dir": "Archivo qcow2 / raw en un sistema de archivos",
"zfs": "Dataset ZFS nativo (zvol) por disco"
},
{
"label": "Snapshots",
"dir": "Snapshots qcow2; snapshots btrfs si fs=btrfs",
"zfs": "Nativos, instantáneos, copy-on-write"
},
{
"label": "Thin provisioning",
"dir": "Sí (qcow2 por defecto)",
"zfs": "Sí (ZFS por defecto)"
},
{
"label": "Necesidades de RAM",
"dir": "Bajas",
"zfs": "Altas — ZFS usa la RAM libre como caché ARC"
},
{
"label": "Content types soportados",
"dir": "images, backup, iso, vztmpl, snippets, rootdir",
"zfs": "images, rootdir solamente (almacenamiento de bloque)"
},
{
"label": "Mejor para",
"dir": "Disco de propósito general: mezcla de discos de VM, backups, ISOs",
"zfs": "Disco puramente de datos de VM / LXC con necesidades de snapshot + integridad"
}
]
},
"opening": {
"heading": "Abrir la herramienta",
"body": "Desde el menú principal de ProxMenux, abre <strong>Storage &amp; Share Manager → Add Local Disk as Proxmox Storage</strong>. Verás este submenú con cuatro opciones:",
"imageAlt": "Menú Local Disk Manager — Add / View / Remove / List available disks"
},
"howRuns": {
"heading": "Cómo se ejecuta el script (flujo Add)",
"body": "El flujo tiene dos fases con un filtro de seguridad de triple gate. La Fase 1 descubre discos seguros, decide qué hacer con el elegido y recoge los parámetros de almacenamiento; la Fase 2 hace el trabajo destructivo. Hasta la confirmación final el disco queda intacto."
},
"format": {
"heading": "Formatear un disco en blanco",
"intro": "La ruta para un disco nuevo o uno cuyo contenido no te importa.",
"items": [
"Elige el disco (los discos del sistema / en uso quedan ocultos).",
"Elige \"Format disk (ERASE all data)\".",
"Elige el sistema de archivos — mira la tabla de arriba para las contrapartidas.",
"Storage ID (por defecto <code>disk-&lt;device&gt;</code>), ruta de montaje, preset de content type.",
"Confirma en el diálogo <strong>FINAL CONFIRMATION — DATA WILL BE ERASED</strong>.",
"ProxMenux limpia la tabla de particiones, crea una partición que abarca el disco entero, ejecuta <code>mkfs.&lt;fs&gt;</code> (o <code>zpool create</code>), la monta, la añade a <code>/etc/fstab</code> por UUID con <code>defaults,nofail</code> y la registra en Proxmox vía <code>pvesm add dir</code> o <code>pvesm add zfspool</code>."
],
"tipTitle": "Por qué UUID + nofail en /etc/fstab",
"tipBody": "El script escribe <code>UUID=… /mnt/&lt;id&gt; &lt;fs&gt; defaults,nofail 0 2</code>. El UUID sobrevive a reordenaciones de dispositivos entre reinicios (así que <code>/dev/sdc</code> pasando a ser <code>/dev/sdd</code> no rompe el arranque). <code>nofail</code> significa que si el disco desaparece alguna vez (fallo de hardware, desconectado), Proxmox arranca igualmente — el almacenamiento simplemente se mostrará como inactive hasta que el disco vuelva."
},
"reuse": {
"heading": "Reutilizar un sistema de archivos existente",
"intro": "La ruta para un disco en el que quieres conservar los datos — quizá lo moviste de otro host Proxmox, o el disco ya tiene backups / ISOs que quieres mantener accesibles.",
"items": [
"Elige el disco.",
"Elige \"Use existing filesystem\".",
"Storage ID, ruta de montaje, preset de content type.",
"ProxMenux <strong>no</strong> toca los datos: crea el punto de montaje, monta el disco, añade una entrada UUID a <code>/etc/fstab</code> y lo registra como almacenamiento Proxmox <code>dir</code>."
],
"warnTitle": "La ruta de reutilización no gestiona pools ZFS",
"warnBody": "Si el disco ya contiene un pool ZFS, la ruta de <em>reuse</em> aquí simplemente intenta montarlo como un sistema de archivos normal — y falla. Para importar un pool ZFS existente usa <code>zpool import &lt;name&gt;</code> en línea de comandos y después regístralo manualmente con <code>pvesm add zfspool</code>."
},
"presets": {
"heading": "Presets de content type",
"intro": "En vez de una larga lista de verificación, ProxMenux ofrece 4 presets más una opción custom. La cadena del preset se pasa a <code>pvesm add … --content &lt;csv&gt;</code>:",
"headerPreset": "Preset",
"headerContent": "Cadena de contenido",
"headerUse": "Caso de uso",
"rows": [
{
"preset": "VM Storage",
"content": "images,backup",
"use": "Un almacén de discos de VM dedicado que también guarda backups de esas VMs cerca."
},
{
"preset": "Standard NAS",
"content": "backup,iso,vztmpl",
"use": "Un disco de archivo / media — backups, ISOs y templates LXC. Sin discos de VM en vivo aquí."
},
{
"preset": "All types",
"content": "images,backup,iso,vztmpl,snippets",
"use": "\"Que decida el host\" — permite todos los content types que Proxmox soporta en este almacenamiento."
},
{
"preset": "Custom",
"content": "(entrada libre)",
"useRich": "Escribe el CSV exacto tú mismo, p. ej. <code>images</code> solo, o <code>rootdir,images</code>."
}
],
"zfsTitle": "El contenido del ZFS pool es más limitado",
"zfsBody": "Si elegiste <strong>zfs</strong> como sistema de archivos, Proxmox solo acepta <code>images</code> y <code>rootdir</code> como content types en un <code>zfspool</code> (es almacenamiento de bloque, no un sistema de archivos para ISOs). Los presets de arriba siguen funcionando pero Proxmox descarta silenciosamente los content types que no puede usar — comprueba <code>pvesm status</code> después."
},
"manual": {
"heading": "Equivalente manual",
"extIntro": "Formatear + registrar un disco como almacenamiento directory ext4:",
"zfsIntro": "O como ZFS pool:"
},
"view": {
"heading": "Ver almacenamientos de disco",
"body": "Lista cada almacenamiento Proxmox respaldado por disco (tanto <code>dir</code> como <code>zfspool</code> creados por el usuario — los pools del sistema como <code>rpool</code> quedan ocultos). Muestra la ruta de montaje / nombre del pool, content types y estado en vivo."
},
"remove": {
"heading": "Eliminar almacenamiento de disco",
"body": "Desregistra el almacenamiento de Proxmox (<code>pvesm remove</code>) y ofrece limpiar la entrada correspondiente en <code>/etc/fstab</code>. Para pools ZFS el script <strong>no</strong> destruye automáticamente el pool — eso es un paso aparte <code>zpool destroy &lt;name&gt;</code> que haces a mano cuando estés seguro.",
"warnTitle": "Datos y dependencias de VM existentes",
"warnBody": "Eliminar el almacenamiento no toca el sistema de archivos ni el pool — los datos siguen en el disco. Pero las VMs / CTs que referencian este almacenamiento por ID fallarán al arrancar tras la eliminación. Mueve esos discos de VM a otro almacenamiento (o haz un backup) antes de eliminar."
},
"list": {
"heading": "Listar discos disponibles",
"body": "Una vista de diagnóstico de solo lectura: imprime la salida de <code>lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL</code> seguida de los almacenamientos <code>dir</code> / <code>zfspool</code> que Proxmox ya conoce. Buena primera parada al abrir la herramienta cuando quieres ver \"¿qué hay en este host?\" antes de añadir nada."
},
"troubleshoot": {
"heading": "Solución de problemas",
"noDisksTitle": "\"No available disks found\"",
"noDisksIntro": "El filtro de seguridad ocultó cada disco. Razones comunes:",
"noDisksItems": [
"Solo está presente el disco raíz.",
"Cada otro disco forma parte de un array ZFS / LVM / RAID activo.",
"Cada otro disco está referenciado por una config de VM o LXC (passthrough).",
"El disco está en modo solo lectura (hardware fallando o write-blocker)."
],
"noDisksOutro": "Usa <em>List Available Disks</em> desde el menú para ver la salida cruda de <code>lsblk</code> y entender qué pasa.",
"mountedTitle": "El formateo falla con \"device is mounted\"",
"mountedBody": "Algo automontó el disco (udisksd, un gestor de escritorio, una unit de systemd persistente). Desmóntalo: <code>umount /dev/sdX?*</code> o <code>systemctl stop &lt;whatever-mounts-it&gt;</code>, y reintenta. El filtro de seguridad del script debería haber ocultado discos montados, así que si has llegado a este error el montaje ocurrió entre que se mostró el menú y tú confirmaste.",
"zpoolTitle": "zpool create falla \"invalid vdev specification\"",
"zpoolBody": "Normalmente significa que el disco todavía tiene firmas GPT / LVM / ZFS obsoletas que <code>zpool</code> se niega a sobrescribir sin force. El script ejecuta <code>wipefs</code> y <code>sgdisk --zap-all</code> antes del formato, pero un disco muy terco puede seguir teniendo una etiqueta obsoleta. Fuerza una limpieza manualmente: <code>zpool labelclear -f /dev/sdX</code> o <code>dd if=/dev/zero of=/dev/sdX bs=1M count=10</code> y reintenta.",
"inactiveTitle": "El almacenamiento aparece como inactive tras el reinicio",
"inactiveBody": "Comprueba <code>findmnt &lt;mount-path&gt;</code> — si el montaje falta, algo en <code>/etc/fstab</code> falló. <code>dmesg | tail</code> normalmente apunta a la razón (mismatch de UUID, corrupción del sistema de archivos, <code>nofail</code> abandonó el reintento). Un <code>mount -a</code> normalmente reactiva el almacenamiento una vez arreglada la causa."
},
"related": {
"heading": "Relacionado",
"items": [
{
"href": "/docs/disk-manager/format-disk",
"label": "Disk Manager: Format / Wipe Physical Disk",
"tail": " — alternativa de bajo nivel cuando solo quieres preparar un disco sin registrarlo como almacenamiento de Proxmox."
},
{
"href": "/docs/storage-share/host-iscsi",
"label": "Añadir target iSCSI como almacenamiento de Proxmox",
"tail": " — equivalente de red cuando el dispositivo de bloque vive en otra máquina."
},
{
"href": "/docs/storage-share/host-local-shared",
"label": "Añadir directorio compartido en el host",
"tail": " — prepara un directorio en el host para bind mounts LXC (no registra un almacenamiento de Proxmox)."
}
]
}
}

103
web/messages/es/docs/storage-share/host-local-shared.json Normal file
View File

@@ -0,0 +1,103 @@
{
"meta": {
"title": "Host: añadir directorio compartido en el host | ProxMenux Documentation",
"description": "Crea un directorio en el host listo para bind mounts LXC, con permisos que funcionan a la vez para contenedores privileged y unprivileged. Sticky bit + world-rwx + ACLs para herencia por defecto.",
"ogTitle": "Host: añadir directorio compartido en el host | ProxMenux Documentation",
"ogDescription": "Prepara un directorio en el host para bind mounts LXC con permisos compatibles con CTs privileged y unprivileged."
},
"header": {
"title": "Host: añadir directorio compartido en el host",
"description": "Crea un directorio en el host diseñado para hacer bind mount en uno o más contenedores LXC. ProxMenux aplica un conjunto de permisos que funciona a la vez para CTs privileged y unprivileged — sin quebraderos de cabeza con UIDs desplazados, sin chowns por contenedor — y registra el directorio para que el LXC Mount Manager lo pueda recoger después.",
"section": "Almacenamiento y compartición · Host"
},
"intro": {
"title": "Qué es esto (y qué NO es)",
"body": "Esta herramienta <strong>no</strong> registra nada en Proxmox (no hay <code>pvesm add</code> aquí). Solo prepara un directorio en el host — <code>/mnt/shared</code>, por defecto — con permisos que cualquier contenedor LXC puede leer y escribir, sin importar si el CT es privileged o unprivileged. El siguiente paso habitual es hacer bind mount en cada CT con el <mountLink>LXC Mount Manager</mountLink>."
},
"why": {
"heading": "Por qué una herramienta dedicada para esto",
"intro": "Cuando haces bind mount de un directorio del host en un contenedor LXC, los permisos dependen de:",
"items": [
"Si el CT es <strong>privileged</strong> (UID 0 en CT = UID 0 en host) o <strong>unprivileged</strong> (UID 0 en CT = UID 100000 en host — todo desplazado +100000).",
"La propiedad del directorio del host (un archivo propiedad del UID 1000 en el host aparece como \"others\" desde la perspectiva de un CT unprivileged, porque ningún usuario del CT mapea al UID 1000 del host).",
"Si varios CTs comparten el mismo directorio (CTs diferentes pueden tener rangos de UID diferentes)."
],
"outro": "El truco pragmático que ProxMenux usa aquí es <strong>dar acceso a todo el mundo</strong> a nivel de sistema de archivos: world-rwx más el sticky bit, más ACLs para que los archivos nuevos hereden los mismos permisos. Cualquier UID mapeado puede leer y escribir; no se requiere alineamiento de UID / GID."
},
"howRuns": {
"heading": "Cómo se ejecuta el script",
"body": "El script no tiene menú principal — ejecuta una sola acción, <strong>Create shared directory</strong>. La Fase 1 recoge la ruta destino; la Fase 2 crea el directorio y aplica permisos."
},
"bits": {
"heading": "Qué hace cada bit de permiso",
"intro": "El número <strong>1777</strong> no es arbitrario — es el mismo modo que Linux usa para <code>/tmp</code>. Tres propiedades combinadas:",
"headerBit": "Bit",
"headerEffect": "Efecto",
"headerWhy": "Por qué importa aquí",
"rows": [
{
"bit": "1 (sticky)",
"effect": "Solo el propietario del archivo puede borrar / renombrar un archivo.",
"why": "Evita que el CT-A borre archivos creados por el CT-B en el mismo directorio."
},
{
"bit": "777 (rwx-rwx-rwx)",
"effect": "Todos pueden leer, escribir y atravesar.",
"why": "Los UIDs de CT unprivileged (100000+) aparecen como \"others\" desde el host, así que world-rwx les da acceso."
},
{
"bit": "ACLs (default)",
"effect": "Heredado en cada archivo / subdir recién creado.",
"why": "Los permisos se aplican para siempre — el contenido nuevo conserva el perfil abierto sin reejecutar el script."
}
],
"privTitle": "Los CTs privileged ven lo mismo, solo que sin el desplazamiento",
"privBody": "Para un CT privileged, el UID 0 en el CT es el UID 0 en el host, así que <code>root</code> dentro del CT puede leer / escribir el directorio del host directamente. <code>1777</code> sigue estando bien — solo significa que usuarios no-root dentro del CT también pueden usar el directorio. Los mismos permisos cubren ambos casos."
},
"where": {
"heading": "Dónde poner el directorio compartido",
"intro": "El selector de ubicación ofrece cuatro opciones:",
"opt1Title": "1. Crear nueva carpeta en /mnt",
"opt1Body": "La elección habitual. ProxMenux sugiere automáticamente el primer nombre libre (<code>shared</code>, <code>shared2</code>, <code>shared3</code>, …). Solo tienes que confirmar o escribir un nombre diferente.",
"opt2Title": "2. Introducir ruta personalizada",
"opt2Body": "Para directorios fuera de <code>/mnt</code>. Cualquier ruta absoluta vale (p. ej. <code>/srv/media</code>, <code>/data/family</code>). El script aplica los mismos permisos.",
"opt3Title": "3. Ver carpetas existentes en /mnt",
"opt3Body": "Diagnóstico de solo lectura: lista cada directorio bajo <code>/mnt</code> con sus permisos, propietario y espacio disponible. Útil antes de crear uno nuevo para evitar colisiones de nombres.",
"opt4Title": "4. Cancelar",
"opt4Body": "Sale sin crear nada. Igual que pulsar <kbd>Esc</kbd>.",
"tipTitle": "¿Dónde vive /mnt?",
"tipBody": "Por defecto <code>/mnt</code> está en el sistema de archivos raíz de Proxmox. Si quieres el directorio compartido en un disco diferente (un disco de datos, un pool ZFS), monta ese disco bajo <code>/mnt/&lt;name&gt;</code> primero (Disk Manager o <diskLink>Añadir disco local como almacenamiento de Proxmox</diskLink>), y después crea el directorio compartido como subcarpeta dentro — o elige \"Introducir ruta personalizada\" aquí y apunta al disco montado."
},
"manual": {
"heading": "Equivalente manual",
"body": "El flujo entero se puede reproducir a mano:"
},
"next": {
"heading": "Siguiente paso: bind mount en contenedores",
"body": "Crear el directorio solo lo prepara — ningún contenedor lo ve aún. Para hacerlo visible dentro de uno o más LXCs, usa el <mountLink>LXC Mount Manager</mountLink> para hacer bind mount de <code>/mnt/&lt;name&gt;</code> en los CTs. Como los permisos ya están abiertos, el Mount Manager <strong>no</strong> ofrecerá cambiarlos — el directorio está listo para usar tal cual."
},
"troubleshoot": {
"heading": "Solución de problemas",
"mkdirTitle": "\"Failed to create directory\"",
"mkdirBody": "Normalmente un problema del sistema de archivos: <code>/mnt</code> está en un sistema de archivos solo lectura, la ruta contiene un componente que no es un directorio (p. ej. escribiste <code>/etc/passwd/sub</code>), o el disco está lleno. Comprueba con <code>df -h /mnt</code> y <code>mount | grep /mnt</code>.",
"writeTitle": "El contenedor no puede escribir pese a los permisos abiertos",
"writeBody": "Comprueba que el CT está usando realmente el bind mount (<code>pct config &lt;ctid&gt; | grep ^mp</code>). Dentro del CT, ejecuta <code>touch /mnt/data/test-$(date +%s)</code> — si esto falla con permission denied, el montaje puede estar en un sistema de archivos del host que no respeta ACLs (algunos montajes <code>ext3</code> o <code>vfat</code> antiguos). Mueve el directorio compartido a un backing ext4 / xfs / btrfs / zfs.",
"aclTitle": "Comandos ACL no disponibles silenciosamente",
"aclBody": "En una instalación mínima de Proxmox <code>setfacl</code> / <code>getfacl</code> pueden no estar instalados. El script hace un fallback elegante (comprobación <code>command -v setfacl</code>) y aplica solo permisos POSIX — que suele ser suficiente, pero los archivos nuevos no heredarán automáticamente el perfil permisivo. Instala <code>acl</code> con <code>apt-get install -y acl</code> y reejecuta el script sobre el directorio."
},
"related": {
"heading": "Relacionado",
"items": [
{
"href": "/docs/storage-share/lxc-mount-points",
"label": "LXC Mount Manager",
"tail": " — el siguiente paso natural: hacer bind mount de este directorio en uno o más contenedores."
},
{
"href": "/docs/storage-share/host-local-disk",
"label": "Añadir disco local como almacenamiento de Proxmox",
"tailRich": " — si quieres el directorio compartido en un disco dedicado, prepara el disco primero, móntalo bajo <code>/mnt</code> y crea la subcarpeta compartida aquí."
}
]
}
}

174
web/messages/es/docs/storage-share/host-nfs.json Normal file
View File

@@ -0,0 +1,174 @@
{
"meta": {
"title": "Host: montar share NFS en el host | ProxMenux Documentation",
"description": "Monta un export NFS externo en el host Proxmox — bien como almacenamiento de Proxmox (pvesm add nfs), bien como un montaje fstab del host normal (NO visible en Datacenter > Storage), o ambos. El método fstab es ideal para hacer bind mount del share en contenedores LXC sin exponerlo como almacenamiento de Proxmox.",
"ogTitle": "Host: montar share NFS en el host | ProxMenux Documentation",
"ogDescription": "Monta un export NFS externo en el host Proxmox vía pvesm, fstab o ambos. La ruta fstab es ideal para bind mounts LXC."
},
"header": {
"title": "Host: montar share NFS en el host",
"description": "Monta un export NFS externo (de un NAS, otro servidor, un share de homelab…) en el host Proxmox. Elige uno o ambos métodos: regístralo como almacenamiento de Proxmox (visible en Datacenter > Storage) y/o añade un montaje /etc/fstab normal en una ruta que tú elijas (útil para hacer bind mount del share en contenedores LXC sin exponerlo como almacenamiento de Proxmox).",
"section": "Almacenamiento y compartición · Host"
},
"intro": {
"title": "Qué hace",
"body": "ProxMenux ofrece dos métodos de montaje para cualquier export NFS: <strong>(1) Almacenamiento de Proxmox</strong> vía <code>pvesm add nfs</code> — el share aparece en Datacenter > Storage y Proxmox gestiona el montaje en <code>/mnt/pve/&lt;id&gt;</code>; <strong>(2) Montaje fstab del host</strong> en una ruta que tú elijas — persistente vía <code>/etc/fstab</code>, NO visible como almacenamiento de Proxmox, ideal para hacer bind mount en contenedores LXC (la UI de Proxmox queda limpia). Puedes ejecutar un método, el otro o ambos."
},
"opening": {
"heading": "Abrir la herramienta",
"body": "Desde el menú principal de ProxMenux, abre <strong>Storage &amp; Share Manager → Mount NFS Share on Host</strong>. Verás este submenú con cuatro opciones:",
"imageAlt": "Menú NFS Host Manager — Mount / View / Remove / Test connectivity"
},
"howRuns": {
"heading": "Cómo se ejecuta el script",
"body": "El flujo tiene dos fases con una separación clara entre \"descubrir, validar y elegir\" y \"montar / escribir config realmente\". Tras seleccionar un export, eliges el método o métodos de montaje vía una lista de verificación; el resto de diálogos solo piden parámetros para los métodos que seleccionaste. Hasta la confirmación final, ni <code>/etc/pve/storage.cfg</code> ni <code>/etc/fstab</code> se tocan."
},
"modes": {
"heading": "Selector de método de montaje (dos opciones, marca una o ambas)",
"intro": "Tras seleccionar y validar el export, ProxMenux muestra una lista de verificación con los dos métodos de montaje. Puedes marcar uno o ambos. Si pulsas OK sin marcar nada, el diálogo reaparece hasta que elijas al menos una opción o pulses Cancel para salir del flujo.",
"imageAlt": "Lista de verificación de método de montaje con opciones pvesm y fstab",
"headerMethod": "Método",
"headerMount": "Ruta de montaje",
"headerUi": "Visible en Datacenter > Storage",
"headerUseCase": "Caso de uso típico",
"rows": [
{
"method": "<strong>Como almacenamiento de Proxmox (pvesm)</strong>",
"mountRich": "<code>/mnt/pve/&lt;storage-id&gt;</code> (gestionado por Proxmox)",
"ui": "Sí",
"useCase": "Imágenes de disco de VM, backups, ISOs, templates LXC — cualquier cosa que necesite aparecer en la UI de Proxmox."
},
{
"method": "<strong>Solo fstab del host</strong>",
"mountRich": "<code>/mnt/&lt;path&gt;</code> (tú eliges la ruta)",
"ui": "No",
"useCaseRich": "Hacer bind mount del share en uno o más LXCs <em>sin</em> exponerlo como almacenamiento de Proxmox. Mantiene la UI de Datacenter limpia."
},
{
"method": "<strong>Ambos</strong>",
"mount": "Ambas rutas de arriba (dos conexiones NFS independientes al servidor)",
"ui": "Sí",
"useCase": "Quieres integración con la UI Y una ruta estable del lado del host con permisos abiertos para bind mounts LXC. El servidor ve dos conexiones desde el host."
}
],
"bothTitle": "\"Ambos\" crea dos montajes NFS independientes",
"bothBody": "Marcar ambas opciones ejecuta cada método independientemente — pvesm monta en <code>/mnt/pve/&lt;id&gt;</code>, fstab monta en <code>/mnt/&lt;path&gt;</code>. El servidor ve dos conexiones TCP desde el host Proxmox. Esto es intencional: te permite mantener el almacenamiento pvesm limpio (opciones por defecto de Proxmox) mientras tienes un montaje separado del lado del host con permisos abiertos para bind mounts LXC."
},
"pvesmBranch": {
"heading": "Método A — Como almacenamiento de Proxmox (pvesm)",
"intro": "Si <em>Como almacenamiento de Proxmox</em> está marcado, ProxMenux ejecuta el flujo pvesm original:",
"items": [
"<strong>Storage ID</strong> — cómo llamará Proxmox a este almacenamiento. Por defecto es <code>nfs-&lt;server-ip-with-dashes&gt;</code>. Solo se aceptan letras, dígitos, <code>-</code> y <code>_</code>.",
"<strong>Content types</strong> — Proxmox vincula categorías de contenido a volúmenes de almacenamiento; elige qué se le permite a este NFS contener:"
],
"headerType": "Content type",
"headerAllows": "Qué permite",
"rows": [
{
"type": "import",
"allowsRich": "Importaciones de imágenes de disco (seleccionado por defecto). Necesario para <em>Import Disk Image to VM</em>."
},
{
"type": "backup",
"allowsRich": "Archivos de backup de VM y CT (<code>vzdump</code>)."
},
{
"type": "iso",
"allows": "Imágenes ISO de instalación."
},
{
"type": "vztmpl",
"allows": "Templates LXC."
},
{
"type": "images",
"allows": "Imágenes de disco de VM en vivo (esto convierte el NFS en un almacén de discos de VM)."
},
{
"type": "rootdir",
"allows": "Sistemas de archivos raíz de LXC (raro para NFS — lee la nota de abajo)."
},
{
"type": "snippets",
"allows": "Scripts de hook y snippets cloud-init."
}
],
"warnTitle": "images y rootdir en NFS",
"warnBody": "Marcar <code>images</code> en un almacenamiento NFS deja a Proxmox colocar discos de VM en vivo ahí. Funciona, pero la latencia de NFS + su semántica de locks lo hacen notablemente más lento que el almacenamiento local (y un corte de red pausa cada VM respaldada por ese almacén). Marcar <code>rootdir</code> significa que alojarás sistemas de archivos raíz de LXC sobre NFS, lo que históricamente da problemas con contenedores unprivileged (interacciones overlay / chown). Es preferible mantener <code>images</code> / <code>rootdir</code> en almacenamiento local o iSCSI y usar NFS para <code>backup</code> / <code>iso</code> / <code>vztmpl</code>.",
"result": "El resultado es <code>pvesm add nfs &lt;id&gt; --server &lt;srv&gt; --export &lt;path&gt; --content &lt;csv&gt;</code> y Proxmox automonta en <code>/mnt/pve/&lt;id&gt;</code>."
},
"fstabBranch": {
"heading": "Método B — Solo montaje fstab del host",
"intro": "Si <em>Solo como montaje fstab del host</em> está marcado, ProxMenux pide una ruta de montaje del host y opciones persistentes, luego monta y escribe la entrada en <code>/etc/fstab</code>:",
"items": [
"<strong>Ruta de montaje del host</strong> — por defecto <code>/mnt/&lt;export-basename&gt;</code>. Debe ser una ruta absoluta. Si algo ya está montado ahí, o existe una entrada fstab para la misma ruta, ProxMenux te avisa y ofrece reemplazarla.",
"<strong>Mount options</strong> — elige <em>Read/Write</em> (por defecto con <code>rw,hard,nofail,_netdev,rsize=131072,wsize=131072,timeo=600,retrans=2</code>), <em>Read-only</em>, o <em>Custom</em> (escribe tu propia cadena de opciones)."
],
"appliesIntro": "Una vez confirmes, el script:",
"applies": [
"<code>mkdir -p</code> de la ruta de montaje.",
"<code>mount -t nfs -o &lt;opts&gt; &lt;srv&gt;:&lt;export&gt; &lt;path&gt;</code>.",
"Escribe una entrada de una línea en <code>/etc/fstab</code>: <code>&lt;srv&gt;:&lt;export&gt; &lt;path&gt; nfs &lt;opts&gt; 0 0</code>.",
"Ejecuta <code>systemctl daemon-reload</code> para que systemd recoja la nueva entrada fstab.",
"Intenta <code>chmod 1777</code> + <code>setfacl o::rwx</code> en el punto de montaje (best-effort silencioso — solo tiene éxito si el servidor NFS lo permite; muchos exports NAS ya sirven rutas world-writable)."
],
"lxcTitle": "Usar el montaje fstab desde un LXC",
"lxcBody": "El script imprime el comando <code>pct set</code> exacto al final para hacer bind mount de la ruta en un contenedor, p. ej. <code>pct set &lt;ctid&gt; -mp0 /mnt/&lt;path&gt;,mp=/mnt/&lt;ct-path&gt;,shared=1,backup=0</code>. O usa el <mountLink>LXC Mount Manager</mountLink>, que detecta el montaje fstab automáticamente. <strong>No se hacen cambios dentro del contenedor</strong> — para que los LXCs unprivileged lean/escriban los datos NFS, el script depende de la semántica world-writable del export del lado del servidor (típica en defaults de Synology, TrueNAS, OMV). Si tu servidor NFS aplica squash a root o restringe permisos, mira Solución de problemas.",
"noUiTitle": "El montaje fstab NO es un almacenamiento de Proxmox",
"noUiBody": "El montaje fstab del host es invisible para la UI web de Proxmox — por diseño. No aparece en <em>Datacenter > Storage</em>, no puedes seleccionarlo en el creador de VM / CT, y los trabajos de backup de Proxmox no pueden apuntarlo. Es puramente una ruta del sistema de archivos del host. Si quieres también integración con la UI, marca <em>ambos</em> métodos en el selector."
},
"manual": {
"heading": "Equivalente manual",
"pvesmIntro": "El Método A (pvesm) se traduce a:",
"fstabIntro": "El Método B (fstab) se traduce a:"
},
"view": {
"heading": "Ver almacenamientos NFS configurados",
"body": "Lista cada entrada NFS en Proxmox (<code>pvesm status | awk ''$2 == \"nfs\"''</code>) con servidor, export, content types, ruta de montaje y estado en vivo. <strong>Nota:</strong> esta vista solo muestra almacenamientos registrados con pvesm — los montajes solo en fstab no se listan aquí. Compruébalos con <code>findmnt -t nfs</code> o <code>grep nfs /etc/fstab</code>."
},
"remove": {
"heading": "Eliminar almacenamiento NFS",
"body": "Ejecuta <code>pvesm remove &lt;storage-id&gt;</code> tras una confirmación que muestra servidor / export / contenido. Solo se elimina el registro del lado de Proxmox — <strong>el propio servidor NFS remoto nunca se toca</strong>, no se borran archivos. Para eliminar un montaje solo en fstab, edita <code>/etc/fstab</code> a mano y ejecuta <code>umount &lt;path&gt;</code>.",
"warnTitle": "Haz backup de las dependencias primero",
"warnBody": "Si VMs, CTs o trabajos de backup todavía referencian este almacenamiento (por ID), eliminarlo los deja apuntando a un almacén desaparecido. Proxmox marcará el error pero no limpiará. Mueve o elimina esas referencias primero, después elimina el almacenamiento."
},
"test": {
"heading": "Probar conectividad NFS",
"body": "Ejecuta una pasada de diagnóstico sobre cada almacenamiento NFS registrado en Proxmox: comprueba que <code>showmount</code> está disponible, que <code>rpcbind</code> está corriendo, hace ping a cada servidor, prueba el puerto 2049, llama a <code>showmount -e</code> y finalmente informa de la vista del propio Proxmox (<code>pvesm status</code>). Buena primera parada cuando un almacenamiento aparece como <em>inactive</em> en la UI de Proxmox."
},
"troubleshoot": {
"heading": "Solución de problemas",
"noServersTitle": "\"No NFS servers found on the network\"",
"noServersBody": "El auto-descubrimiento usa <code>nmap -p 2049 --open &lt;subnet&gt;/24</code>. El servidor puede no responder si: está en una VLAN / subnet diferente, su firewall bloquea las sondas nmap (muchos lo hacen) o el puerto 2049 está intencionalmente cerrado en esa interfaz. Usa la opción <em>Manual</em> con la IP o hostname del servidor en su lugar.",
"portTitle": "\"NFS port (2049) is not accessible\"",
"portBody": "El ping tuvo éxito pero <code>nc -z -w 3 &lt;server&gt; 2049</code> falló. Comprueba que el servicio NFS está corriendo en el servidor (<code>systemctl status nfs-server</code> en Linux, Panel de Control → File Services en Synology, plugin NFS en OMV / TrueNAS) y que el firewall permite el 2049 desde el host Proxmox.",
"showmountTitle": "\"Failed to connect\" desde showmount",
"showmountBody": "El servidor rechazó la consulta de la lista de exports. Causas comunes: el servidor aplica ACLs de cliente estrictas (tu IP de Proxmox no está en la lista permitida), <code>rpcbind</code> no está corriendo en el servidor o el servidor expone solo NFSv4 con <code>showmount</code> deshabilitado. La ruta del export se puede añadir manualmente igualmente si la conoces.",
"inactiveTitle": "El almacenamiento aparece como inactive en la UI de Proxmox",
"inactiveBody": "Ejecuta <em>Test NFS Connectivity</em> primero — el 99 % de las veces esto marca el salto exacto que se rompe (DNS, puerto, permisos de montaje). Si la conectividad va bien pero Proxmox sigue marcando inactive, comprueba <code>journalctl -u pvestatd</code> en el nodo Proxmox; DNS intermitente o montajes NFS lentos al arrancar pueden dejar almacenamientos en estado inactive hasta que <code>pvesm set &lt;id&gt; --disable 0</code> se reaplica.",
"lxcNoWriteTitle": "El montaje fstab funciona pero un LXC unprivileged no puede escribir por un bind mount",
"lxcNoWriteBody": "Los permisos NFS se aplican del lado del servidor, no del host. Las opciones fstab (<code>uid=</code>, <code>file_mode=</code>) que funcionan para CIFS <strong>no</strong> se aplican a NFS. Si tu LXC unprivileged (root dentro del CT = UID 100000 en el host, mapeado a NFS como \"others\") no puede escribir, el servidor NFS o bien aplica squash a root o bien tiene permisos restrictivos. Arregla en el servidor: cambia el export a <code>no_root_squash</code> si confías en el host, o pon el export world-writable (Synology, TrueNAS, OMV exponen esto en su UI). El script intenta <code>chmod 1777</code> en el montaje pero eso solo tiene éxito cuando el servidor lo permite.",
"fstabBootTitle": "El montaje fstab no se levanta tras el reinicio",
"fstabBootBody": "El script añade <code>nofail,_netdev</code> para que un share que falte al arranque no bloquee el inicio. Si el montaje nunca se levanta: confirma que la red es alcanzable (<code>ping &lt;server&gt;</code>), comprueba <code>journalctl -u remote-fs.target</code> y verifica que la entrada es válida con <code>mount -fav | grep nfs</code>. <code>mount -a</code> después del arranque monta todo lo que falte actualmente."
},
"related": {
"heading": "Relacionado",
"items": [
{
"href": "/docs/storage-share/host-samba",
"label": "Samba / CIFS como almacenamiento de Proxmox",
"tail": " — mismo patrón de flujo (Método A pvesm + Método B fstab) para shares SMB/CIFS."
},
{
"href": "/docs/storage-share/lxc-mount-points",
"label": "LXC Mount Manager",
"tailRich": " — hacer bind mount de la ruta solo en fstab <code>/mnt/&lt;path&gt;</code> en uno o más contenedores."
},
{
"href": "/docs/storage-share/lxc-nfs-client",
"label": "Cliente NFS en LXC",
"tail": " — alternativa: monta NFS directamente desde dentro de un contenedor privileged (se salta el host)."
}
]
}
}

172
web/messages/es/docs/storage-share/host-samba.json Normal file
View File

@@ -0,0 +1,172 @@
{
"meta": {
"title": "Host: montar share Samba en el host | ProxMenux Documentation",
"description": "Monta un share Samba / CIFS externo en el host Proxmox — bien como almacenamiento de Proxmox (pvesm add cifs), bien como un montaje fstab del host normal con uid/gid/file_mode abiertos (NO visible en Datacenter > Storage), o ambos. El método fstab abre los permisos para que un LXC unprivileged que haga bind mount de la ruta pueda leer/escribir sin cambios dentro del contenedor.",
"ogTitle": "Host: montar share Samba en el host | ProxMenux Documentation",
"ogDescription": "Monta un share Samba / CIFS externo en el host Proxmox vía pvesm, fstab con permisos abiertos (ideal para bind mounts LXC), o ambos."
},
"header": {
"title": "Host: montar share Samba en el host",
"description": "Monta un share Samba (SMB / CIFS) externo — de un NAS, una máquina Windows, un export SMB de TrueNAS — en el host Proxmox. Elige uno o ambos métodos: regístralo como almacenamiento de Proxmox (visible en Datacenter > Storage) y/o añade un montaje /etc/fstab normal en una ruta que tú elijas, con uid/gid/file_mode abiertos para que los LXCs unprivileged puedan hacer bind mount y escribir sin cambios dentro del contenedor.",
"section": "Almacenamiento y compartición · Host"
},
"intro": {
"title": "Qué hace",
"body": "ProxMenux ofrece dos métodos de montaje para cualquier share Samba: <strong>(1) Almacenamiento de Proxmox</strong> vía <code>pvesm add cifs</code> — visible en Datacenter > Storage, montado en <code>/mnt/pve/&lt;id&gt;</code>, credenciales guardadas cifradas en <code>/etc/pve/priv/storage/&lt;id&gt;.pw</code>; <strong>(2) Montaje fstab del host</strong> en una ruta que tú elijas — persistente vía <code>/etc/fstab</code>, montado con <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> para que los bind mounts LXC unprivileged puedan escribir, credenciales guardadas en un archivo solo para root en <code>/etc/samba/credentials/</code> (la contraseña nunca aparece en <code>fstab</code>). Puedes ejecutar un método, el otro o ambos."
},
"opening": {
"heading": "Abrir la herramienta",
"body": "Desde el menú principal de ProxMenux, abre <strong>Storage &amp; Share Manager → Mount Samba Share on Host</strong>. Verás este submenú con cuatro opciones:",
"imageAlt": "Menú Samba Host Manager — Mount / View / Remove / Test connectivity"
},
"howRuns": {
"heading": "Cómo se ejecuta el script",
"body": "El flujo tiene dos fases. Fase 1: descubre el servidor, valida credenciales, elige share y elige método o métodos de montaje vía una lista de verificación. Fase 2: solo se ejecutan los métodos que marcaste. Las credenciales se necesitan por adelantado porque <code>smbclient</code> las necesita para listar shares. Hasta la confirmación final, ni <code>/etc/pve/storage.cfg</code> ni <code>/etc/fstab</code> se tocan."
},
"modes": {
"heading": "Selector de método de montaje (dos opciones, marca una o ambas)",
"intro": "Tras seleccionar el share y validar las credenciales, ProxMenux muestra una lista de verificación con los dos métodos de montaje. Puedes marcar uno o ambos. Si pulsas OK sin marcar nada, el diálogo reaparece hasta que elijas al menos una opción o pulses Cancel para salir del flujo.",
"headerMethod": "Método",
"headerMount": "Ruta de montaje",
"headerUi": "Visible en Datacenter > Storage",
"headerUseCase": "Caso de uso típico",
"rows": [
{
"method": "<strong>Como almacenamiento de Proxmox (pvesm)</strong>",
"mountRich": "<code>/mnt/pve/&lt;storage-id&gt;</code> (gestionado por Proxmox)",
"ui": "Sí",
"useCase": "Backups, ISOs, templates LXC — cualquier cosa que necesite aparecer en la UI de Proxmox. Los discos de VM en vivo están técnicamente soportados pero desaconsejados en CIFS (semántica de locking)."
},
{
"method": "<strong>Solo fstab del host</strong>",
"mountRich": "<code>/mnt/&lt;path&gt;</code> con uid/gid/file_mode abiertos",
"ui": "No",
"useCaseRich": "Hacer bind mount del share en uno o más LXCs <em>sin</em> exponerlo como almacenamiento de Proxmox. Los permisos abiertos garantizan que los CTs unprivileged puedan escribir a través del bind mount."
},
{
"method": "<strong>Ambos</strong>",
"mount": "Ambas rutas de arriba (dos conexiones CIFS independientes al servidor)",
"ui": "Sí",
"useCase": "Quieres integración con la UI Y una ruta estable del lado del host con permisos abiertos para bind mounts LXC. El montaje pvesm usa los valores por defecto de Proxmox; el montaje fstab aplica el uid/gid/file_mode abierto por separado."
}
],
"bothTitle": "\"Ambos\" crea dos conexiones CIFS independientes",
"bothBody": "pvesm y fstab montan el mismo share dos veces con opciones distintas. El montaje pvesm en <code>/mnt/pve/&lt;id&gt;</code> usa los valores por defecto de Proxmox (sin uid/gid abiertos) — la UI de Proxmox está contenta. El montaje fstab en <code>/mnt/&lt;path&gt;</code> usa <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> — los bind mounts LXC unprivileged a él pueden escribir. Dos conexiones TCP al servidor SMB desde el mismo host Proxmox."
},
"pvesmBranch": {
"heading": "Método A — Como almacenamiento de Proxmox (pvesm)",
"intro": "Si <em>Como almacenamiento de Proxmox</em> está marcado, ProxMenux ejecuta el flujo pvesm original:",
"items": [
"<strong>Storage ID</strong> — por defecto <code>cifs-&lt;server-ip-with-dashes&gt;</code>. Solo letras, dígitos, <code>-</code> y <code>_</code>.",
"<strong>Content types</strong> — CIFS expone <strong>6</strong> opciones (las mismas que NFS menos <code>rootdir</code>, que Proxmox no permite en CIFS porque la semántica de locking no puede sostener un rootfs LXC en vivo):"
],
"headerType": "Content type",
"headerAllows": "Qué permite",
"rows": [
{
"type": "import",
"allows": "Importaciones de imágenes de disco (seleccionado por defecto)."
},
{
"type": "backup",
"allowsRich": "Archivos de backup de VM y CT (<code>vzdump</code>)."
},
{
"type": "iso",
"allows": "Imágenes ISO de instalación."
},
{
"type": "vztmpl",
"allows": "Templates LXC."
},
{
"type": "images",
"allowsRich": "Imágenes de disco de VM en vivo — <strong>avisado en línea</strong>, ver abajo."
},
{
"type": "snippets",
"allows": "Scripts de hook y snippets cloud-init."
}
],
"warnTitle": "Discos de VM en vivo en CIFS",
"warnBody": "Si marcas <code>images</code>, ProxMenux saca un aviso antes de continuar. CIFS usa un modelo de locking advisory que interactúa mal con las operaciones de disco de KVM (snapshots, migración en vivo, I/O bajo contención). Un almacén de backups o ISOs en CIFS es perfectamente correcto; un almacén de discos en vivo es buscarse problemas. Usa NFS (o almacenamiento local) para <code>images</code> cuando puedas.",
"credsTitle": "Dónde guarda pvesm las credenciales",
"credsBody": "Cuando usas autenticación de usuario, la contraseña NO se escribe en <code>/etc/pve/storage.cfg</code>. Proxmox la guarda en <code>/etc/pve/priv/storage/&lt;storage-id&gt;.pw</code> — modo <code>0600</code>, propietario <code>root</code>, miembro del cluster sync. Si más adelante cambias la contraseña en el servidor Samba, usa <code>pvesm set &lt;id&gt; --password &lt;new&gt;</code> o elimina y vuelve a añadir a través de ProxMenux."
},
"fstabBranch": {
"heading": "Método B — Solo montaje fstab del host",
"intro": "Si <em>Solo como montaje fstab del host</em> está marcado, ProxMenux pide una ruta de montaje del host y opciones persistentes, escribe un archivo de credenciales solo para root (modo User), luego monta y escribe la entrada en <code>/etc/fstab</code>:",
"items": [
"<strong>Ruta de montaje del host</strong> — por defecto <code>/mnt/&lt;share-name&gt;</code>. Debe ser una ruta absoluta. Si algo ya está montado ahí, o existe una entrada fstab, ProxMenux ofrece reemplazarla.",
"<strong>Mount options</strong> — elige <em>Read/Write</em> (por defecto con <code>rw,uid=0,gid=0,file_mode=0777,dir_mode=0777,iocharset=utf8,nofail,_netdev</code>), <em>Read-only</em> (variante de solo lectura con <code>file_mode=0555,dir_mode=0555</code>), o <em>Custom</em> (escribe tu propia cadena de opciones). El uid/gid/file_mode abiertos siempre se recomiendan para escrituras a través de bind mount LXC."
],
"credsTitle": "Archivo de credenciales (modo User)",
"credsBody": "Si te autenticaste con usuario + contraseña, ProxMenux escribe un archivo de credenciales solo para root en <code>/etc/samba/credentials/&lt;server&gt;_&lt;share&gt;.cred</code> (modo <code>0600</code>) con líneas <code>username=</code> y <code>password=</code>, y lo referencia en la entrada fstab vía la opción de montaje <code>credentials=</code>. El texto en claro nunca aterriza en <code>/etc/fstab</code>. Para el modo Guest, en su lugar se añade la opción <code>guest</code> y no se crea archivo de credenciales.",
"appliesIntro": "Una vez confirmes, el script:",
"applies": [
"<code>mkdir -p</code> de la ruta de montaje.",
"<code>mount -t cifs -o &lt;opts&gt;,credentials=&lt;file&gt;</code> (o <code>guest</code>) <code>//&lt;srv&gt;/&lt;share&gt; &lt;path&gt;</code>.",
"Escribe una entrada de una línea en <code>/etc/fstab</code>: <code>//&lt;srv&gt;/&lt;share&gt; &lt;path&gt; cifs &lt;opts&gt; 0 0</code>.",
"Ejecuta <code>systemctl daemon-reload</code> para que systemd recoja la nueva entrada fstab."
],
"lxcTitle": "Usar el montaje fstab desde un LXC unprivileged",
"lxcBody": "Como el cliente CIFS aplica <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code>, cada archivo en el montaje pertenece al UID 0 del host con modo 0777. Un LXC unprivileged que haga bind mount de la ruta ve permisos \"others\" en cada entrada (root del CT = UID 100000 del host = others en el sistema de archivos del host), así que las lecturas y escrituras tienen éxito. <strong>No se hacen cambios dentro del contenedor</strong> — sin <code>chown</code> en el CT, sin configuración de grupo, nada modificado en <code>/etc/lxc</code> más allá de la única línea <code>mp</code> de bind mount. El script imprime el comando <code>pct set</code> exacto al final, o usa el <mountLink>LXC Mount Manager</mountLink> para adjuntar la ruta.",
"noUiTitle": "El montaje fstab NO es un almacenamiento de Proxmox",
"noUiBody": "El montaje fstab del host es invisible para la UI web de Proxmox — por diseño. No aparece en <em>Datacenter > Storage</em>, no puedes seleccionarlo en el creador de VM / CT y los trabajos de backup de Proxmox no pueden apuntarlo. Es puramente una ruta del sistema de archivos del host. Si quieres también integración con la UI, marca <em>ambos</em> métodos en el selector."
},
"manual": {
"heading": "Equivalente manual",
"pvesmIntro": "El Método A (pvesm) se traduce a:",
"fstabUserIntro": "Método B (fstab, auth de usuario) — archivo de credenciales + montaje:",
"fstabGuestIntro": "Método B (fstab, auth guest) — sin archivo de credenciales:"
},
"view": {
"heading": "Ver almacenamientos CIFS configurados",
"body": "Lista cada entrada CIFS en Proxmox (<code>pvesm status | awk ''$2 == \"cifs\"''</code>) con servidor, share, content types, usuario (o <em>Guest</em>), ruta de montaje y estado en vivo. La contraseña <strong>nunca se imprime</strong>. <strong>Nota:</strong> esta vista solo muestra almacenamientos registrados con pvesm — los montajes solo en fstab no se listan. Compruébalos con <code>findmnt -t cifs</code> o <code>grep cifs /etc/fstab</code>."
},
"remove": {
"heading": "Eliminar almacenamiento CIFS",
"body": "Ejecuta <code>pvesm remove &lt;storage-id&gt;</code> tras una confirmación que muestra servidor / share / contenido. Solo se elimina el registro del lado de Proxmox — <strong>el servidor Samba remoto no se toca</strong>. Proxmox también borra el archivo de credenciales emparejado. Para eliminar un montaje solo en fstab, edita <code>/etc/fstab</code> a mano, ejecuta <code>umount &lt;path&gt;</code> y elimina el archivo de <code>/etc/samba/credentials/</code>.",
"warnTitle": "Haz backup de las dependencias primero",
"warnBody": "Las VMs, CTs o trabajos de backup que referencien este almacenamiento por ID fallarán tras la eliminación. Mueve / elimina esas referencias antes de eliminar el almacenamiento."
},
"test": {
"heading": "Probar conectividad Samba",
"body": "Ejecuta una pasada de diagnóstico sobre cada almacenamiento CIFS registrado en Proxmox: comprueba que <code>smbclient</code> está disponible, hace ping a cada servidor, prueba los puertos 445 y 139, intenta un listado guest e informa de la vista del propio Proxmox (<code>pvesm status</code>). \"Requires authentication\" en el listado guest significa que tu servidor solo expone shares a usuarios autenticados — normal en la mayoría de setups NAS."
},
"troubleshoot": {
"heading": "Solución de problemas",
"noServersTitle": "\"No Samba servers found on the network\"",
"noServersBody": "El auto-descubrimiento usa <code>nmap -p 139,445</code>. El servidor puede estar en una subnet diferente, con firewall o solo alcanzable por hostname (mDNS / WINS). Usa la opción <em>Manual</em> con la IP o hostname en su lugar.",
"noSharesTitle": "\"No accessible shares found\"",
"noSharesBody": "<code>smbclient -L</code> no devolvió nada para estas credenciales. Causas: el usuario no tiene permiso para listar shares (prueba con credenciales de admin una vez, o escribe el nombre del share manualmente), el servidor tiene la visibilidad de shares deshabilitada o las credenciales son incorrectas. El script te permite escribir el nombre del share a mano en este caso.",
"denyTitle": "El montaje de Proxmox falla con NT_STATUS_ACCESS_DENIED",
"denyBody": "Las credenciales que pvesm guardó están desincronizadas con el servidor Samba (contraseña cambiada, cuenta deshabilitada, mismatch de domain / workgroup). Vuelve a introducir credenciales con <code>pvesm set &lt;id&gt; --username &lt;u&gt; --password &lt;p&gt;</code> o elimina y vuelve a añadir desde ProxMenux. Si el servidor está en un dominio AD, añade <code>--domain &lt;DOMAIN&gt;</code> a la llamada <code>pvesm set</code>.",
"sleepTitle": "\"host is down\" o el estado del almacenamiento pasa a inactive por la noche",
"sleepBody": "Algunos appliances NAS ponen SMB en suspensión agresivamente. <code>pvestatd</code> entonces ve el almacenamiento como inactive hasta que el primer acceso despierta al NAS. Si es cosmético, no hay nada roto. Si causa fallos de backup, deshabilita la desconexión por idle de SMB en el NAS o programa los backups fuera de la ventana de suspensión.",
"lxcNoWriteTitle": "El bind mount LXC unprivileged no puede escribir en la ruta fstab",
"lxcNoWriteBody": "Confirma que el montaje usa las opciones abiertas: <code>findmnt /mnt/&lt;path&gt;</code> debería mostrar <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code>. Si una cadena de opciones Custom omite esas, un LXC unprivileged tendrá permission denied (los UIDs del CT mapean a \"others\" del host, que sin file_mode abierto no tienen bit de escritura). Vuelve a montar con el preset RW por defecto o añade las cuatro opciones de vuelta a tu cadena custom.",
"fstabBootTitle": "El montaje fstab no se levanta tras el reinicio",
"fstabBootBody": "El script añade <code>nofail,_netdev</code> para que un share que falte al arranque no bloquee el inicio. Si el montaje nunca se levanta: confirma que la red es alcanzable (<code>ping &lt;server&gt;</code>), comprueba <code>journalctl -u remote-fs.target</code>, verifica que el archivo de credenciales sigue existiendo (<code>ls -l /etc/samba/credentials/</code>) y es legible, y prueba <code>mount -a</code> manualmente."
},
"related": {
"heading": "Relacionado",
"items": [
{
"href": "/docs/storage-share/host-nfs",
"label": "Share NFS como almacenamiento de Proxmox",
"tail": " — página hermana con el mismo patrón de flujo (Método A pvesm + Método B fstab) y contrapartidas en paralelo."
},
{
"href": "/docs/storage-share/lxc-mount-points",
"label": "LXC Mount Manager",
"tailRich": " — hacer bind mount de la ruta solo en fstab <code>/mnt/&lt;path&gt;</code> en uno o más contenedores."
},
{
"href": "/docs/storage-share/lxc-samba-client",
"label": "Cliente Samba en LXC",
"tail": " — alternativa: monta Samba directamente desde dentro de un contenedor privileged (se salta el host)."
}
]
}
}

135
web/messages/es/docs/storage-share/index.json Normal file
View File

@@ -0,0 +1,135 @@
{
"meta": {
"title": "NFS, Samba, iSCSI y puntos de montaje LXC en Proxmox — Almacenamiento y compartición | ProxMenux",
"description": "Integra almacenamiento externo y local en Proxmox VE y comparte carpetas entre el host y los contenedores LXC. Añade shares NFS, Samba (CIFS) y targets iSCSI como almacenamiento de Proxmox, configura bind mounts LXC (Mount Manager) y ejecuta clientes y servidores NFS / Samba dentro de contenedores.",
"ogTitle": "NFS, Samba, iSCSI y puntos de montaje LXC en Proxmox — Almacenamiento y compartición",
"ogDescription": "Integra almacenamiento externo y local en Proxmox VE — registro de NFS, Samba e iSCSI más bind mounts LXC y compartición por red.",
"twitterTitle": "Proxmox NFS, Samba, iSCSI | ProxMenux",
"twitterDescription": "Añade NFS / Samba / iSCSI como almacenamiento de Proxmox y comparte carpetas entre el host y LXC."
},
"header": {
"title": "Storage & Share Manager",
"description": "Integra almacenamiento externo o local en Proxmox VE y comparte carpetas entre el host y los contenedores LXC. Tres bloques de herramientas: integración de almacenamiento en el host (registra almacenamiento en el propio Proxmox), el LXC Mount Manager (bind mounts con un manejo pragmático de permisos) y compartición por red en LXC (flujos de cliente y servidor NFS / Samba para casos de uso concretos).",
"section": "Almacenamiento y compartición"
},
"intro": {
"title": "Para qué sirve este menú",
"body": "El Disk Manager trabaja a nivel de <em>discos físicos individuales</em>. Storage &amp; Share Manager trabaja un nivel por encima — <strong>registra pools de almacenamiento y shares de red en Proxmox</strong> (para que la UI y el creador de VMs los puedan usar) y <strong>configura la compartición de archivos entre el host y tus contenedores</strong>."
},
"opening": {
"heading": "Abrir el menú",
"body": "Desde el menú principal de ProxMenux, selecciona <strong>Storage &amp; Share Manager</strong>. Verás esto:",
"imageAlt": "Menú Storage & Share Manager con bloques HOST y LXC"
},
"groups": {
"heading": "Tres grupos de herramientas",
"intro": "El menú se divide en tres bloques. <strong>Integración de almacenamiento en el host</strong> registra almacenamiento externo o local en el propio Proxmox. El <strong>LXC Mount Manager</strong> es la herramienta principal para compartir carpetas con contenedores — un flujo de bind mount pragmático que gestiona el mapeo de UIDs de CTs unprivileged en el lado del host. <strong>Compartición por red en LXC</strong> cubre cuatro escenarios adicionales en los que un contenedor necesita <em>consumir</em> o <em>exponer</em> shares NFS / Samba directamente.",
"hostTitle": "Almacenamiento en el host",
"hostBody": "Registra almacenamiento externo y local en Proxmox vía <code>pvesm add …</code>. Una vez registrado, el almacenamiento aparece en la UI de Proxmox y queda disponible para los creadores de VMs y CTs.",
"hostItems": [
"NFS / Samba / iSCSI externo → almacenamiento de Proxmox",
"Disco local → almacenamiento Proxmox directory o ZFS",
"Directorio local compartido (para bind mounts entre CTs)"
],
"lxcMountTitle": "LXC Mount Manager",
"lxcMountBody": "La herramienta principal de compartición LXC. Hace bind mount de directorios del host dentro de los contenedores vía <code>pct set -mpN</code> y gestiona las particularidades de permisos de los CTs unprivileged sin crear ningún grupo o usuario dentro del contenedor.",
"lxcMountItems": [
"Funciona con CTs privileged y unprivileged",
"Ofrece aplicar <code>o+rwx</code> en el directorio del host para UIDs unprivileged",
"Repara montajes CIFS / NFS existentes si hace falta"
],
"lxcNetTitle": "Compartición por red en LXC",
"lxcNetBody": "Cuatro flujos adicionales para escenarios en los que un contenedor necesita consumir o exponer shares NFS / Samba directamente. Todos requieren un contenedor <strong>privileged</strong>.",
"lxcNetItems": [
"<strong>Cliente</strong> NFS / Samba (consumir shares externos)",
"<strong>Servidor</strong> NFS / Samba (exponer carpetas del CT)"
]
},
"host": {
"heading": "Integración de almacenamiento en el host",
"intro": "Registra almacenamiento en Proxmox. Cada opción llama a <code>pvesm add …</code> por dentro, así que el almacenamiento aparece en <strong>Datacenter → Storage</strong> y queda disponible para los creadores de VM / CT.",
"options": [
{
"href": "/docs/storage-share/host-nfs",
"icon": "Network",
"title": "Añadir share NFS como almacenamiento de Proxmox",
"description": "Registra un export NFS externo como almacenamiento de Proxmox vía pvesm add nfs. Proxmox gestiona el montaje — no hacen falta entradas en fstab."
},
{
"href": "/docs/storage-share/host-samba",
"icon": "Share2",
"title": "Añadir share Samba como almacenamiento de Proxmox",
"description": "Registra un share Samba / CIFS externo como almacenamiento de Proxmox vía pvesm add cifs. Proxmox gestiona el montaje y las credenciales."
},
{
"href": "/docs/storage-share/host-iscsi",
"icon": "Database",
"title": "Añadir target iSCSI como almacenamiento de Proxmox",
"description": "Conecta a un target iSCSI externo y lo registra como almacenamiento de Proxmox (dispositivo de bloque) para imágenes de disco de VM."
},
{
"href": "/docs/storage-share/host-local-disk",
"icon": "HardDrive",
"title": "Añadir disco local como almacenamiento de Proxmox",
"description": "Formatea un disco local SATA / SAS / NVMe y lo registra como almacenamiento Proxmox directory o ZFS pool."
},
{
"href": "/docs/storage-share/host-local-shared",
"icon": "FolderOpen",
"title": "Añadir directorio compartido en el host",
"description": "Crea un directorio en el host pensado para hacer bind mount en varios CTs. No es un almacenamiento de Proxmox — solo un recurso del lado del host para bind mounts LXC."
}
]
},
"lxcMount": {
"heading": "LXC Mount Manager",
"intro": "La herramienta principal para compartir carpetas entre el host Proxmox y los contenedores LXC. Usa <code>pct set -mpN</code> para hacer bind mount de un directorio del host dentro del contenedor, y gestiona las particularidades de permisos de los CTs unprivileged en el lado del host (no se crea ningún grupo ni usuario dentro del contenedor).",
"card": {
"title": "Puntos de montaje LXC (host ↔ CT)",
"description": "Bind mount de cualquier directorio del host dentro de un contenedor LXC vía pct set -mpN. Funciona con CTs privileged y unprivileged; ofrece chmod o+rwx / ACLs en el directorio del host y repara montajes CIFS / NFS existentes cuando hace falta."
}
},
"lxcNet": {
"heading": "Compartición por red en LXC",
"intro": "Usa estos flujos cuando un contenedor necesita <em>ser</em> un endpoint NFS / Samba — ya sea consumiendo un share externo (cliente) o exponiendo sus propias carpetas (servidor). Para la mayoría de necesidades de compartición de archivos (bind mounts host ↔ CT), el <mountLink>LXC Mount Manager</mountLink> es más sencillo y no requiere contenedores privileged.",
"options": [
{
"href": "/docs/storage-share/lxc-nfs-client",
"icon": "Download",
"title": "Cliente NFS en LXC",
"description": "Monta shares NFS externos desde dentro de un contenedor LXC privileged. Soporta auto-descubrimiento, persistencia en /etc/fstab y desmontaje limpio."
},
{
"href": "/docs/storage-share/lxc-samba-client",
"icon": "Download",
"title": "Cliente Samba en LXC",
"description": "Monta shares Samba / CIFS desde dentro de un contenedor LXC privileged. Credenciales guardadas de forma segura, auto-descubrimiento disponible."
},
{
"href": "/docs/storage-share/lxc-nfs-server",
"icon": "Upload",
"title": "Servidor NFS en LXC",
"description": "Exporta carpetas por NFS desde dentro de un contenedor LXC privileged."
},
{
"href": "/docs/storage-share/lxc-samba-server",
"icon": "Upload",
"title": "Servidor Samba en LXC",
"description": "Expone carpetas por SMB / CIFS desde dentro de un contenedor LXC privileged."
}
]
},
"privReq": {
"title": "Requisito de contenedor privileged",
"body": "Los cuatro flujos de <strong>compartición por red en LXC</strong> de arriba requieren un contenedor <strong>privileged</strong> — los módulos de kernel (<code>nfs-kernel-server</code>, <code>smbd</code>, <code>mount.nfs</code>, <code>mount.cifs</code>) necesitan capabilities que los CTs unprivileged no exponen. Si solo necesitas compartir archivos entre el host y un CT unprivileged, usa el <mountLink>LXC Mount Manager</mountLink> en su lugar — hace bind mount desde el host y ajusta los permisos en el lado del host para que el contenedor pueda leer y escribir sin trucos de módulos de kernel."
},
"unprivExplain": {
"title": "Cómo gestiona ProxMenux los permisos de CT unprivileged",
"body": "Los contenedores LXC unprivileged desplazan sus UIDs en <strong>+100000</strong> en el host (UID 0 del contenedor = UID 100000 del host, UID 1000 del contenedor = UID 101000 del host, …). Por tanto, un archivo creado por un usuario del contenedor aparece en el host como <em>others</em> — sin pertenecer a ningún usuario o grupo real del host. El LXC Mount Manager aborda esto de forma pragmática: en vez de intentar alinear UIDs / GIDs entre host y CT, ofrece aplicar <code>chmod o+rwx</code> (más las ACLs correspondientes) en el directorio del host, para que cualquier UID mapeado pueda leer y escribir. Para CIFS remonta con <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code>; para NFS pone un directorio sticky escribible por todos y, si el servidor aplica squash a root, te guía al ajuste correcto del lado del servidor."
},
"scripts": {
"heading": "Scripts implicados",
"intro": "Cada página individual enlaza al script que dirige su flujo. El archivo de abajo es un helper compartido que no está documentado como página propia pero lo usan varios de los flujos de compartición por red en LXC:",
"itemTail": " — validación de CT, selección de punto de montaje, comprobación de privileged y helpers de configuración de grupo universal compartidos entre los flujos de cliente / servidor en LXC."
}
}

174
web/messages/es/docs/storage-share/lxc-mount-points.json Normal file
View File

@@ -0,0 +1,174 @@
{
"meta": {
"title": "Puntos de montaje LXC (host ↔ contenedor) | ProxMenux Documentation",
"description": "El LXC Mount Manager — bind mount de cualquier directorio del host en uno o más contenedores LXC vía pct set -mpN. Gestiona las particularidades de permisos de los contenedores unprivileged, repara montajes CIFS / NFS existentes en el lado del host y nunca modifica nada dentro del contenedor.",
"ogTitle": "Puntos de montaje LXC (host ↔ contenedor) | ProxMenux Documentation",
"ogDescription": "Bind mount de directorios del host en contenedores LXC. Gestiona el mapeo de UIDs unprivileged de forma pragmática, repara el acceso CIFS / NFS en el lado del host."
},
"header": {
"title": "Puntos de montaje LXC (host ↔ contenedor)",
"description": "La herramienta principal para compartir carpetas entre el host Proxmox y los contenedores LXC. Bind mount de cualquier directorio del host en uno o más contenedores usando la sintaxis nativa pct set -mpN de Proxmox. La parte inteligente: resuelve los quebraderos de cabeza de permisos de los contenedores unprivileged en el lado del host — nunca modifica nada dentro del contenedor.",
"section": "Almacenamiento y compartición · LXC"
},
"intro": {
"title": "Qué hace",
"body": "Coge un directorio que vive en el host Proxmox (una carpeta local, un share NAS montado, un almacenamiento gestionado por Proxmox…) y haz que aparezca dentro de un contenedor LXC en una ruta que tú elijas, con permisos que funcionan incluso para contenedores unprivileged — sin tocar nada dentro del contenedor."
},
"bigPicture": {
"heading": "Cómo funciona (visión general)",
"intro": "Un bind mount es exactamente lo que el nombre dice: Proxmox le dice al kernel \"el directorio del host <code>X</code> también debería aparecer en la ruta <code>Y</code> dentro de este contenedor\". No hay copia, ni sync, ni red — ambos lados ven los <em>mismos archivos</em> a la vez.",
"sourceLabel": "Host Proxmox",
"sourceDetail": "/mnt/data\n(tu carpeta)",
"targetLabel": "Contenedor LXC",
"targetDetail": "/mnt/data\n(aparece aquí)",
"arrowLabel": "bind mount",
"outro": "La ruta del host a la izquierda y la ruta del contenedor a la derecha pueden ser diferentes — por ejemplo, <code>/mnt/nas-films</code> en el host puede convertirse en <code>/media/films</code> dentro del contenedor. El script añade la entrada a la config del contenedor (<code>/etc/pve/lxc/&lt;ctid&gt;.conf</code>) usando el siguiente índice <code>mpN</code> libre, con dos valores por defecto seguros incorporados:",
"items": [
"<code>shared=1</code> — le dice a Proxmox que los datos son almacenamiento compartido, así que no intenta migrar el disco al migrar el contenedor.",
"<code>backup=0</code> — excluye el bind mount de los backups <code>vzdump</code> (los datos viven en el host, los respaldas por separado)."
]
},
"perms": {
"heading": "Gestión de permisos — la parte inteligente",
"intro": "Los bind mounts son fáciles en principio. La parte difícil son los permisos: un contenedor LXC <strong>unprivileged</strong> desplaza cada UID en <strong>+100000</strong>, así que un archivo creado dentro del contenedor por el usuario 1000 aparece en el host como UID 101000 — un UID que nadie en el host posee. Para que esto funcione sin alinear UIDs entre hosts y contenedores, ProxMenux aplica el truco adecuado de \"abrir permisos\" en el lado del <em>host</em>, dependiendo del tipo de directorio que elegiste:",
"headerType": "Tipo de directorio del host",
"headerAction": "Qué ofrece hacer el script",
"localType": "Carpeta local",
"localTypeSub": "p. ej. /mnt/data",
"localActionRich": "<code>chmod o+rwx</code> + <code>setfacl o::rwx</code> en el directorio del host. Solo se ofrece si el CT es unprivileged y los permisos actuales son insuficientes.",
"cifsType": "CIFS / SMB montado",
"cifsTypeSub": "p. ej. /mnt/pve/cifs-…",
"cifsActionRich": "Remontar con <code>uid=0, gid=0, file_mode=0777, dir_mode=0777</code> para que el CT (cualquier UID) pueda leer y escribir el share. <code>/etc/fstab</code> se actualiza.",
"nfsType": "NFS montado",
"nfsTypeSub": "p. ej. /mnt/pve/nfs-…",
"nfsActionRich": "<code>chmod 1777</code> + <code>setfacl o::rwx</code> en el montaje NFS. No puede anular el squash del lado del servidor — si ni siquiera el root del host puede escribir, se te guía a arreglar el export en el servidor NFS.",
"privTitle": "Los contenedores privileged no necesitan nada de esto",
"privBody": "Para contenedores privileged, el UID 0 en el CT es el UID 0 en el host — root dentro del CT puede leer y escribir el directorio del host directamente sin trucos de permisos. El script detecta esto y se salta el paso de \"abrir permisos\" por completo.",
"noCtTitle": "El script nunca modifica nada dentro del contenedor",
"noCtBody": "Todos los ajustes de permisos ocurren en el <strong>sistema de archivos del host</strong>. Sin chowns por <code>pct exec</code>, sin grupos creados en el CT, sin fstab dentro del contenedor. Si reutilizas el directorio bind-mounted en un CT distinto después, se aplican los mismos permisos automáticamente — sin setup por contenedor."
},
"writes": {
"heading": "Qué escribe ProxMenux — y qué no",
"intro": "Una confusión común al hacer bind mount en un CT unprivileged: la gente asume que ProxMenux debe estar escribiendo entradas <code>lxc.idmap</code> en <code>/etc/pve/lxc/&lt;CTID&gt;.conf</code>. <strong>No lo hace.</strong> Solo se añade una línea a ese archivo — el propio bind mount:",
"outro": "La línea de salida que ves al final de la ejecución, <em>\"Unprivileged container — UID offset: 100000\"</em>, es puramente informativa — solo te dice que el CT está usando el mapeo unprivileged por defecto de Proxmox (root en CT = UID 100000 en host). El script no configura nada a su alrededor.",
"twoWaysHeading": "Las dos formas de hacer que los permisos funcionen — y por qué ProxMenux elige una",
"headerApproach": "Enfoque",
"headerChanges": "Qué cambia",
"headerWhen": "Cuándo encaja",
"hostType": "Permisos del lado del host",
"hostTypeSub": "(lo que hace este script)",
"hostChangesRich": "<code>chmod o+rwx</code> + <code>setfacl o::rwx</code> en el directorio del host. Los UIDs mapeados del CT (100000+) caen en el cubo \"others\", así que abrir <em>others</em> es suficiente.",
"hostWhen": "Acceso genérico a carpeta compartida desde cualquier CT. Varios CTs compartiendo el mismo directorio del host. Sencillo y reutilizable.",
"idmapTypeRich": "<code>lxc.idmap</code>",
"idmapTypeSub": "(este script no lo usa)",
"idmapChangesRich": "Mapeo personalizado de UID/GID en <code>/etc/pve/lxc/&lt;CTID&gt;.conf</code> más entradas correspondientes en <code>/etc/subuid</code> + <code>/etc/subgid</code> en el host. El CT debe reiniciarse en cada cambio.",
"idmapWhenRich": "Necesitas que un UID <em>específico</em> dentro del CT mapee a un UID <em>específico</em> en el host (p. ej. <code>media:1000</code> en el CT debe poseer archivos como <code>media:1000</code> en el host para que NFS no aplique squash). Un setup más rígido, normalmente solo merece la pena para ese escenario exacto.",
"idmapTipTitle": "Cuándo necesitas lxc.idmap de verdad",
"idmapTipBody": "Si el LXC Mount Manager no cubre tu caso — típicamente porque necesitas que los archivos escritos desde dentro del CT aterricen en el host como un UID/GID específico (exports NFS con <code>all_squash</code>, shares Samba con propiedad estricta, compartir un directorio con un usuario del host que tiene el mismo nombre que alguien dentro del CT) — ese es el momento de añadir entradas <code>lxc.idmap</code> a mano. El Mount Manager no te peleará: la línea de bind mount que escribió es independiente de cualquier configuración idmap que añadas después."
},
"opening": {
"heading": "Abrir la herramienta",
"body": "Desde el menú principal de ProxMenux, abre <strong>Storage &amp; Share Manager → Configure LXC Mount Points (Host ↔ Container)</strong>. Verás este submenú con tres opciones:",
"imageAlt": "Menú LXC Mount Manager — Add / View / Remove"
},
"addFlow": {
"heading": "Añadir un montaje — flujo completo",
"intro": "La vista técnica, para cuando quieras saber exactamente qué hace cada diálogo:"
},
"sources": {
"heading": "Qué puedes elegir como directorio del host",
"intro": "El selector de directorio del host es el más exhaustivo de la sección de Almacenamiento y compartición. Escanea cuatro fuentes y presenta una lista deduplicada:",
"headerSource": "Fuente",
"headerWhere": "De dónde viene",
"headerLabel": "Etiqueta en el menú",
"rows": [
{
"source": "Montajes de red activos",
"whereRich": "Shares CIFS / NFS montados actualmente, parseados de <code>/proc/mounts</code>.",
"labelRich": "<code>NFS [used/size]</code> o <code>CIFS/SMB [used/size]</code>"
},
{
"source": "Montajes fstab inactivos",
"whereRich": "Definidos en <code>/etc/fstab</code> pero no montados actualmente.",
"labelRich": "<code>fstab(off)-NFS</code> / <code>fstab(off)-CIFS/SMB</code>"
},
{
"source": "Directorios locales",
"whereRich": "Subdirectorios bajo <code>/mnt</code> que no son montajes de red.",
"labelRich": "<code>Local [size]</code>"
},
{
"source": "Almacenamientos Proxmox",
"whereRich": "Rutas de almacenamiento bajo <code>/mnt/pve/*</code> (NFS / CIFS registrados vía <code>pvesm</code>).",
"labelRich": "<code>PVE-NFS</code> / <code>PVE-CIFS/SMB</code> / <code>Proxmox-Storage</code>"
},
{
"source": "Entrada manual",
"where": "Cualquier otra cosa — escribe la ruta absoluta tú mismo.",
"labelRich": "<em>Introducir ruta manualmente</em>"
}
],
"tipTitle": "Las rutas internas de Proxmox quedan filtradas",
"tipBody": "El selector se salta explícitamente las rutas internas de Proxmox (<code>/mnt/pve/local</code>, <code>/mnt/pve/local-lvm</code>, <code>/mnt/pve/backup</code>, …) — están reservadas para internos de Proxmox y no deberías hacerles bind mount. Solo aparecen los almacenamientos añadidos por el usuario."
},
"manual": {
"heading": "Equivalente manual",
"privIntro": "Para un contenedor privileged — el caso más simple, sin trucos de permisos:",
"unprivLocalIntro": "Para un contenedor unprivileged con un directorio local del host — abre los permisos en el host primero:",
"unprivCifsIntro": "Para un contenedor unprivileged con un share CIFS ya montado en el host:"
},
"view": {
"heading": "Ver puntos de montaje",
"body": "Lista cada entrada <code>mpN</code> de cada contenedor en este host Proxmox, agrupado por id de CT y mostrando ruta del host → ruta del contenedor más cualquier opción extra. Solo lectura — útil como comprobación antes de añadir o eliminar nada."
},
"remove": {
"heading": "Eliminar un punto de montaje",
"body": "Elige el contenedor, elige la entrada <code>mpN</code>, confirma. El script ejecuta <code>pct set --delete mpN</code> para quitar la entrada de la config del CT y ofrece reiniciar el contenedor si está corriendo. El directorio del host y su contenido <strong>no se tocan</strong> — puedes volver a añadir el montaje después (o adjuntar el mismo directorio a un CT distinto).",
"warnTitle": "Los contenedores en ejecución necesitan un reinicio para que los cambios surtan efecto",
"warnBody": "Tanto añadir como eliminar puntos de montaje solo se hacen visibles dentro del contenedor tras un reinicio. El script ofrece un <code>pct reboot</code> de un clic al final de cada operación; puedes declinar y reiniciar manualmente después."
},
"troubleshoot": {
"heading": "Solución de problemas",
"noMountTitle": "El montaje aparece en la config del pct pero no dentro del contenedor",
"noMountBody": "Los bind mounts solo se adjuntan cuando el contenedor arranca. Si añadiste el montaje mientras el CT estaba corriendo, reinícialo (<code>pct reboot &lt;ctid&gt;</code>). Si ya está reiniciado y sigue faltando, comprueba <code>pct config &lt;ctid&gt;</code> para confirmar que la entrada existe y que la ruta del host realmente contiene un directorio.",
"noWriteTitle": "El contenedor puede ver el directorio pero no puede escribir",
"noWriteBody": "Casi siempre un problema de permisos. Para contenedores unprivileged, ejecuta de nuevo el fix de permisos del script — las ACLs del directorio del host pueden haber sido reseteadas por otra herramienta (rsync, restore desde backup, <code>chmod</code> manual). Para CIFS, revisa las opciones de montaje en el host: <code>findmnt /mnt/pve/cifs-…</code>, busca valores <code>uid=</code> / <code>gid=</code> / <code>file_mode=</code>.",
"alreadyTitle": "\"This path is already used as a mount point in this container\"",
"alreadyBody": "Elegiste la misma ruta del contenedor que ya está cableada a un directorio del host distinto. O elige una ruta del contenedor diferente, o elimina el punto de montaje existente primero.",
"nfsTitle": "El acceso NFS sigue bloqueado tras aplicar el fix del host",
"nfsIntro": "Tu servidor NFS está aplicando squash a root o a todas las conexiones. El script puede detectar esto (intenta escribir un archivo de prueba desde el host) y muestra guía del lado del servidor. Dos arreglos comunes del lado del servidor para el export:",
"nfsItems": [
"<code>no_root_squash</code> — los CTs privileged pueden escribir directamente.",
"<code>all_squash,anonuid=65534,anongid=65534</code> — para CTs unprivileged."
],
"nfsOutro": "Estos cambios ocurren en el servidor NFS (TrueNAS, Synology, tu export personalizado, …), no en Proxmox.",
"fstabOffTitle": "Montar entradas \"fstab(off)\" no hace nada",
"fstabOffBody": "El selector muestra entradas <code>fstab(off)-</code> cuando un montaje de red está definido en fstab pero no está montado actualmente. El script te deja hacer bind mount de la ruta, pero el directorio estará vacío hasta que realmente montes el share (<code>mount &lt;path&gt;</code> en el host). Móntalo primero, luego bind en el CT."
},
"related": {
"heading": "Relacionado",
"items": [
{
"href": "/docs/storage-share/host-local-shared",
"label": "Añadir directorio compartido en el host",
"tailRich": " — primer paso típico: prepara un <code>/mnt/shared</code> en el host antes de hacerle bind mount en uno o más CTs aquí."
},
{
"href": "/docs/storage-share/host-nfs",
"label": "Añadir share NFS como almacenamiento de Proxmox",
"extraHref": "/docs/storage-share/host-samba",
"extraLabel": "Añadir share Samba como almacenamiento de Proxmox",
"joiner": " / ",
"tailRich": " — registra un share externo en Proxmox primero, luego haz bind mount de su ruta <code>/mnt/pve/&lt;id&gt;</code> en el CT aquí."
},
{
"href": "/docs/storage-share/lxc-nfs-client",
"label": "Cliente NFS en LXC",
"extraHref": "/docs/storage-share/lxc-samba-client",
"extraLabel": "Cliente Samba en LXC",
"joiner": " / ",
"tail": " — la alternativa cuando quieres que el propio CT monte el share (requiere un contenedor privileged)."
}
]
}
}

128
web/messages/es/docs/storage-share/lxc-nfs-client.json Normal file
View File

@@ -0,0 +1,128 @@
{
"meta": {
"title": "Cliente NFS en LXC | ProxMenux Documentation",
"description": "Monta shares NFS directamente desde dentro de un contenedor LXC de Proxmox con ProxMenux. Auto-instala nfs-common, soporta auto-descubrimiento en la LAN, montajes persistentes vía /etc/fstab y comportamiento seguro en el arranque. Requiere un contenedor privileged.",
"ogTitle": "Cliente NFS en LXC | ProxMenux Documentation",
"ogDescription": "Monta shares NFS desde dentro de un contenedor LXC privileged. Auto-descubrimiento, persistencia en /etc/fstab, defaults de arranque seguros."
},
"header": {
"title": "Cliente NFS en LXC",
"description": "Monta shares NFS directamente desde dentro de un contenedor LXC de Proxmox. El contenedor se convierte en un cliente NFS real — habla con el servidor NFS sobre la red, ejecuta mount.nfs, escribe en /etc/fstab. ProxMenux instala nfs-common por ti, te ayuda a encontrar servidores y exports, y aplica defaults seguros de arranque.",
"section": "Almacenamiento y compartición · LXC"
},
"privReq": {
"title": "Contenedor privileged requerido",
"body": "El cliente <code>mount.nfs</code> del kernel necesita capabilities (<code>SYS_ADMIN</code> como mínimo) que los contenedores LXC unprivileged no exponen. El script lo impone — te pide elegir un CT y <strong>aborta si es unprivileged</strong>. Si necesitas el share dentro de un CT unprivileged, móntalo en el host Proxmox primero (con <hostNfsLink>Share NFS como almacenamiento de Proxmox</hostNfsLink>) y hazle bind mount en el CT con el <mountLink>LXC Mount Manager</mountLink>."
},
"what": {
"heading": "Qué hace",
"body": "A diferencia del LXC Mount Manager — que hace que el CT vea algo <em>a través del</em> host Proxmox — este script le da al contenedor su <strong>propio cliente NFS</strong>: habla NFS sobre la red, monta shares directamente desde el servidor NFS y guarda el montaje en el <code>/etc/fstab</code> del contenedor. El host Proxmox no está en la ruta de datos.",
"diagramServerLabel": "Servidor NFS",
"diagramServerDetail": "/export/data",
"diagramHostLabel": "Host Proxmox",
"diagramHostDetail": "(solo un\npuente de red)",
"diagramCtLabel": "LXC (privileged)",
"diagramCtDetail": "/mnt/data\nmount.nfs dentro del CT",
"diagramArrow": "NFS",
"twoWaysTitle": "Dos formas de dar acceso NFS a un CT — elige una",
"twoWaysBind": "<strong>Bind mount vía host</strong> (<mountLink>LXC Mount Manager</mountLink>): el host monta el NFS una vez, cada CT hace bind mount de la misma ruta. Funciona con CTs unprivileged. Recomendado cuando varios CTs necesitan el mismo share.",
"twoWaysDirect": "<strong>Montaje NFS directo dentro del CT</strong> (esta página): el CT monta el NFS él mismo. Requiere privileged. Útil cuando el CT debe poseer su conexión / credenciales, o para setups donde cada CT habla con un servidor distinto."
},
"opening": {
"heading": "Abrir la herramienta",
"body": "Desde el menú principal de ProxMenux, abre <strong>Storage &amp; Share Manager → Configure NFS Client in LXC (only privileged)</strong>. ProxMenux te pide primero <strong>elegir el CT destino</strong> (y lo arranca si está parado); aborta si es unprivileged. Una vez seleccionado el CT, ves este submenú:",
"imageAlt": "Menú NFS Client Manager — Mount / View / Unmount / Test connectivity"
},
"howRuns": {
"heading": "Cómo se ejecuta el script (flujo Mount)"
},
"fstabFlags": {
"heading": "Por qué esos flags de fstab",
"intro": "Para montajes permanentes el script añade tres flags más allá de las opciones NFS estándar: <code>_netdev,x-systemd.automount,noauto</code>. Cada uno resuelve un problema real de boot:",
"headerFlag": "Flag",
"headerEffect": "Qué hace",
"rows": [
{
"flag": "_netdev",
"effect": "Le dice al sistema init que este montaje necesita la red. El arranque no se bloquea esperándolo antes de que la red esté arriba."
},
{
"flag": "x-systemd.automount",
"effectRich": "Crea una unit auto-mount de systemd: el montaje solo ocurre la primera vez que algo accede a <code>/mnt/&lt;path&gt;</code>. Un servidor NFS inalcanzable al arrancar no atasca el CT."
},
{
"flag": "noauto",
"effect": "Salta el montaje eager al arrancar. Combinado con la unit automount de arriba, el montaje se establece de forma lazy en el primer acceso."
}
],
"netEffectTitle": "Efecto neto",
"netEffectBody": "Tu contenedor siempre arranca, incluso si el servidor NFS está offline. La primera vez que algo toca la ruta de montaje, systemd lo monta silenciosamente. Si el servidor sigue caído, ese único acceso falla con <em>resource temporarily unavailable</em> — pero nada más en el CT se ve afectado."
},
"manual": {
"heading": "Equivalente manual",
"body": "Reproduce el flujo entero a mano — cada comando se ejecuta <strong>dentro del CT</strong> vía <code>pct exec &lt;ctid&gt; --</code> o directamente vía <code>pct enter &lt;ctid&gt;</code>:"
},
"view": {
"heading": "Ver montajes actuales",
"body": "Lista cada punto de montaje NFS activo dentro del CT (<code>mount | grep nfs</code>) más cada línea NFS en el <code>/etc/fstab</code> del CT. Para cada entrada fstab se muestra el estado del montaje en vivo — útil para detectar montajes permanentes que no se levantaron al arrancar."
},
"unmount": {
"heading": "Desmontar share NFS",
"body": "Combina los montajes en vivo y las entradas fstab en una sola lista, te deja elegir uno y <strong>elimina la línea correspondiente de <code>/etc/fstab</code></strong>. El script <em>no</em> ejecuta <code>umount</code> en el montaje en vivo — en su lugar te dice que hace falta un reinicio del CT para que el desmontaje surta efecto.",
"warnTitle": "El script elimina entradas fstab, no montajes en vivo",
"warnBody": "Es una decisión de diseño deliberada: <code>umount</code> en un montaje ocupado falla con \"device busy\" cuando algo dentro del CT lo sigue usando. Eliminar la entrada fstab garantiza que el montaje desaparezca limpiamente en el siguiente arranque del CT. Si quieres el montaje fuera <em>ya</em> y estás seguro de que nada lo está usando, ejecuta <code>pct exec &lt;ctid&gt; -- umount /mnt/&lt;path&gt;</code> a mano después de que el script termine."
},
"test": {
"heading": "Probar conectividad NFS",
"body": "Pasada de diagnóstico dentro del CT: confirma que <code>nfs-common</code> está instalado, que <code>rpcbind</code> está corriendo, lista los montajes NFS actuales y luego itera sobre cada servidor NFS referenciado en fstab y comprueba ping → puerto 2049 → <code>showmount -e</code>. Buena primera parada cuando un montaje permanente no se levanta."
},
"troubleshoot": {
"heading": "Solución de problemas",
"privTitle": "Contenedor privileged requerido (el script aborta)",
"privBody": "El CT seleccionado es unprivileged. El cliente NFS del kernel necesita la capability <code>SYS_ADMIN</code> que los CTs unprivileged no exponen. O bien convierte el CT a privileged (la conversión &amp; Disk Manager está documentada en la página <importLink>Import Disk to LXC</importLink>) o usa la ruta alternativa descrita en el aviso al inicio de esta página.",
"aptTitle": "apt-get install nfs-common falla",
"aptIntro": "El script asume un CT de la familia Debian (<code>apt-get</code>). Si el CT corre Alpine / Arch / Rocky / Alma, el paso de instalación falla silenciosamente. Instala el cliente NFS a mano para esa distro:",
"aptItems": [
"Alpine: <code>apk add nfs-utils</code>",
"Arch: <code>pacman -S nfs-utils</code>",
"Rocky / Alma: <code>dnf install nfs-utils</code>"
],
"aptOutro": "Después reejecuta el script de ProxMenux — el paso de instalación se salta cuando las herramientas ya están presentes.",
"portTitle": "\"NFS port (2049) is not accessible\"",
"portBody": "El ping tuvo éxito pero <code>nc -z &lt;server&gt; 2049</code> falló desde dentro del CT. Comprueba que el servicio NFS está corriendo en el servidor, que el firewall permite el 2049 desde la red del CT y que el CT realmente tiene una ruta de red válida (prueba <code>pct exec &lt;ctid&gt; -- ip route</code>).",
"bootTitle": "El montaje permanente tiene éxito pero no se levanta al arrancar",
"bootBody": "Casi siempre uno de: la red no está lista cuando el CT monta (los flags <code>_netdev,x-systemd.automount,noauto</code> del script lo arreglan — vuelve a añadir el montaje vía el script si escribiste la línea fstab a mano sin esos), el servidor es inalcanzable al arrancar (auto-mount espera al primer acceso — eso es normal) o DNS no resuelto al arrancar (usa la IP del servidor, no su hostname).",
"squashTitle": "El servidor aplica squash a root, sin acceso de escritura desde dentro del CT",
"squashIntro": "El export NFS usa <code>root_squash</code> (el valor por defecto) y el CT escribe como root. Dos opciones:",
"squashItems": [
"Lado del servidor: cambia el export a <code>no_root_squash</code> (solo si confías en el CT).",
"Lado del CT: escribe como un usuario no-root que el servidor acepte, o haz chown del share apropiadamente."
],
"squashOutro": "ProxMenux no puede arreglar esto — es política del servidor."
},
"related": {
"heading": "Relacionado",
"items": [
{
"href": "/docs/storage-share/lxc-mount-points",
"label": "Puntos de montaje LXC (host ↔ contenedor)",
"tail": " — la alternativa para CTs unprivileged: monta en host, bind en CT."
},
{
"href": "/docs/storage-share/lxc-samba-client",
"label": "Cliente Samba en LXC",
"tail": " — página hermana, mismo patrón para shares SMB / CIFS."
},
{
"href": "/docs/storage-share/lxc-nfs-server",
"label": "Servidor NFS en LXC",
"tailRich": " — el inverso: expone carpetas <em>desde</em> un CT por NFS."
},
{
"href": "/docs/storage-share/host-nfs",
"label": "Share NFS como almacenamiento de Proxmox",
"tail": " — registra el share en el propio Proxmox en vez de dentro de un único CT."
}
]
}
}

159
web/messages/es/docs/storage-share/lxc-nfs-server.json Normal file
View File

@@ -0,0 +1,159 @@
{
"meta": {
"title": "Servidor NFS en LXC | ProxMenux Documentation",
"description": "Expón carpetas por NFS desde dentro de un contenedor LXC de Proxmox con ProxMenux. Auto-instala nfs-kernel-server, configura una convención de grupo sharedfiles universal, gestiona /etc/exports, ACL de red y desinstalación. Requiere un contenedor privileged.",
"ogTitle": "Servidor NFS en LXC | ProxMenux Documentation",
"ogDescription": "Ejecuta un servidor NFS dentro de un contenedor LXC privileged. Grupo sharedfiles universal, ACL de red y desinstalación completa."
},
"header": {
"title": "Servidor NFS en LXC",
"description": "Ejecuta un servidor NFS de kernel dentro de un contenedor LXC de Proxmox y expón carpetas a otras máquinas en la red. ProxMenux instala nfs-kernel-server, configura una convención de grupo sharedfiles universal para que múltiples CTs privileged puedan compartir archivos limpiamente, gestiona /etc/exports y ofrece una ruta de desinstalación completa.",
"section": "Almacenamiento y compartición · LXC"
},
"privReq": {
"title": "Contenedor privileged requerido",
"body": "<code>nfs-kernel-server</code> necesita montar el sistema de archivos del kernel <code>nfsd</code> en <code>/proc/fs/nfsd</code>, lo que requiere <code>CAP_SYS_ADMIN</code> en el namespace del kernel del host — no solo en el namespace de usuario del contenedor. LXC unprivileged no expone esa capability. En la práctica, el servicio simplemente falla al arrancar con <code>rpc.nfsd: Unable to access /proc/fs/nfsd errno 2 (No such file or directory)</code> y systemd marca <code>nfs-server.service</code> como una dependencia fallida. El script impone un CT privileged y <strong>aborta si es unprivileged</strong>. Si no puedes usar un CT privileged, ejecuta el servidor NFS dentro de una VM."
},
"what": {
"heading": "Qué hace",
"body": "Esto es lo <em>opuesto</em> de la página del cliente NFS. El contenedor se convierte en un <strong>servidor</strong> NFS: expone una carpeta de su sistema de archivos a clientes en la red. Otros CTs, el host Proxmox, VMs o máquinas físicas pueden entonces montar esa carpeta.",
"diagramServerLabel": "LXC (privileged) — servidor NFS",
"diagramServerDetail": "/mnt/data\n(carpeta que expones)\n\nchown root:sharedfiles\nchmod 2775 (SGID)\n\nnfs-kernel-server\n+ rpcbind corriendo",
"diagramClientLabel": "Cualquier cliente en la red",
"diagramClientDetail": "otro CT, el host,\nuna VM, una máquina física…",
"diagramArrow": "export NFS"
},
"shared": {
"heading": "La convención del grupo \"sharedfiles\"",
"body": "Antes de exportar la carpeta, ProxMenux crea un grupo llamado <code>sharedfiles</code> con <strong>GID 101000</strong> dentro del contenedor, añade cada usuario regular a él, luego pone el directorio del export a <code>root:sharedfiles</code> con modo <code>2775</code>. El <code>2</code> al principio es el bit SGID — cada archivo o carpeta creada dentro hereda automáticamente el grupo <code>sharedfiles</code>.",
"gidTitle": "Por qué GID 101000 específicamente",
"gidBody": "Mapea al GID <strong>1000</strong> del host cuando un contenedor unprivileged lee el mismo archivo (el idmap por defecto de LXC desplaza todo en +100000). En el flujo actual de ProxMenux el propio servidor NFS corre en un CT <strong>privileged</strong> (sin desplazamiento de su lado), pero la convención mantiene el GID numéricamente consistente con CTs cliente unprivileged que puedan montar este share después. Dos CTs privileged usando ambos <code>sharedfiles</code> con GID 101000 pueden leer / escribir los archivos del otro limpiamente porque los números de GID coinciden de principio a fin.",
"remapTitle": "El script también crea usuarios 'remap_*' — son vestigiales aquí",
"remapBody": "Por cada usuario regular en el CT (y para UIDs comunes como 33 = www-data, 1000, 1001, 1002), el script crea un usuario paralelo <code>remap_&lt;uid&gt;</code> con UID = <code>&lt;uid&gt; + 100000</code>, todos miembros de <code>sharedfiles</code>. El desplazamiento <code>+100000</code> imita el idmap unprivileged de LXC, pero como este script impone un CT <strong>privileged</strong> (sin desplazamiento), esos usuarios <code>remap_*</code> son cuentas shadow sin contraparte real en el host. Son restos inofensivos de una intención de diseño más ambiciosa. Si no los ves en <code>getent passwd</code>, no se rompe nada."
},
"defaults": {
"heading": "Opciones de export por defecto — léelo primero",
"warnTitle": "Las opciones por defecto incluyen no_root_squash",
"warnBody": "ProxMenux usa por defecto <code>rw,sync,no_subtree_check,'<'strong'>'no_root_squash'<'/strong'>'</code>. Esto significa que <strong>cualquier usuario root del cliente puede escribir como root en el export</strong> — apropiado para una LAN doméstica de confianza pero nunca para una red no confiable. Si tu CT es alcanzable desde un segmento no confiable (una red pública, un VPS, una VLAN hostil), <strong>cambia las opciones del export a <code>root_squash</code></strong> en el diálogo de opciones custom."
},
"opening": {
"heading": "Abrir la herramienta",
"body": "Desde el menú principal de ProxMenux, abre <strong>Storage &amp; Share Manager → Configure NFS Server in LXC (only privileged)</strong>. ProxMenux te pide primero elegir el CT destino (y lo arranca si está parado); aborta si es unprivileged. Una vez seleccionado el CT ves este submenú con cinco opciones:",
"imageAlt": "Menú NFS Server Manager — Create / View / Delete / Status / Uninstall"
},
"howRuns": {
"heading": "Cómo se ejecuta el script (flujo Create)"
},
"network": {
"heading": "ACL de red — quién puede montar el share",
"intro": "El campo network en <code>/etc/exports</code> filtra qué clientes pueden montar. ProxMenux ofrece tres modos:",
"headerMode": "Modo",
"headerValue": "Valor escrito en /etc/exports",
"headerWhen": "Cuándo elegirlo",
"rows": [
{
"mode": "Red local",
"value": "192.168.0.0/16",
"whenRich": "LAN doméstica / SOHO estándar. Cubre cada dirección <code>192.168.*.*</code>."
},
{
"mode": "Subnet personalizada",
"value": "tu CIDR (p. ej. 10.0.0.0/24)",
"when": "Cuando tu LAN no está en 192.168.x.x o quieres un alcance más estrecho."
},
{
"mode": "Host único",
"value": "tu IP (p. ej. 10.0.0.42)",
"when": "Solo una máquina específica debería montar. La más restrictiva."
}
]
},
"options": {
"heading": "Opciones de export explicadas",
"headerOption": "Opción",
"headerEffect": "Qué hace",
"rows": [
{
"option": "rw / ro",
"effect": "Permitir acceso de lectura-escritura o solo lectura para los clientes que conecten."
},
{
"option": "sync",
"effectRich": "Responder a las peticiones de escritura solo después de que los datos estén en disco. Más seguro que <code>async</code> a costa de throughput."
},
{
"option": "no_subtree_check",
"effect": "Saltar la comprobación por petición de que el archivo sigue dentro del subárbol exportado. Más rápido y evita problemas cuando los archivos se renombran a mitad de operación."
},
{
"option": "no_root_squash",
"effectRich": "<strong>Confiar en el root del cliente.</strong> Un cliente que monte como root escribe como root en el servidor. Bueno para LANs de confianza (p. ej. herramientas de backup necesitan preservar la propiedad). Reemplázalo con <code>root_squash</code> si no confías plenamente en cada máquina de la ACL de red."
}
]
},
"manual": {
"heading": "Equivalente manual",
"body": "Reproduce el flujo entero a mano — cada comando se ejecuta <strong>dentro del CT</strong> vía <code>pct exec &lt;ctid&gt; --</code> o <code>pct enter &lt;ctid&gt;</code>:"
},
"view": {
"heading": "Ver exports actuales",
"body": "Cat de <code>/etc/exports</code> desde dentro del CT (saltando comentarios / blancos) e imprime cada export con su ACL de red y cadena de opciones. Útil para comprobar qué carpetas están expuestas antes de compartir la IP del CT con alguien."
},
"delete": {
"heading": "Eliminar un export",
"body": "Lista cada línea en <code>/etc/exports</code> para selección, elimina la elegida (<code>sed -i</code>), ejecuta <code>exportfs -ra</code> y reinicia <code>nfs-kernel-server</code>. La propia carpeta y su contenido se dejan intactos."
},
"status": {
"heading": "Comprobar estado NFS",
"body": "Pasada de diagnóstico: confirma que <code>nfs-kernel-server</code> y <code>rpcbind</code> están instalados y activos, imprime la salida de <code>exportfs -v</code>, lista las sesiones NFS activas (<code>showmount -a</code>) y las conexiones de cliente actuales."
},
"uninstall": {
"heading": "Desinstalar servidor NFS",
"body": "Limpieza completa tras confirmación: para + deshabilita <code>nfs-kernel-server</code> y <code>rpcbind</code>, vacía <code>/etc/exports</code>, hace <code>apt-get purge</code> de los paquetes NFS, elimina el grupo <code>sharedfiles</code> y los usuarios <code>remap_*</code>, mata cualquier proceso residual. Las <strong>propias carpetas exportadas no se borran</strong> — solo la configuración NFS y los paquetes.",
"warnTitle": "El script se detiene en la línea del export, no en los datos",
"warnBody": "Tanto <em>Delete export</em> como <em>Uninstall NFS server</em> eliminan la configuración del export. Los datos en la carpeta exportada se preservan. Para borrar también los datos, hazlo explícitamente con <code>rm -rf</code> después de que el script termine — y haz backup primero si alguien todavía podría necesitarlos."
},
"troubleshoot": {
"heading": "Solución de problemas",
"privTitle": "Contenedor privileged requerido (el script aborta)",
"privBody": "El CT seleccionado es unprivileged. <code>nfs-kernel-server</code> no puede arrancar ahí porque montar <code>/proc/fs/nfsd</code> necesita <code>CAP_SYS_ADMIN</code> en el namespace del kernel del host, y el módulo <code>nfsd</code> tampoco está expuesto al namespace del contenedor (<code>modprobe nfsd</code> desde dentro devuelve <code>FATAL: Module nfsd not found</code>). Si te saltas el gate, verás <code>rpc.nfsd: Unable to access /proc/fs/nfsd errno 2 (No such file or directory)</code> en el journal y ningún puerto NFS llegará a abrirse. Las únicas opciones viables son: convertir el CT a privileged, o mover el servidor NFS a una VM.",
"aptTitle": "apt-get install falla",
"aptIntro": "El script asume un CT de la familia Debian. En Alpine / Arch / Rocky / Alma, instala los paquetes del servidor NFS a mano:",
"aptItems": [
"Alpine: <code>apk add nfs-utils</code>",
"Arch: <code>pacman -S nfs-utils</code>",
"Rocky / Alma: <code>dnf install nfs-utils</code>"
],
"aptOutro": "Después reejecuta el script de ProxMenux — el paso de instalación se salta cuando las herramientas ya están presentes.",
"aclTitle": "El cliente no puede montar: 'access denied by server'",
"aclBody": "La IP del cliente está fuera de la ACL de red que configuraste. Vuelve a crear el export con una subnet más amplia, o añade la IP exacta del cliente. Pega común: los clientes que conectan a través de NAT del router pueden aparecer con la IP WAN del router, no la IP LAN del cliente — comprueba en el servidor con <code>tcpdump -n port 2049</code>.",
"ownTitle": "Los archivos escritos por el cliente aparecen con propiedad rara en el servidor",
"ownIntro": "Dos posibilidades:",
"ownItems": [
"Con <code>no_root_squash</code> (por defecto), el root del cliente escribe como root en el servidor. Los archivos pertenecen a <code>root:sharedfiles</code> gracias al SGID de la carpeta.",
"Los usuarios cliente no-root escriben como su propio UID/GID. Si su UID no existe en el servidor, los archivos aparecen con números raw (p. ej. <code>1234:1234</code>). Usa el grupo <code>sharedfiles</code> también en el cliente, o alinea UIDs entre los sistemas que comparten archivos."
],
"noShowTitle": "El servidor es alcanzable pero showmount no devuelve nada",
"noShowBody": "Tras editar <code>/etc/exports</code>, debes recargar la tabla de exports con <code>exportfs -ra</code> y reiniciar <code>nfs-kernel-server</code> — el script hace ambas cosas, pero si editaste el archivo a mano, hazlo tú. Confirma también que el firewall en el CT (y en el host Proxmox) permite TCP/UDP 2049 y el puerto rpcbind (111)."
},
"related": {
"heading": "Relacionado",
"items": [
{
"href": "/docs/storage-share/lxc-nfs-client",
"label": "Cliente NFS en LXC",
"tail": " — el inverso: monta shares NFS externos desde dentro de un CT."
},
{
"href": "/docs/storage-share/lxc-samba-server",
"label": "Servidor Samba en LXC",
"tail": " — página hermana, mismo patrón con SMB / CIFS en vez de NFS."
},
{
"href": "/docs/storage-share/host-nfs",
"label": "Share NFS como almacenamiento de Proxmox",
"tailRich": " — una vez que tu CT esté exportando, registra ese share NFS en Proxmox para que aparezca bajo <em>Datacenter → Storage</em>."
}
]
}
}

155
web/messages/es/docs/storage-share/lxc-samba-client.json Normal file
View File

@@ -0,0 +1,155 @@
{
"meta": {
"title": "Cliente Samba en LXC | ProxMenux Documentation",
"description": "Monta shares Samba / CIFS directamente desde dentro de un contenedor LXC de Proxmox con ProxMenux. Auto-instala cifs-utils + smbclient, soporta auto-descubrimiento, almacenamiento seguro de credenciales y montajes persistentes vía /etc/fstab. Requiere un contenedor privileged.",
"ogTitle": "Cliente Samba en LXC | ProxMenux Documentation",
"ogDescription": "Monta shares Samba / CIFS desde dentro de un contenedor LXC privileged. Auto-descubrimiento, archivo seguro de credenciales, persistencia en /etc/fstab."
},
"header": {
"title": "Cliente Samba en LXC",
"description": "Monta shares Samba (SMB / CIFS) directamente desde dentro de un contenedor LXC de Proxmox. El contenedor se convierte en un cliente CIFS real — habla con el servidor Samba sobre la red, ejecuta mount.cifs, guarda las credenciales de forma segura y escribe en /etc/fstab. ProxMenux instala cifs-utils + smbclient por ti y valida las credenciales contra el servidor antes de montar.",
"section": "Almacenamiento y compartición · LXC"
},
"privReq": {
"title": "Contenedor privileged requerido",
"body": "El cliente <code>mount.cifs</code> del kernel necesita capabilities (<code>SYS_ADMIN</code> como mínimo) que los contenedores LXC unprivileged no exponen. El script lo impone — te pide elegir un CT y <strong>aborta si es unprivileged</strong>. Si necesitas el share dentro de un CT unprivileged, móntalo en el host Proxmox primero (con <hostSambaLink>Samba / CIFS como almacenamiento de Proxmox</hostSambaLink>) y hazle bind mount en el CT con el <mountLink>LXC Mount Manager</mountLink>."
},
"what": {
"heading": "Qué hace",
"body": "El contenedor habla CIFS sobre la red y monta el share por su cuenta. El host Proxmox es solo el puente de red — no ve ni gestiona el montaje.",
"diagramServerLabel": "Servidor Samba",
"diagramServerDetail": "//srv/share",
"diagramHostLabel": "Host Proxmox",
"diagramHostDetail": "(solo un\npuente de red)",
"diagramCtLabel": "LXC (privileged)",
"diagramCtDetail": "/mnt/share\nmount.cifs dentro del CT",
"diagramArrow": "CIFS",
"twoWaysTitle": "Dos formas de dar a un CT un share Samba — elige una",
"twoWaysBind": "<strong>Bind mount vía host</strong> (<mountLink>LXC Mount Manager</mountLink>): el host monta el CIFS una vez, cada CT hace bind mount de la misma ruta. Funciona con CTs unprivileged. Recomendado cuando varios CTs necesitan el mismo share.",
"twoWaysDirect": "<strong>Montaje CIFS directo dentro del CT</strong> (esta página): el CT monta el CIFS él mismo. Requiere privileged. Útil cuando el CT debe poseer sus propias credenciales, o cuando cada CT habla con un servidor diferente."
},
"opening": {
"heading": "Abrir la herramienta",
"body": "Desde el menú principal de ProxMenux, abre <strong>Storage &amp; Share Manager → Configure Samba Client in LXC (only privileged)</strong>. ProxMenux te pide primero <strong>elegir el CT destino</strong> (y lo arranca si está parado); aborta si es unprivileged. Una vez seleccionado el CT ves este submenú:",
"imageAlt": "Menú Samba Client Manager — Mount / View / Unmount / Test connectivity"
},
"howRuns": {
"heading": "Cómo se ejecuta el script (flujo Mount)"
},
"creds": {
"heading": "Dónde vive la contraseña",
"body": "ProxMenux <strong>nunca guarda la contraseña en texto plano</strong> en el comando de montaje ni en <code>/etc/fstab</code>. En su lugar escribe un archivo de credenciales dentro del CT:",
"whyTitle": "Por qué un archivo separado en vez de fstab",
"whyBody": "El módulo CIFS acepta opciones <code>username=</code> / <code>password=</code> en línea en fstab, pero cualquiera que pueda leer <code>/etc/fstab</code> ve la contraseña en claro. Poner las credenciales en un archivo solo para root y apuntar fstab a él (<code>credentials=</code>) mantiene la contraseña fuera de la config legible por todos."
},
"options": {
"heading": "Opciones de montaje explicadas",
"headerOption": "Opción",
"headerEffect": "Qué hace",
"rows": [
{
"option": "rw / ro",
"effect": "Modo lectura-escritura o solo lectura para el montaje entero."
},
{
"option": "file_mode=0664",
"effect": "Permisos reportados para archivos vía CIFS. Por defecto deja escribir a owner+group, leer a others."
},
{
"option": "dir_mode=0775",
"effect": "Permisos reportados para directorios. Por defecto deja entrar y crear a owner+group, atravesar a others."
},
{
"option": "iocharset=utf8",
"effect": "Forzar UTF-8 para los nombres de archivo que vienen por la red. Evita mojibake en nombres no-ASCII."
},
{
"option": "credentials=file",
"effect": "Leer usuario / contraseña del archivo (añadido automáticamente para auth de usuario)."
},
{
"option": "guest",
"effect": "Autenticar como guest, sin credenciales (añadido automáticamente cuando se elige guest)."
},
{
"option": "_netdev",
"effect": "Le dice al sistema init que este montaje necesita la red. El arranque no se bloquea esperándolo."
},
{
"option": "x-systemd.automount",
"effect": "Montaje lazy: solo monta en el primer acceso. Un servidor CIFS inalcanzable al arrancar no atasca el CT."
},
{
"option": "noauto",
"effect": "Salta el montaje eager al arrancar. Combinado con la unit automount, el montaje se establece de forma lazy."
}
],
"netEffectTitle": "Efecto neto de los flags fstab",
"netEffectBody": "Tu contenedor siempre arranca, incluso si el servidor Samba está offline. La primera vez que algo toca la ruta de montaje, systemd lo monta silenciosamente. Si el servidor sigue caído, ese único acceso falla con <em>resource temporarily unavailable</em> — pero nada más en el CT se ve afectado."
},
"manual": {
"heading": "Equivalente manual",
"body": "Reproduce el flujo entero a mano — cada comando se ejecuta <strong>dentro del CT</strong> vía <code>pct exec &lt;ctid&gt; --</code> o directamente vía <code>pct enter &lt;ctid&gt;</code>:",
"guestIntro": "Variante guest — sin archivo de credenciales:"
},
"view": {
"heading": "Ver montajes actuales",
"body": "Lista cada punto de montaje CIFS activo dentro del CT (<code>mount -t cifs</code>) más cada línea CIFS en el <code>/etc/fstab</code> del CT. Para cada entrada fstab se muestra el estado del montaje en vivo — útil para detectar montajes permanentes que no se levantaron al arrancar."
},
"unmount": {
"heading": "Desmontar share Samba",
"body": "Combina los montajes en vivo y las entradas fstab en una sola lista, te deja elegir uno y <strong>elimina la línea correspondiente de <code>/etc/fstab</code></strong> más el archivo de credenciales asociado. El script no ejecuta <code>umount</code> en el montaje en vivo — en su lugar te dice que hace falta un reinicio del CT para que el desmontaje surta efecto.",
"warnTitle": "El script elimina entradas fstab, no montajes en vivo",
"warnBody": "Mismo diseño que el cliente NFS: <code>umount</code> en un montaje ocupado falla con \"device busy\". Eliminar la entrada fstab garantiza que el montaje desaparezca limpiamente en el siguiente arranque del CT. Si quieres el montaje fuera <em>ya</em>, ejecuta <code>pct exec &lt;ctid&gt; -- umount /mnt/&lt;path&gt;</code> a mano después de que el script termine."
},
"test": {
"heading": "Probar conectividad Samba",
"body": "Pasada de diagnóstico dentro del CT: confirma que <code>cifs-utils</code> está instalado, lista los montajes CIFS actuales y luego, por cada servidor referenciado en fstab, comprueba ping → puertos 139/445 → listado guest. \"Requires authentication\" en el test de guest es normal para cualquier servidor que no exponga shares públicos."
},
"troubleshoot": {
"heading": "Solución de problemas",
"privTitle": "Contenedor privileged requerido (el script aborta)",
"privBody": "El CT seleccionado es unprivileged. El cliente CIFS del kernel necesita la capability <code>SYS_ADMIN</code> que los CTs unprivileged no exponen. O bien convierte el CT a privileged, o usa la ruta alternativa descrita en el aviso al inicio de esta página.",
"aptTitle": "apt-get install falla",
"aptIntro": "El script asume un CT de la familia Debian (<code>apt-get</code>). En Alpine / Arch / Rocky / Alma, instala el cliente CIFS a mano:",
"aptItems": [
"Alpine: <code>apk add cifs-utils samba-client</code>",
"Arch: <code>pacman -S cifs-utils smbclient</code>",
"Rocky / Alma: <code>dnf install cifs-utils samba-client</code>"
],
"aptOutro": "Después reejecuta el script de ProxMenux — el paso de instalación se salta cuando las herramientas ya están presentes.",
"guestFallbackTitle": "\"The server connected you as guest instead of the specified user\"",
"guestFallbackBody": "La validación activa del script detectó un problema real de auth. El servidor aceptó la conexión pero la degradó a guest porque las credenciales son incorrectas. Causas comunes: typo en el usuario / contraseña, el usuario no existe en el servidor, el usuario está bloqueado o el workgroup / dominio no coincide. Reejecuta el flujo y vuelve a introducir las credenciales con cuidado (la contraseña queda oculta en el diálogo).",
"denyTitle": "\"NT_STATUS_ACCESS_DENIED\" al montar",
"denyBody": "Las credenciales se validaron pero el share deniega el acceso. Comprueba en el lado del servidor si el usuario tiene permisos en ese share específico (la validación solo confirma el login, no las ACLs por share). Comprueba también si el servidor requiere una versión específica del protocolo SMB: añade <code>vers=3.0</code> (o <code>2.1</code>, <code>2.0</code>) a las opciones de montaje.",
"utf8Title": "Nombres de archivo UTF-8 / no-ASCII salen estropeados",
"utf8Body": "Las opciones por defecto incluyen <code>iocharset=utf8</code>, pero algunas configuraciones de servidor reportan un codepage inesperado. Si los nombres con acentos / símbolos se ven mal, prueba también <code>nounix</code> (algunos servidores Samba Linux lo necesitan cuando el cliente también es Linux) o pon en el lado del servidor <code>unix extensions = no</code>.",
"bootTitle": "El montaje permanente tiene éxito pero no se levanta al arrancar",
"bootBody": "Casi siempre uno de: la red no está lista cuando el CT monta (los flags <code>_netdev,x-systemd.automount,noauto</code> del script lo arreglan), el servidor es inalcanzable al arrancar (auto-mount espera al primer acceso — eso es normal) o DNS no resuelto al arrancar (usa la IP del servidor, no su hostname)."
},
"related": {
"heading": "Relacionado",
"items": [
{
"href": "/docs/storage-share/lxc-mount-points",
"label": "Puntos de montaje LXC (host ↔ contenedor)",
"tail": " — la alternativa para CTs unprivileged: monta en host, bind en CT."
},
{
"href": "/docs/storage-share/lxc-nfs-client",
"label": "Cliente NFS en LXC",
"tail": " — página hermana, mismo patrón para shares NFS."
},
{
"href": "/docs/storage-share/lxc-samba-server",
"label": "Servidor Samba en LXC",
"tailRich": " — el inverso: expone carpetas <em>desde</em> un CT por Samba."
},
{
"href": "/docs/storage-share/host-samba",
"label": "Samba / CIFS como almacenamiento de Proxmox",
"tail": " — registra el share en el propio Proxmox en vez de dentro de un único CT."
}
]
}
}

132
web/messages/es/docs/storage-share/lxc-samba-server.json Normal file
View File

@@ -0,0 +1,132 @@
{
"meta": {
"title": "Servidor Samba en LXC | ProxMenux Documentation",
"description": "Ejecuta un servidor Samba (SMB / CIFS) dentro de un contenedor LXC de Proxmox con ProxMenux. Auto-instala samba, gestiona /etc/samba/smb.conf, usuarios smbpasswd, grupo sharedfiles para carpetas bind-mounted. Requiere un contenedor privileged.",
"ogTitle": "Servidor Samba en LXC | ProxMenux Documentation",
"ogDescription": "Expón carpetas por SMB/CIFS desde dentro de un contenedor LXC privileged. Auto-instalación, usuario smbpasswd, permisos conscientes de bind mount."
},
"header": {
"title": "Servidor Samba en LXC",
"description": "Ejecuta un servidor Samba (SMB / CIFS) dentro de un contenedor LXC de Proxmox y expón carpetas a clientes Windows / macOS / Linux en la red. ProxMenux instala samba, crea un usuario Samba con smbpasswd, gestiona /etc/samba/smb.conf y aplica permisos conscientes de bind mount cuando la carpeta compartida viene del host.",
"section": "Almacenamiento y compartición · LXC"
},
"privReq": {
"title": "Contenedor privileged requerido",
"body": "Samba impersona al usuario que conecta con <code>setgroups()</code> en cada tree connection (el momento en el que un cliente abre un share). En un LXC unprivileged, el kernel rechaza esa syscall porque el namespace de usuario del contenedor se crea con <code>setgroups=deny</code> — y <code>smbd</code> responde abortando el proceso worker con <code>PANIC: sys_setgroups failed</code>. El resultado es que <code>smbd</code> arranca y bindea los puertos 139/445, pero cada conexión de cliente falla con <code>NT_STATUS_CONNECTION_DISCONNECTED</code>. El script impone un CT privileged por esta razón y <strong>aborta si es unprivileged</strong>. No hay arreglo limpio del lado del servidor; usa un CT privileged, o ejecuta Samba dentro de una VM."
},
"what": {
"heading": "Qué hace",
"body": "El contenedor se convierte en un servidor SMB/CIFS: ejecuta <code>smbd</code>, expone una carpeta vía <code>/etc/samba/smb.conf</code> y acepta conexiones de cliente en los puertos <code>139</code> / <code>445</code>. Los clientes ven el share en <code>\\\\&lt;ct-ip&gt;\\&lt;share-name&gt;</code> en el Explorador de Windows, <code>smb://&lt;ct-ip&gt;/&lt;share-name&gt;</code> en el Finder de macOS, o vía <code>mount.cifs</code> en Linux.",
"diagramServerLabel": "LXC (privileged) — servidor Samba",
"diagramServerDetail": "/mnt/data\n(carpeta que expones)\n\nsmbd + nmbd corriendo\n\nUsuario: <username>\n(vía smbpasswd)\n\nForce group:\nsharedfiles",
"diagramClientLabel": "Cualquier cliente en la red",
"diagramClientDetail": "Windows: \\\\<ip>\\<share>\nmacOS: smb://<ip>/<share>\nLinux: mount.cifs",
"diagramArrow": "SMB / CIFS"
},
"perms": {
"heading": "Dos rutas de permisos según el tipo de carpeta",
"body": "Antes de añadir el share a <code>smb.conf</code>, el script comprueba si la carpeta elegida es un <strong>bind mount desde el host</strong> o una <strong>carpeta local normal dentro del CT</strong> — y aplica propiedad / permisos diferentes en consecuencia:",
"headerType": "Tipo de carpeta",
"headerAction": "Qué hace el script",
"bindType": "Bind mount desde host",
"bindTypeSubRich": "detectado vía salida de <code>mount</code>",
"bindActionRich": "Crea el grupo <code>sharedfiles</code> (GID por defecto 999, dinámico si está cogido), añade el usuario Samba a él, luego <code>chown root:sharedfiles</code> + <code>chmod 2775</code> (SGID — los archivos nuevos heredan el grupo). Si el usuario todavía no puede escribir, aplica <code>setfacl -m u:&lt;user&gt;:rwx</code>.",
"localType": "Carpeta local dentro del CT",
"localTypeSub": "sin bind mount detectado",
"localActionRich": "Propiedad estándar: <code>chown -R &lt;user&gt;:&lt;user&gt;</code> + <code>chmod -R 755</code>. No hace falta grupo compartido porque ningún otro CT escribe en esta carpeta. Cae a <code>setfacl</code> si el acceso de escritura sigue faltando.",
"gidTitle": "El GID de 'sharedfiles' difiere del flujo del servidor NFS",
"gidBody": "El script del servidor Samba usa el GID <strong>999</strong> para <code>sharedfiles</code>, mientras que el <nfsLink>flujo del servidor NFS</nfsLink> usa el GID <strong>101000</strong>. Si ejecutas ambos servidores en el mismo CT y quieres un único grupo compartido entre ambos protocolos, edita uno de ellos para que coincida con el otro tras la instalación (p. ej. <code>groupmod -g 101000 sharedfiles</code>) y reaplica la propiedad en las carpetas afectadas. Es una inconsistencia conocida en los scripts actuales."
},
"opening": {
"heading": "Abrir la herramienta",
"body": "Desde el menú principal de ProxMenux, abre <strong>Storage &amp; Share Manager → Configure Samba Server in LXC (only privileged)</strong>. ProxMenux te pide primero elegir el CT destino (y lo arranca si está parado); aborta si es unprivileged. Una vez seleccionado el CT ves este submenú con cinco opciones:",
"imageAlt": "Menú Samba Server Manager — Create / View / Delete / Status / Uninstall"
},
"howRuns": {
"heading": "Cómo se ejecuta el script (flujo Create)"
},
"modes": {
"heading": "Los tres modos de share",
"intro": "Cada modo escribe una stanza diferente en <code>smb.conf</code>. Los tres incluyen <code>valid users = &lt;username&gt;</code> (sin anónimo), <code>force group = sharedfiles</code> (para que los archivos nuevos pertenezcan al grupo compartido) y <code>veto files = /lost+found/</code> (lo oculta a los clientes).",
"headerMode": "Modo",
"headerBlock": "Bloque escrito en smb.conf",
"rwMode": "Read-Write",
"roMode": "Read-Only",
"customMode": "Custom",
"customBodyRich": "Tú escribes tus propias directivas en un cuadro de texto libre. ProxMenux igualmente las envuelve en un bloque <code>[share]</code> con los <code>path</code>, <code>valid users</code>, <code>force group</code> y <code>veto files</code> estándar."
},
"manual": {
"heading": "Equivalente manual",
"body": "Reproduce el flujo entero a mano — cada comando se ejecuta <strong>dentro del CT</strong> vía <code>pct exec &lt;ctid&gt; --</code> o <code>pct enter &lt;ctid&gt;</code>:"
},
"connect": {
"heading": "Conectar desde clientes",
"headerOs": "SO cliente",
"headerHow": "Cómo conectar",
"windowsOs": "Windows",
"windowsHowRich": "Explorador de archivos → barra de direcciones: <code>\\\\&lt;ct-ip&gt;\\&lt;share-name&gt;</code>. O <em>Conectar a unidad de red</em> → marca \"Conectar usando credenciales diferentes\".",
"macosOs": "macOS",
"macosHowRich": "Finder → <em>Ir → Conectarse al servidor…</em> → <code>smb://&lt;ct-ip&gt;/&lt;share-name&gt;</code>. O <code>mount_smbfs //user@&lt;ct-ip&gt;/&lt;share&gt; /mountpoint</code>.",
"linuxOs": "Linux",
"linuxHowRich": "<code>mount -t cifs //&lt;ct-ip&gt;/&lt;share&gt; /mnt/x -o username=&lt;u&gt;,password=&lt;p&gt;,iocharset=utf8</code>. O usa la página <clientLink>Cliente Samba en LXC</clientLink> si el cliente es otro CT Proxmox."
},
"view": {
"heading": "Ver shares actuales",
"body": "Parsea <code>/etc/samba/smb.conf</code> dentro del CT y lista cada bloque <code>[share]</code> (saltando <code>[global]</code>, <code>[homes]</code>, <code>[printers]</code>) con su path. Útil como inventario rápido."
},
"delete": {
"heading": "Eliminar un share",
"body": "Te deja elegir un share por nombre, elimina el bloque de <code>smb.conf</code> (<code>sed</code> borra desde <code>[share]</code> hasta la siguiente línea en blanco) y reinicia <code>smbd</code>. La propia carpeta y su contenido se dejan intactos."
},
"status": {
"heading": "Comprobar estado Samba",
"body": "Informa de si <code>smbd</code> y <code>nmbd</code> están instalados y activos, lista los usuarios Samba (<code>pdbedit -L</code>) e imprime las sesiones activas (<code>smbstatus</code>)."
},
"uninstall": {
"heading": "Desinstalar servidor Samba",
"body": "Limpieza completa tras confirmación: para + deshabilita <code>smbd</code> y <code>nmbd</code>, hace backup de <code>smb.conf</code> a <code>smb.conf.backup.YYYYMMDD_HHMMSS</code>, elimina los usuarios Samba con <code>smbpasswd -x</code> y hace <code>apt-get purge</code> de los paquetes Samba. Las <strong>propias carpetas exportadas no se borran</strong>.",
"warnTitle": "Las carpetas sobreviven — haz backup de los datos por separado",
"warnBody": "Tanto <em>Delete share</em> como <em>Uninstall Samba server</em> eliminan la configuración del share. Los datos en las carpetas exportadas se preservan. Para borrar también los datos, hazlo explícitamente con <code>rm -rf</code> después de que el script termine."
},
"troubleshoot": {
"heading": "Solución de problemas",
"privTitle": "Contenedor privileged requerido (el script aborta)",
"privBody": "El CT seleccionado es unprivileged y <code>smbd</code> no puede servir archivos ahí. Si te saltas el gate y configuras Samba a mano, <code>smbd</code> arranca y los puertos se abren, pero la primera conexión de cliente entra en pánico con <code>PANIC: sys_setgroups failed</code> en <code>/var/log/samba/log.&lt;client&gt;</code> y el cliente ve <code>NT_STATUS_CONNECTION_DISCONNECTED</code>. La causa es que el namespace de usuario unprivileged tiene <code>setgroups=deny</code>, lo que bloquea la impersonación por conexión de Samba. Ni <code>features=keyctl=1</code> ni eliminar <code>force user</code> / <code>force group</code> cambian esto. Las únicas opciones viables son: convertir el CT a privileged, o mover Samba a una VM.",
"aptTitle": "apt-get install falla",
"aptIntro": "El script asume un CT de la familia Debian. En Alpine / Arch / Rocky / Alma, instala Samba a mano:",
"aptItems": [
"Alpine: <code>apk add samba</code>",
"Arch: <code>pacman -S samba</code>",
"Rocky / Alma: <code>dnf install samba</code>"
],
"aptOutro": "Después reejecuta el script de ProxMenux — el paso de instalación se salta cuando las herramientas ya están presentes.",
"noShareTitle": "El cliente conecta pero no puede ver el share",
"noShareBody": "Comprueba que <code>browseable = yes</code> está puesto en el bloque del share (por defecto para los modos rw / ro; puede faltar en custom). Comprueba también que el firewall del CT y el firewall del host Proxmox permiten TCP 445 (SMB) y 139 (NetBIOS). Algunos clientes Windows también requieren resolución de nombres — prueba la IP directamente primero.",
"authTitle": "La autenticación falla (NT_STATUS_LOGON_FAILURE)",
"authBody": "O bien la contraseña es incorrecta (las contraseñas Samba son <em>separadas</em> de las contraseñas de sistema — mira <code>pdbedit -L</code>) o el usuario no está en <code>valid users</code> para ese share. Resetea la contraseña con <code>smbpasswd &lt;user&gt;</code> dentro del CT.",
"groupTitle": "Los archivos escritos por el cliente aparecen con grupo incorrecto en el servidor",
"groupBody": "El script pone <code>force group = sharedfiles</code> en el bloque del share, así que los archivos nuevos deberían ser del grupo <code>sharedfiles</code>. Si no lo son, el bit SGID en el directorio padre puede haberse perdido (alguien ejecutó <code>chmod</code> a mano). Reaplica: <code>chmod 2775 /mnt/&lt;share&gt;</code>.",
"bothTitle": "Compartir la misma carpeta por NFS y Samba",
"bothBody": "ProxMenux usa GIDs diferentes para <code>sharedfiles</code> en cada script (Samba: 999, NFS: 101000). Si sirves la misma carpeta por ambos, decide un GID y alinea ambos. El fix más simple: tras ejecutar ambos scripts, edita el GID más pequeño:"
},
"related": {
"heading": "Relacionado",
"items": [
{
"href": "/docs/storage-share/lxc-samba-client",
"label": "Cliente Samba en LXC",
"tail": " — el inverso: monta shares Samba externos desde dentro de un CT."
},
{
"href": "/docs/storage-share/lxc-nfs-server",
"label": "Servidor NFS en LXC",
"tail": " — página hermana, mismo patrón con NFS en vez de CIFS."
},
{
"href": "/docs/storage-share/host-samba",
"label": "Samba / CIFS como almacenamiento de Proxmox",
"tailRich": " — una vez que tu CT esté exponiendo, registra ese share en Proxmox para que aparezca bajo <em>Datacenter → Storage</em>."
}
]
}
}