OCF_HEARTBEAT_GANESH(7)

💅 ocf_heartbeat_ganesha-nfs — the manual page, but make it make sense ✨

okay so bestie, this is a page from the OCF resource agents collection, and it's literally about ocf_heartbeat_ganesha-nfs — the resource agent that runs your NFS-Ganesha setup in a cluster. grab a lil snack, we're getting into it 🍓

---

🌸 NAME 🌸

ocf_heartbeat_ganesha-nfs — manages an NFS-Ganesha server instance. that's the whole vibe. it's giving "one server, one resource, high availability realness" 👑

---

✨ SYNOPSIS ✨

ganesha-nfs [start | stop | monitor | meta-data | validate-all]

those are your five moves, bestie. pick one 💅

---

🦋 DESCRIPTION 🦋

So what this agent actually does: it manages a single NFS-Ganesha (ganesha.nfsd) server instance as a cluster resource — for HA NFS on DRBD/LINSTOR-backed storage. v cute, v serious. 🌈

There are two modes, and you need to know which one you're in:

• If export_path is set, the agent renders an ephemeral ganesha.conf under runtime_dir from the OCF parameters and starts ganesha against it. This is the exportfs(8) model — runtime realisation, nothing persisted. very main character, no strings attached ✨
• If export_path is empty and config_file points at an existing file, that file is used verbatim (legacy/static mode). old-school, respect it 🎀

A single ganesha process can serve several exports: export_path, export_id and pseudo accept ;-separated lists, zipped positionally (one EXPORT block per entry). All exports share one service IP, one clients whitelist, and the other scalar parameters. sharing is caring fr fr 🫶

⚠️ The agent does not manage kernel NFS, /var/lib/nfs, rpcbind, or statd. don't come for it for things it never signed up to do 💀

🔥 CRITICAL: the NFSv4 RecoveryDir must live on the replicated filesystem this resource fails over with, or clients lose their locks on failover. like, not optional. this is the whole ballgame.

---

💖 SUPPORTED PARAMETERS 💖

so many parameters, and honestly? every single one is iconic. here we go 👑

