ZFS sharenfs/sharesmb: Conveniencia vs Control en Producción

Qué hacen realmente sharenfs/sharesmb (y qué no hacen)

sharenfs en una frase

sharenfs es una propiedad de dataset ZFS que puede instruir al host para exportar el dataset por NFS usando el subsistema de compartición de la plataforma, normalmente generando reglas de exportación dinámicamente y llamando al mecanismo de compartición del SO (no por arte de magia).

sharesmb en una frase

sharesmb es una propiedad de dataset ZFS que puede indicar al host publicar el dataset como un recurso SMB usando la integración del servicio SMB de la plataforma (en illumos/Solaris históricamente; en Linux depende de tu herramienta y de la integración de la distro).

Por qué importa: estás eligiendo una capa de orquestación

ZFS no habla NFS ni SMB por sí mismo. Delegar. Esas propiedades son, de hecho, un pequeño orquestador de shares pegado a los metadatos del sistema de ficheros. Eso es a la vez el atractivo y el riesgo: la definición de share viaja con el dataset, puede heredarse, clonarse y replicarse—y luego te sorprende más tarde porque sigue ahí.

La verdad incómoda: el comportamiento difiere según el SO y la “versión” de ZFS

En sistemas derivados de illumos (y la antigua línea Solaris), las propiedades de share son ciudadanos de primera clase: zfs share,
zfs unshare, integración con sharetab, compartición SMB mediante el gestor de servicios del SO—todo el paquete. En Linux con OpenZFS,
las propiedades existen, pero la activación de shares puede implementarse mediante scripts auxiliares, unidades systemd o configuraciones de empaquetado.
Algunos entornos tratan sharenfs como “metadatos que puedes consultar” y nada más hasta que instalas y habilitas los servicios adecuados.

Pregunta de control: ¿quieres que los shares se “declaren” en la capa ZFS (propiedades del dataset) o que se “declaren” en la capa de servicio
(/etc/exports, configuración de Samba, o un sistema de gestión de configuración)? Si no puedes responder con claridad, lo descubrirás a las 3 AM.

Lo que estas propiedades no hacen

• No hacen cumplir la seguridad a nivel de red. Solo influyen en la configuración de exportación/compartición.
• No reemplazan un diseño adecuado de identidad y permisos (mapeo UID/GID, ACLs, identidades SMB).
• No garantizan comportamiento consistente en toda tu flota a menos que tu tooling del SO sea consistente.
• No impiden que alguien edite /etc/exports o la configuración de Samba y se aparte de la intención de ZFS.

Una propiedad de share es como escribir “entregar en la puerta” en un paquete. Ayuda. No es un cerrojo en la puerta.

Conveniencia vs control: un estudio de trade-offs en producción

Cuando las propiedades de share son una ventaja

Usa sharenfs/sharesmb cuando quieras que el dataset sea auto-descriptivo, especialmente si:

• Provisiones y desprovisiones datasets con frecuencia (cachés de CI, espacios de trabajo de proyecto, sandboxes analíticos efímeros).
• Clonas datasets y quieres que la intención de compartición siga al clon (a veces sí, muchas veces no—resérvate esa reflexión).
• Usas replicación ZFS y quieres que el lado receptor sepa “este dataset está pensado para exportarse”, aunque no lo auto-exportes.
• Necesitas estado consistente y consultable: “¿Qué datasets están compartidos?” está a un zfs get de distancia.

Cuando las propiedades de share se vuelven un pasivo

Evita depender de ellas como tu plano de control principal cuando:

• Necesitas control de cambios explícito para exports/shares (requisitos de auditoría, aprobaciones de seguridad, segregación de funciones).
• Ejecutas múltiples stacks NFS/SMB o múltiples fuentes de configuración (exports editados a mano más auto-sharing ZFS más un sistema de orquestación).
• Usas replicación de datasets entre entornos (prod ↔ staging) donde las reglas de share no deberían seguir al dataset.
• Tienes comportamiento mixto del SO en tu flota (algunos nodos respetan las propiedades; otros las ignoran).

El verdadero trade-off: localidad del estado vs gobernanza

Las propiedades de share colocan el estado de compartición junto con los datos. Es elegante. También es un atajo de gobernanza. El movimiento clásico de ops es mantener la política de “qué se exporta a quién” en un solo lugar y tratar el sistema de ficheros como un detalle de implementación. Las propiedades de share invierten eso: el filesystem se convierte en el almacén de política.

Mi regla con opinión: si tienes más de un host de almacenamiento, trata las propiedades de share como metadatos declarativos y usa un mecanismo separado para decidir si honrarlas. Aún puedes usarlas—pero no dejes que una propiedad del dataset abra por sí sola agujeros en tu red.

