Files
computer-playbook/roles/svc-storage-nfs-server
kevinveenbirkenbachandClaude Opus 5.5 9b7f25f2fe fix(svc-storage-nfs-client): stop requesting directory delegations from ganesha < 9.11
Every swarm job on ubuntu-26.04 runners (kernel 7.0) died at the NFS
probe write with `[Errno 121] Remote I/O error`. ganesha's NFSv4 debug log
in the rescue bundles shows the cause on every client, the same second as
the failure:

  Request 2: opcode 46 is OP_GET_DIR_DELEGATION
  Status of OP_GET_DIR_DELEGATION in position 2 = NFS4ERR_OP_ILLEGAL

Linux 6.19 added directory delegations: after ACCESS, CREATE, REMOVE or
RENAME the client adds GET_DIR_DELEGATION to the directory's next GETATTR
(`should_request_dir_deleg`, gated per request by the nfsv4 parameter
`directory_delegations`). nfs-ganesha before 9.11 routes op 46 to
`nfs4_op_illegal`, whose reply carries opcode 10044; the client decoder
expects 46 and fails the call with EREMOTEIO. Upstream fixed it in
nfs-ganesha#1385 (98eb77c4, first in V9.11), which answers NOTSUPP; the
client then drops the capability. The distro packages the role installs
predate it: Debian trixie 6.5-5, Ubuntu 26.04 6.5-8.

Every client and the controller now read the server's installed
nfs-ganesha release and, below 9.11, set `directory_delegations=N` right
after the mount and before the first access (the mount itself never sends
op 46), plus `options nfsv4 directory_delegations=N` in /etc/modprobe.d for
later module loads. No ganesha release grants directory delegations, so
the end state equals a fixed server. The parameter is kernel-wide and is
only ever set to N, so clients sharing one kernel cannot flip it back on
each other. Servers on 9.11 or later and the kernel nfsd flavor keep the
client default.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-10-20 16:28:52 +02:00
..
…
…
…
…

NFS Server

Description

NFS (Network File System) is a kernel-level protocol for sharing files over a network. The server exports a directory tree under defined access rules; clients mount it as if it were a local filesystem.

Overview

This role installs an NFS server in one of two flavors, the distro kernel server or userspace nfs-ganesha, selected per deployment. Both export the swarm state path to the resolved addresses of the svc-swarm-node group and to an additional CIDR allow-list; ganesha also exports the export base and squashes root there. Export options come from vars/main.yml for the kernel flavor and from the ganesha configuration template for ganesha. NFS server HA, Kerberos integration, and client-side mounting are out of scope; client mounts are handled by svc-storage-nfs-client.

Cosmos

The diagram places NFS Server in the Infinito.Nexus cosmos: the components it deploys (capabilities), the central services it consumes (dependencies), and its outward reach (federation and bridged external networks).

flowchart LR
    subgraph deps [Dependencies]
        dep_svc_bkp_nfs_2_local["svc-bkp-nfs-2-local 💻"]
    end
    subgraph role [svc-storage-nfs-server 💻]
        svc_nfs_server["nfs-server"]
        svc_nfs_backup["nfs_backup"]
    end
    subgraph dependents [Dependents]
        dpt_svc_bkp_nfs_2_local["svc-bkp-nfs-2-local 💻"]
        dpt_svc_storage_nfs_client["svc-storage-nfs-client 💻"]
    end
    dep_svc_bkp_nfs_2_local -. "0..1" .-> svc_nfs_backup
    svc_nfs_server -. "0..1" .-> dpt_svc_bkp_nfs_2_local
    svc_nfs_server -. "0..1" .-> dpt_svc_storage_nfs_client

Solid 1:1 edges are fixed relationships; dashed 0..1 edges are conditional (enabled only in matching deployments); red 0..0 edges are turned off in this role. Node markers show the role's deploy modes (💻 host, 🐳 compose, 🐝 swarm); ❌ marks a service that is explicitly turned off, and ⚙️ an Ansible role dependency declared in meta/main.yml.

Features

  • Distro-aware install: Installs nfs-kernel-server on Debian / Ubuntu, nfs-utils on Arch / RHEL / Fedora / Alpine.
  • Inventory-driven ACL: Allowed-IP list derives from the svc-swarm-node group; unrelated hosts cannot mount.
  • Reload-on-change: Re-running the role overwrites /etc/exports with the current allowed-IP set; the handler reloads via exportfs -ra only when the file changed.

Quick Setup

Development

Clone, set up the workstation, and deploy NFS Server onto the local stack:

git clone https://github.com/infinito-nexus/core.git
cd core
make onboard
make compose-deploy mode=reinstall apps=svc-storage-nfs-server full_cycle=false

Production

Install NFS Server directly onto the target machine: clone the repository, install the OS prerequisites and the repository toolchain, then deploy against localhost over a local connection (no SSH, no container):

git clone https://github.com/infinito-nexus/core.git
cd core
bash scripts/install/package.sh
make install
source scripts/meta/env/load.sh

APP=svc-storage-nfs-server
DOMAIN=<your-domain>
TLS_MODE=self_signed
SSH_PUBLIC_KEY="<your-ssh-public-key>"
INVENTORY=inventories/production
infinito administration inventory provision "$INVENTORY" \
  --inventory-file "$INVENTORY/devices.yml" \
  --host localhost \
  --include "$APP" \
  --vars "{\"TLS_MODE\": \"$TLS_MODE\", \"DOMAIN_PRIMARY\": \"$DOMAIN\", \"users\": {\"administrator\": {\"authorized_keys\": [\"$SSH_PUBLIC_KEY\"]}}}"
infinito administration deploy dedicated "$INVENTORY/devices.yml" \
  --password-file "$INVENTORY/.password" \
  --diff -vv

Credits

Implemented by Kevin Veen-Birkenbach. Part of the Infinito.Nexus Project and maintained by Kevin Veen-Birkenbach. Licensed under the Infinito.Nexus Community License (Non-Commercial).