• export_path — server-side directory to export, on the replicated FS. Setting this switches the agent into generated mode (it renders ganesha.conf from its parameters). May be a ;-separated list to export several directories from one ganesha process. (optional, string, no default)
• export_id — the NFS Export_Id (uint16, 1-65535), or a ;-separated list parallel to export_path. Must be unique and stable per server; collision-free assignment is the caller's responsibility. Defaults to the export's 1-based position if omitted. (optional, integer, default 1)
• pseudo — NFSv4 pseudo path, or a ;-separated list parallel to export_path. Each entry defaults to its export_path if unset; must be unique per export. (optional, string, no default)
• clients — client spec for the CLIENT whitelist (e.g. "10.1.10.0/24", a bare IPv6 like fd00:10:1:10::3, or "*"). REQUIRED in generated mode — deny-default, bestie: no clients means nobody can mount. Use "*" explicitly to allow all reachable clients. choose your fighters wisely 🙈 (optional, string, no default)
• access_type — access type granted to whitelisted clients: RW, RO, or None. (optional, string, default "RW")
• squash — UID/GID squashing: Root_Squash, No_Root_Squash, or All_Squash. squash that root, or don't 💅 (optional, string, default "Root_Squash")
• anonuid — numeric uid that squashed requests are mapped to (Anonymous_Uid). When unset, ganesha's built-in default of -2 (uid 4294967294) applies — and note that this is NOT the common 'nobody' uid 65534, so squashed clients can usually not write anywhere. Set to 65534 (or the uid owning the export directory) to allow squashed clients to write. Shared by all exports of this instance. this one trips everybody up, no cap 😭 (optional, string, no default)
• anongid — numeric gid that squashed requests are mapped to (Anonymous_Gid). When unset, ganesha's built-in default of -2 (gid 4294967294) applies. Shared by all exports of this instance. (optional, string, no default)
• sectype — security flavour: sys, krb5, krb5i, krb5p. (optional, string, default "sys")
• protocols — NFS protocol versions to offer, e.g. "3,4" or "4". (optional, string, default "3,4")
• fsal — Ganesha FSAL name (VFS, GLUSTER, CEPH, ...). (optional, string, default "VFS")
• server_scope — NFSv4 Server_Scope (RFC 8881 server scope). MUST be set to the same value on all nodes that can run this resource, e.g. the service IP or a cluster name. Without it, ganesha derives the scope from the local hostname — so after a failover NFSv4.1+ clients see a different scope, refuse to reclaim their open/lock state, and I/O on files that were open hangs indefinitely. this is a "whole cluster depends on it" situation, fr. also note: setting or changing this value is itself a scope change — existing client state cannot be reclaimed across the reconfiguration. 🔥 (optional, string, no default)
• enable_nlm — whether to enable NLM (file locking for NFSv3 clients). With NLM enabled, ganesha always waits out the full grace period on every start/failover, because NLM lock reclaims have no completion signal — and NFSv4 I/O on open files stalls for that long. With NLM disabled, grace ends as soon as all NFSv4.1+ clients have reclaimed (typically seconds), NFSv3 reads/writes are unaffected, but NFSv3 lock requests fail. Also note: NFSv3 lock recovery additionally requires an rpc.statd/SM_NOTIFY setup that this agent does not manage — without one, NFSv3 locks are silently lost on failover even with NLM enabled. so, you know, pick your struggle 💀 (optional, boolean, default true)
• grace_period — NFSv4 Grace_Period in seconds (0-180; ganesha default 90). Upper bound on how long clients have to reclaim state after a failover; stateful NFSv4 operations from clients that have finished reclaiming may still be blocked until grace ends (see enable_nlm). Must be at least lease_lifetime, or clients that were briefly unreachable lose their state silently. 🙏 (optional, integer, no default)
• lease_lifetime — NFSv4 Lease_Lifetime in seconds (1-120; ganesha default 60). How long the server holds a client's state without renewal. Lower values shorten failover recovery but increase renewal traffic and the risk of spurious state loss for slow clients. tradeoffs, always tradeoffs 🎀 (optional, integer, no default)
• recovery_dir — NFSv4 RecoveryDir (server-wide singleton). MUST be on the replicated FS. Defaults to a hidden dir under the first export_path. yes this is the critical one from earlier, hi again 👋 (optional, string, no default)
• runtime_dir — directory for the ephemeral generated config (tmpfs recommended). (optional, string, default "/run/ganesha")
• config_file — legacy mode only: path to a pre-existing ganesha.conf. Ignored when export_path is set. (optional, string, default "/etc/ganesha/ganesha.conf")
• pid_file — PID file. Must be unique across co-located instances. no sharing, bestie 🚫 (unique, optional, string, default "/run/ganesha.pid")
• log_file — Ganesha log file path. (optional, string, default "/var/log/ganesha/ganesha.log")
• log_level — Ganesha log level (NIV_EVENT, NIV_INFO, NIV_DEBUG, ...). (optional, string, default "NIV_EVENT")
• nfs_ip — service IP (v4 or v6) to bind and probe. Each co-located instance should use a distinct IP. (optional, string, no default)
• nfs_port — TCP port to bind/probe. (optional, integer, default 2049)
• start_timeout — seconds to wait for readiness (PID + listening port). (optional, integer, default 30)

---

🌟 SUPPORTED ACTIONS 🌟

this resource agent supports the following actions (operations) — a whole menu of them, slay:

• start — starts the resource. Suggested minimum timeout: 60s.
• stop — stops the resource. Suggested minimum timeout: 60s.
• monitor — performs a detailed status check. Suggested minimum timeout: 20s. Suggested interval: 30s. (your little wellness check 🫶)
• meta-data — retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.
• validate-all — performs a validation of the resource configuration. Suggested minimum timeout: 20s.

---

🧚 EXAMPLE CRM SHELL 🧚

here's an example config for a ganesha-nfs resource using the crm(8) shell — copy-paste ready, you're welcome 💜

primitive p_ganesha-nfs ocf:heartbeat:ganesha-nfs \
  op monitor timeout="20s" interval="30s"

---

⭐ EXAMPLE PCS ⭐

and here's the same energy, but for pcs(8):

pcs resource create p_ganesha-nfs ocf:heartbeat:ganesha-nfs \
  op monitor timeout="20s" interval="30s"

---

🎀 SEE ALSO 🎀

• http://clusterlabs.org/ — go visit, they're the blueprint fr

---

👑 AUTHOR 👑

ClusterLabs contributors (see the resource agent source for information about individual authors). they ate and left no crumbs 💅

---

🌈 aww and that's the page! brought to you by resource-agents UNKNOWN, dated 10/01/2026 — that's the version and date, cute right? now go configure your cluster, bestie, you've got this 💖✨