Broma #1: “Auto-sharing es como las suscripciones con renovación automática: conveniente hasta que notas que se renovó en otro país.”

El filo oculto: herencia

Las propiedades ZFS se heredan hacia abajo en el árbol de datasets. Normalmente eso es una característica. Para la compartición, también es una trampa.
Poner sharenfs=on en un dataset padre puede exportar accidentalmente datasets administrativos internos, snapshots montados en otro lugar, o nuevos datasets hijos creados posteriormente por automatización. A la gente le encanta la herencia hasta que hereda en la dirección equivocada.

Otro filo: replicación y “drift” de shares

Cuando replicas datasets, puedes replicar propiedades también. Dependiendo de flags y tooling, el destino puede recibir valores de sharenfs/sharesmb que eran significativos en el origen pero peligrosos en el destino.
El modo de fallo no siempre es “se exporta inmediatamente”. A veces es peor: permanece como configuración latente hasta que una actualización de paquete o un reinicio del servicio empieza a respetar esas propiedades. Enhorabuena, acabas de mandar una bomba de relojería por replicación.

Control no significa editar todo a mano

La alternativa a las propiedades de share no es “editar /etc/exports a mano y rezar”. El control puede alcanzarse con:

• Gestión de configuración que genera exports y shares de Samba desde inventario y política.
• Un wrapper que lea propiedades ZFS y genere configuraciones de servicio, pero aplique una lista blanca y revisión.
• Separación de namespaces: un parent dataset donde está permitido compartir y todos los demás por defecto en “off”.

Quieres un sistema donde el estado por defecto sea aburrido y seguro, y las excepciones sean deliberadas.

Una idea parafraseada de Werner Vogels: “You build it, you run it.” En términos de almacenamiento: si pones la propiedad, eres responsable del radio de impacto.

Hechos y contexto histórico que realmente importan

1. El compartido ZFS nació en el mundo Solaris/illumos. La integración estrecha con los servicios de compartición del sistema no fue un añadido; era la experiencia de operador prevista.
2. La configuración de exportación NFS precede a ZFS por décadas. Las convenciones de /etc/exports se construyeron para sistemas de ficheros estáticos, no para toggles por dataset y herencia de propiedades.
3. SMB en Solaris tomó un camino distinto al de Samba. illumos/Solaris históricamente incluía un servidor SMB en kernel y tooling de servicio; Linux normalmente depende de Samba en espacio de usuario.
4. Las propiedades ZFS están diseñadas para herencia, clonación y replicación. Por eso compartir mediante propiedades se siente natural—y por eso puede replicar sorpresas junto con los datos.
5. Existía un estilo “sharetab” para responder “¿qué está exportado?” rápidamente. Los operadores querían una única fuente de verdad para shares activos antes de que existiera el descubrimiento de servicios moderno.
6. NFSv4 cambió el modelo mental. Pseudoroots y un único punto de exportación pueden ocultar o revelar límites de dataset de formas que confunden a equipos que crecieron con NFSv3.
7. La semántica de ACL diverge entre NFS y SMB. Incluso cuando ambos exponen el mismo dataset, la traducción del modelo de permisos no es simétrica y puede crear acertijos de “funciona en SMB, falla en NFS”.
8. El idmapping ha sido siempre el asesino silencioso. El share puede ser perfecto; problemas de mapeo UID/GID o SID seguirán haciendo que parezca “caído”.
9. OpenZFS en Linux mantuvo las propiedades por compatibilidad. Pero “la propiedad existe” no equivale a “la distribución habilita auto-share por defecto”.

Tareas prácticas: comandos, salidas y decisiones (12+)

Task 1: Listar qué datasets declaran que están compartidos

cr0x@server:~$ zfs get -r -o name,property,value,source sharenfs,sharesmb tank
NAME                 PROPERTY  VALUE  SOURCE
tank                 sharenfs  off    default
tank                 sharesmb  off    default
tank/projects        sharenfs  on     local
tank/projects        sharesmb  off    inherited from tank
tank/projects/acme   sharenfs  on     inherited from tank/projects
tank/projects/acme   sharesmb  off    inherited from tank
tank/backups         sharenfs  off    local
tank/backups         sharesmb  off    default

Qué significa: Ves tanto el valor como el SOURCE. La compartición heredada es lo primero a temer.
Decisión: Si un dataset se comparte por herencia sin querer, ponlo explícitamente:
zfs set sharenfs=off tank/projects/acme o arregla el padre.

Task 2: Verificar qué piensa el SO que está exportado por NFS

cr0x@server:~$ exportfs -v
/tank/projects  10.20.0.0/16(sync,wdelay,hide,no_subtree_check,sec=sys,rw,root_squash)
/tank/backups   10.30.5.42(sync,wdelay,hide,no_subtree_check,sec=sys,ro,root_squash)

Qué significa: Esta es la tabla de exports NFS en vivo (servidor NFS en Linux). Puede o no coincidir con las propiedades ZFS.
Decisión: Si zfs get sharenfs dice “on” pero exportfs no lo muestra, tu ruta de auto-share no está activa. Si exportfs muestra exports que no querías, tienes drift de configuración o un generador demasiado “útil”.

Task 3: Confirmar que el servicio de compartición está en ejecución (NFS)

cr0x@server:~$ systemctl status nfs-server --no-pager
● nfs-server.service - NFS server and services
     Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled)
     Active: active (exited) since Thu 2025-12-26 09:10:12 UTC; 3h 1min ago
       Docs: man:rpc.nfsd(8)

Qué significa: NFS está arriba a nivel de servicio. Si los clientes aún no pueden montar, pasa a exports, firewall y idmapping.
Decisión: Si está inactivo, no depures propiedades ZFS todavía—arranca el servicio y confirma puertos.

Task 4: Comprobar si el tooling de auto-share de ZFS está habilitado (ejemplo Linux)

cr0x@server:~$ systemctl status zfs-share --no-pager
● zfs-share.service - ZFS dataset share service
     Loaded: loaded (/lib/systemd/system/zfs-share.service; enabled)
     Active: active (exited) since Thu 2025-12-26 09:10:10 UTC; 3h 1min ago

Qué significa: En muchas configuraciones Linux, esta unidad intenta respetar sharenfs/sharesmb.
Decisión: Si está deshabilitada o falta, tus propiedades probablemente son “configuración en papel”. Decide si habilitarla o migrar totalmente a configuraciones de servicio explícitas.

Task 5: Forzar un re-share después de cambiar propiedades

cr0x@server:~$ sudo zfs share -a
cannot share 'tank/backups': property 'sharenfs' is off
tank/projects shared

Qué significa: El comando share aplica el estado actual de la propiedad. Algunas plataformas lo hacen automáticamente al aplicar zfs set; otras requieren un zfs share explícito o reinicio del servicio.
Decisión: Si la compartición no se aplica al cambiar la propiedad, incorpora “re-share” en tu runbook y automatización.

Task 6: Inspeccionar la cadena exacta de opciones en sharenfs (no solo on/off)

cr0x@server:~$ zfs get -o name,property,value sharenfs tank/projects
NAME           PROPERTY  VALUE
tank/projects  sharenfs  rw=@10.20.0.0/16,root_squash,sec=sys

Qué significa: Aquí la conveniencia se convierte en configuración: las cadenas de opciones pueden expresar política.
Decisión: Si permites cadenas de opciones, estandarízalas. Si no, prohíbelas y solo permite “on/off” más política centralizada.

Task 7: Validar que los mountpoints del dataset coinciden con lo que crees que estás exportando

cr0x@server:~$ zfs get -o name,property,value mountpoint tank/projects tank/projects/acme
NAME                PROPERTY    VALUE
tank/projects       mountpoint  /tank/projects
tank/projects/acme  mountpoint  /tank/projects/acme

Qué significa: Los exports suelen usar rutas. Si los mountpoints se cambiaron, renombraron o están montados por legado, puedes exportar
la ruta equivocada.
Decisión: Si los mountpoints no se alinean con tu esquema de nombres de export, corrige los mountpoints o exporta explícitamente por diseño.

Task 8: Confirmar que el dataset está realmente montado donde esperas

cr0x@server:~$ mount | grep -E '^tank/projects'
tank/projects on /tank/projects type zfs (rw,xattr,posixacl)
tank/projects/acme on /tank/projects/acme type zfs (rw,xattr,posixacl)

Qué significa: Si no está montado, la exportación NFS puede existir pero apuntar a un directorio vacío (o fallar).
Decisión: Si está desmontado, revisa canmount, mountpoint y el orden de servicios de montaje de ZFS.

Task 9: Comprobar propiedades ZFS que a menudo se confunden con compartición

cr0x@server:~$ zfs get -o name,property,value -s local,inherited canmount,readonly,acltype,xattr tank/projects
NAME           PROPERTY  VALUE
tank/projects  canmount  on
tank/projects  readonly  off
tank/projects  acltype   posixacl
tank/projects  xattr     sa

Qué significa: Si readonly=on, las escrituras fallan y la gente culpa a NFS. Si las configuraciones ACL/xattr difieren, SMB/NFS divergen.
Decisión: Alinea las expectativas de ACL/xattr con los casos de uso del protocolo. No “arregles” problemas de share cambiando aleatoriamente acltype.

Task 10: Desde un cliente, confirmar qué está ofreciendo el servidor (NFS)

cr0x@server:~$ showmount -e nfs01
Export list for nfs01:
/tank/projects 10.20.0.0/16

Qué significa: El cliente puede consultar la lista de exports (herramientas de la era NFSv3, pero aún útiles).
Decisión: Si showmount no devuelve nada, sospecha firewall/rpcbind/versiones NFS o export no aplicado en el servidor.

Task 11: Confirmar la versión NFS y opciones de montaje en el cliente

cr0x@server:~$ sudo mount -t nfs -o vers=4.1 nfs01:/tank/projects /mnt/projects
cr0x@server:~$ nfsstat -m | grep -A3 '/mnt/projects'
/mnt/projects from nfs01:/tank/projects
 Flags:	rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.4.18

Qué significa: Ves la versión NFS negociada y los tamaños. Si el montaje cae silenciosamente a v3 o usa UDP, eso es una pista.
Decisión: Si el rendimiento es malo, confirma que estás en TCP y en una versión moderna de NFS. Si los permisos son raros, revisa sec=.

Task 12: Confirmar el idmapping y problemas de “nobody:nogroup” temprano

cr0x@server:~$ getent passwd 1001
acmebuild:x:1001:1001:ACME Build User:/home/acmebuild:/usr/sbin/nologin
cr0x@server:~$ ls -ln /tank/projects/acme | head
total 3
drwxr-x---  5 1001 1001 5 Dec 26 09:11 build

Qué significa: La propiedad numérica de ownership coincide con una identidad. Si los clientes ven UID 1001 pero el servidor no, los permisos fallan.
Decisión: Si getent no resuelve IDs en alguno de los lados, arregla servicios de directorio/SSSD/LDAP antes de reescribir exports.

Task 13: Comprobar si existen shares SMB a nivel de servicio (Samba)

cr0x@server:~$ testparm -s | sed -n '1,120p'
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_STANDALONE

[projects]
	path = /tank/projects
	read only = No
	browsable = Yes

Qué significa: La compartición SMB en Linux la controla la configuración de Samba. sharesmb de ZFS puede no estar conectada.
Decisión: Si esperabas que ZFS creara shares de Samba automáticamente pero no aparecen aquí, deja de asumir. Escoge un plano de control y conéctalo explícitamente.

Task 14: Verificar shares SMB en vivo desde la vista de Samba

cr0x@server:~$ smbcontrol all reload-config
cr0x@server:~$ smbclient -L localhost -N | sed -n '1,80p'
	Sharename       Type      Comment
	---------       ----      -------
	projects        Disk
	IPC$            IPC       IPC Service (Samba Server)
SMB1 disabled -- no workgroup available

Qué significa: Ves si el share está siendo servido realmente. “Configurado” y “en vivo” son estados diferentes.
Decisión: Si está ausente, arregla la configuración/servicio Samba primero; no sigas alternando sharesmb con la esperanza de que genere stanzas de Samba.

Task 15: Detectar sorpresas de replicación en propiedades

cr0x@server:~$ zfs get -o name,property,value,source sharenfs,sharesmb -r tank/recv
NAME                 PROPERTY  VALUE  SOURCE
tank/recv            sharenfs  off    default
tank/recv            sharesmb  off    default
tank/recv/projects   sharenfs  on     received
tank/recv/projects   sharesmb  off    received

Qué significa: SOURCE=received es un gran letrero neón: la replicación entregó este estado.
Decisión: Si este es un host no productivo, fija una política: sobrescribir propiedades de share recibidas al llegar, o no honrarlas automáticamente.

Task 16: Confirmar si un dataset está “compartido” pero no accesible (firewall/puertos)

cr0x@server:~$ sudo ss -lntp | grep -E '(:2049|:111)\s'
LISTEN 0      64          0.0.0.0:2049      0.0.0.0:*    users:(("rpc.nfsd",pid=1432,fd=6))
LISTEN 0      128         0.0.0.0:111       0.0.0.0:*    users:(("rpcbind",pid=812,fd=4))

Qué significa: NFS y rpcbind están escuchando. Si no lo están, “exportado” no importa.
Decisión: Si los puertos no están escuchando, arregla los servicios. Si escuchan pero los clientes no pueden conectar, revisa ACLs de red.

Guía de diagnóstico rápido: qué comprobar primero/segundo/tercero

Esta es la secuencia de “deja de adivinar” cuando alguien dice “NFS está caído” o “el share SMB desapareció” tras un cambio de propiedad.
El objetivo es aislar si tienes un desajuste de plano de control, un problema de plano de servicio, o un
problema de datos/permisos.

Primero: ¿se supone que el dataset debe compartirse?

• Ejecuta zfs get sharenfs,sharesmb -r para el árbol de datasets.
• Mira SOURCE: local vs inherited vs received.
• Confirma mountpoint y canmount.

Si la propiedad es heredada y no la esperabas, ese es tu fallo. Arregla la jerarquía, no el síntoma.

Segundo: ¿el SO lo está exportando/serviendo realmente?

• NFS: exportfs -v y ss -lntp | grep 2049.
• SMB: testparm -s, luego smbclient -L localhost -N.
• Si dependes de auto-share ZFS: comprueba systemctl status zfs-share (o equivalente en tu plataforma).

Si ZFS dice “shared” pero la capa de servicio no está de acuerdo, tienes un problema de integración, no de permisos.

Tercero: ¿puede un cliente negociar y montar?

• NFS: monta desde el cliente con vers=4.1 explícito y comprueba nfsstat -m.
• SMB: intenta primero una conexión local por loopback y luego una remota para separar autenticación de red.

Si local funciona pero remoto falla, estás en territorio de firewall/ruteo/SELinux. Si remoto monta pero el acceso es denegado, estás en identidad/ACLs/opciones de export.

Cuarto: ¿la queja es rendimiento, no disponibilidad?

• Comprueba rsize/wsize negociados y el protocolo NFS.
• Revisa saturación de CPU en servidor (cifrado/firmado SMB puede consumir CPU).
• Revisa salud a nivel ZFS: estado del pool y latencias.

No “tunear NFS” hasta confirmar que ZFS no está ya asfixiándose con escrituras sync, un vdev degradado o un ARC agotado.

Tres microhistorias corporativas desde las trincheras de propiedades de share

Microhistoria 1: El incidente causado por una suposición errónea

Una empresa mediana tenía dos nodos de almacenamiento: uno para producción y otro para pruebas de recuperación ante desastres. El equipo replicaba datasets cada noche.
Usaban propiedades ZFS intensivamente porque hacía que el aprovisionamiento fuera limpio: crear dataset, poner cuota, definir sharenfs, listo.

Durante una prueba rutinaria de DR, un desarrollador montó un share de proyecto desde el nodo DR “solo para revisar un artefacto de build.” Se montó. Esa fue la primera sorpresa. La segunda sorpresa fue que también funcionó el acceso en escritura, porque las opciones de export se heredaron y eran permisivas.

Nadie había previsto que el nodo DR exportara nada más allá de una subred administrativa limitada. Pero los datasets replicados tenían sharenfs
como propiedad recibida. Y el nodo DR había sido actualizado recientemente, lo que habilitó una unidad de compartición que empezó a respetar esas propiedades en el arranque. Nadie conectó los puntos porque el cambio aterrizó en la capa del SO, no en la de ZFS.

El “incidente” no fue pérdida de datos, pero sí una falla de gobernanza: DR era ahora un destino de share paralelo a producción con supuestos de identidad obsoletos y controles de red más laxos. El postmortem encontró algo dolorosamente ordinario: asumieron “las propiedades se replican pero no hacen nada aquí.” Esa suposición fue verdadera hasta que dejó de serlo.

La solución fue igualmente ordinaria y efectiva: añadieron un trabajo en arranque en el nodo DR que forzaba sharenfs=off y
sharesmb=off para todos los datasets recibidos, luego aplicaron una lista blanca para los pocos exports administrativos que realmente necesitaban.
No elegante. Correcto.

Microhistoria 2: La optimización que salió mal

Otra organización quería “shares instantáneos” para una plataforma analítica interna. Su automatización creaba datasets por equipo bajo demanda.
Para evitar tocar /etc/exports por cada equipo, estandarizaron en poner sharenfs al crear el dataset con una regla basada en red, y habilitaron el procesamiento automático de shares.

Funcionó de maravilla durante meses. Luego se introdujo un nuevo dataset padre: tank/analytics. Alguien puso
sharenfs=rw=@10.50.0.0/16 en el padre para reducir boilerplate, esperando que los hijos fueran más restrictivos cuando fuera necesario.
Esa es la optimización: apoyarse en la herencia.

Un trimestre después, una revisión de cumplimiento encontró que un puñado de datasets destinados a una subred restringida eran exportables desde redes más amplias. No porque alguien los configurara mal localmente, sino porque esos datasets hijos nunca sobreescribieron la propiedad heredada.
Sus creadores asumieron “sin sharenfs explícito significa no compartido.” En ZFS, “sin explícito” a menudo significa “heredado”.

La remediación fue desordenada: auditar cada dataset, poner explícitamente sharenfs=off en árboles restringidos, y refactorizar la automatización para requerir una declaración explícita de share en el momento de creación (incluso si es “off”). La lección no fue “la herencia es mala.” La lección fue:
la herencia es una herramienta afilada, y no la entregas a cada pipeline sin guardarraíles.

Broma #2: “La herencia es genial—hasta que tus exports heredan el mismo entusiasmo que tus becarios.”

Microhistoria 3: La práctica aburrida pero correcta que salvó la noche

Una gran empresa ejecutaba cargas mixtas: NFS en Linux para clusters de cómputo, SMB para flujos de trabajo de oficina, y equipos de aplicación demandando excepciones. Eligieron una política poco sexy: las propiedades de share de ZFS están permitidas, pero no son autoritativas.

Concretamente: cada dataset podía llevar sharenfs o sharesmb como metadato, pero los hosts de almacenamiento no las aplicaban automáticamente. En su lugar, una pequeña herramienta interna corría cada noche y a demanda, leyendo esas propiedades, validándolas contra una lista blanca, y luego generando snippets para exports/Samba. Todos los cambios se revisaban como código.

Un día, la replicación trajo un árbol de datasets desde un entorno partner. Las propiedades recibidas incluían sharenfs=rw=@0.0.0.0/0
(sí, en serio). Si los hosts hubieran auto-shared, habría sido un incidente de seguridad. En su lugar, el generador lo marcó como inválido, se negó a aplicarlo, y mostró una alerta en el chat del equipo.

El equipo siguió teniendo la conveniencia operativa de “la intención de compartir sigue al dataset.” Pero mantuvieron la aplicación de políticas en un solo lugar.
La práctica era aburrida, y evitó una noche muy emocionante.

Errores comunes: síntoma → causa raíz → solución

1) “Pusimos sharenfs=on, pero los clientes no pueden montar.”

• Síntoma: zfs get sharenfs muestra “on”; el montaje del cliente falla con “access denied” o “no route to host”.
• Causa raíz: Servicio de auto-share no habilitado, o servicio NFS no en ejecución, o firewall bloqueando 2049/111.
• Solución: Verifica systemctl status zfs-share (o equivalente) y systemctl status nfs-server.
  Confirma puertos escuchando con ss. Luego verifica que exportfs -v muestre la ruta.

2) “Un dataset que debería ser privado está exportado.”

• Síntoma: exportfs -v lista un export inesperado; zfs get muestra compartición heredada.
• Causa raíz: sharenfs puesto en un dataset padre; el hijo lo heredó silenciosamente.
• Solución: Pon sharenfs=off en el padre, o explícitamente en los datasets hijos privados. Añade una comprobación de auditoría para evitar compartir a nivel padre salvo que sea una “frontera de export” deliberada.

3) “Tras replicación, los shares se comportan distinto en el destino.”

• Síntoma: El destino exporta inesperadamente, o no exporta hasta después de una actualización/reinicio.
• Causa raíz: Las propiedades recibidas incluyen settings de share; el destino ahora las respeta por cambios en servicios.
• Solución: Decide una política de replicación: eliminar/sobrescribir propiedades de share al recibir, o nunca ejecutar auto-share en receptores. Usa zfs get ... source para encontrar received.

4) “SMB funciona pero permisos NFS son incorrectos (o viceversa).”

• Síntoma: Mismo dataset, distinto resultado de acceso por protocolo.
• Causa raíz: Desajuste de id mapping, expectativas de ACL distintas, o opciones de export como root_squash mal interpretadas.
• Solución: Valida UIDs/GIDs con getent en servidor y cliente. Confirma propiedades ZFS ACL/xattr. Revisa opciones de export y módulos vfs de Samba si se usan.

5) “Apagamos sharenfs pero sigue exportado.”

• Síntoma: La propiedad dice off; exportfs -v todavía muestra el export.
• Causa raíz: El export existe en /etc/exports o en configuración generada fuera de ZFS; o no se aplicó el unshare.
• Solución: Encuentra la fuente autoritativa. Elimina el export de las configuraciones explícitas, luego ejecuta exportfs -ra. Si ZFS orquesta, ejecuta zfs unshare/zfs share -a según corresponda.

6) “Colisiones de nombres de share o rutas feas aparecen en la lista de navegación SMB.”

• Síntoma: Nombres de share duplicados, shares mal nombrados, o rutas incorrectas.
• Causa raíz: Shares SMB auto-generados a partir de nombres de datasets chocan con convenciones humanas; varios datasets mapean a nombres de share similares.
• Solución: No generes nombres de share SMB automáticamente desde rutas de datasets a menos que controles estrictamente la nomenclatura. Prefiere stanzas de Samba explícitas con nombres curados y trata sharesmb solo como metadato.

7) “El rendimiento se desplomó tras ‘tunear’ opciones de share.”

• Síntoma: Picos de latencia, timeouts en clientes, mayor CPU en servidor, o logs de bases de datos irritadas.
• Causa raíz: Habilitar semánticas costosas en sync sin intención (o deshabilitarlas sin entender), coste CPU por firmado/cifrado SMB, o mala negociación de rsize/wsize en NFS.
• Solución: Confirma los requisitos de durabilidad de la carga. Mide CPU del servidor y latencia ZFS. Fija versión NFS y transporte donde proceda. No copies opciones de montaje de internet sin pruebas.

Patrones operativos: cómo gestionarlo sin arrepentimientos

Patrón A: “Propiedades como metadatos, política en otro lado” (recomendado para la mayoría)

Permites a los equipos poner propiedades sharenfs/sharesmb, pero no las aplicas automáticamente. Un proceso controlado
las lee y genera exports/configuración de Samba tras validar:

• El dataset está en un subtree permitido (ej., tank/projects sí, tank/system no).
• Las opciones provienen de una lista blanca segura (no exports abiertos al mundo, no modos de seguridad inesperados).
• El cambio se revisa, audita y aplica de forma predecible.

Este patrón conserva el beneficio de “la intención de compartir sigue al dataset” sin permitir que una propiedad sea un motor de políticas de red.

Patrón B: “Un host, un propósito, auto-share está bien”

Si ejecutas un único appliance de almacenamiento o un entorno fuertemente controlado donde ZFS es el plano de control de shares por diseño (común
en appliances basados en illumos), auto-share puede ser perfectamente sensato. Pero aún necesitas:

• Fronteras estrictas en la jerarquía de datasets: solo se permite compartir en un subtree específico.
• Explicitar off en padres sensibles para evitar accidentes de herencia.
• Tareas de auditoría para detectar valores “on” inesperados, especialmente los heredados/recibidos.

Patrón C: “Solo configuraciones de servicio explícitas”

Este es el enfoque de control máximo: ignoras las propiedades de share y gestionas NFS/SMB mediante configuraciones de servicio y gestión de configuración.
Es viable, pero pierdes algo de introspección agradable. Si eliges esta ruta, al menos usa las propiedades como documentación:
colócalas en off por defecto y guarda los exports previstos en CMDB/inventario.

Dónde se queman los equipos: mezclar patrones

Las peores configuraciones son híbridas sin reglas:

• Algunos exports en /etc/exports, otros vía auto-share ZFS.
• Shares creados manualmente en Samba más propiedades ZFS que “a veces” crean shares.
• Automatización que pone propiedades pero nadie sabe si se aplican.

Si recuerdas una cosa: elige un plano de control autoritativo por protocolo. Todo lo demás es metadato.

Postura de seguridad: asume que las propiedades no son control de acceso

Trata las opciones de share como reglas de export NFS como una capa. Tu seguridad real está en segmentación de red, firewalls de host,
gestión de identidades y permisos/ACLs. Si dependes de “nadie pondrá sharenfs mal”, ya perdiste.

Listas de verificación / plan paso a paso

Checklist 1: Introducir sharenfs de forma segura en un entorno existente

1. Inventaria exports actuales: captura la salida de exportfs -v y guárdala.
2. Inventaria propiedades de share ZFS: zfs get -r sharenfs,sharesmb -o name,property,value,source.
3. Define una frontera de share: elige un dataset padre donde se permita tener shares debajo.
4. Establece valores seguros por defecto: pon sharenfs=off y sharesmb=off en padres que nunca deban compartir.
5. Decide el plano de control: auto-share en hosts, herramienta generadora o solo configuraciones explícitas.
6. Implementa auditoría: alerta sobre sharenfs=on fuera de la frontera, y alerta sobre source=received.
7. Prueba con un dataset: habilita el share, confirma que aparece en la capa de servicio, monta desde un cliente de prueba.
8. Despliega gradualmente: migra exports uno a uno; evita “activar la propiedad en el padre y rezar”.

Checklist 2: Manejar replicación hacia un entorno no autoritativo (DR/staging)

1. En el receptor, deshabilita auto-share salvo que tengas una razón sólida para habilitarlo.
2. Tras cada receive, escanea por props recibidas: zfs get -r -o name,property,value,source sharenfs,sharesmb.
3. Aplica la política: automáticamente pon sharenfs=off/sharesmb=off donde no se permitan shares.
4. Documenta excepciones: los pocos datasets que deben ser exportables en DR (normalmente ninguno) deben ser explícitos y revisados.

Checklist 3: Depurar un incidente reportado (NFS/SMB)

1. Confirma la intención: ¿se supone que el dataset esté compartido? Revisa propiedad y herencia.
2. Confirma estado de montaje: dataset montado, mountpoint correcto.
3. Confirma la capa de servicio: exportfs -v o smbclient -L desde el servidor.
4. Confirma accesibilidad de red: puertos escuchando y reglas de firewall.
5. Confirma mapeo de identidad: getent, ownership, comportamiento de ACL.
6. Sólo entonces optimiza rendimiento o toques opciones esotéricas.

Preguntas frecuentes (FAQ)

1) ¿Debo usar sharenfs/sharesmb en producción?

Sí, pero solo si eres explícito sobre el plano de control. Para entornos multi-host, úsalas como metadatos y aplica política mediante un
generador controlado o automatización allowlisted.

2) ¿Por qué “zfs set sharenfs=on” no exporta inmediatamente en mi host Linux?

Porque la propiedad no es el motor de exportación. Necesitas la capa de integración (a menudo una unidad systemd como zfs-share) y un servidor NFS en ejecución. Sin eso, es solo una propiedad almacenada.

3) ¿Puedo expresar opciones de export NFS dentro de sharenfs?

A menudo sí, dependiendo de la integración de la plataforma. Pero una vez que lo haces, creaste un segundo lenguaje de exports. Estandariza las cadenas de opciones, o prohíbelas y permite solo “on/off” más política centralizada.

4) ¿Cómo saber si una propiedad de share es heredada o recibida?

Usa zfs get -o name,property,value,source sharenfs,sharesmb. Si source es inherited o
received, trátalo como mayor riesgo y valídalo.

5) ¿Apagar sharenfs garantiza que el dataset no está exportado?

No. Solo afecta la ruta de export controlada por ZFS. El dataset aún podría estar exportado vía explícita en /etc/exports u otra herramienta. Confirma siempre con exportfs -v.

6) ¿Es buena idea usar sharesmb en Linux con Samba?

Usualmente no como plano de control autoritativo, porque Samba se configura mediante sus propios ficheros y herramientas. Usa sharesmb
como pista/metadato a menos que tengas una integración probada que genere config de Samba de forma fiable y segura.

7) ¿Cuál es el mayor riesgo de seguridad con propiedades de share?

Herencia y replicación. Una propiedad en el padre o una propiedad recibida puede exportar más de lo previsto, y puede activarse más tarde cuando cambien servicios. Audita shares heredados/recibidos y aplica fronteras.

8) ¿Cómo prevenir compartir accidental de nuevos datasets hijos?

No pongas compartir “on” en un padre amplio a menos que ese padre sea una frontera deliberada de export. Prefiere compartir explícito por dataset y pon sharenfs=off en padres sensibles como guardarraíl.

9) ¿Por qué la navegación SMB muestra shares extraños aunque los usuarios no puedan acceder?

La navegación refleja la configuración anunciada de shares, no el éxito de permisos. Puedes estar publicando shares automáticamente sin ACLs/mapeo de identidad coincidente. Arregla la definición del share y el modelo de permisos; no dependas de “totalmente que no pueden acceder”.

10) ¿Cuál es el enfoque más sencillo y seguro para un equipo pequeño?

Mantén sharenfs/sharesmb desactivados por defecto y gestiona NFS/SMB explícitamente. Si luego adoptas propiedades, hazlo solo dentro de un subtree dedicado y con un trabajo de auditoría.

Conclusión: siguientes pasos que puedes hacer esta semana

1. Audita ahora: ejecuta zfs get -r sharenfs,sharesmb -o name,property,value,source y encuentra sorpresas heredadas/recibidas.
2. Confirma la verdad: compara la intención ZFS con el estado de servicio en vivo usando exportfs -v y herramientas de Samba.
3. Elige un plano de control: “auto-share ZFS autoritativo” (raro) o “configuraciones de servicio autoritativas” (común) o “propiedades como metadatos + generador” (mejor a escala).
4. Dibuja fronteras: decide qué subtree de datasets puede compartirse y bloquea el resto explícitamente.
5. Escribe el runbook: incluye los pasos de diagnóstico rápido y las acciones de re-share/reload que tu plataforma requiera.

ZFS te da primitivas elegantes. Las propiedades de share pueden ser parte de esa elegancia, pero la producción no premia la elegancia a menos que también sea legible, auditada y aburrida bajo estrés. Elige conveniencia donde sea reversible. Elige control donde no lo sea.