GANESHA-TLS-CONFIG(8)

💅 GANESHA-TLS-CONFIG(8) — the NFS-Ganesha TLS Service Configurations file, bestie ✨

okay so this is the ganesha-tls-config page from the NFS-Ganesha manual — it's literally all about making your NFS traffic go 💖 encrypted 💖 and it's giving main character energy. sit down, grab a strawberry 🍓, and let's get into it.

🦋 SYNOPSIS

/etc/ganesha/ganesha.conf

that's the file, babe. the whole vibe lives in there.

---

🌸 DESCRIPTION

okay so Transport Layer Security (TLS) is a cryptographic protocol that provides confidentiality, integrity, and authentication for network communications — no cap. when you use it with NFS, TLS encrypts all the traffic between the client and the server, so the data is not visible to intermediaries and it cannot be altered in transit without detection. slay. 🔥

TLS operates at the transport layer (above TCP) and establishes a secure channel between the client and the server before any application data is exchanged. during the handshake process, the client validates the server's identity using its certificate. the server may also optionally request a certificate from the client. iconic behavior honestly.

when NFS is configured to use TLS-based transport security, the mount negotiation and all subsequent RPC calls are carried over this encrypted channel. everything. encrypted. periodt. 🔐

💀 TLS VS. MTLS — the glow-up

in standard TLS (also called one-way TLS), only the server is authenticated. the client verifies that it is talking to the correct server by validating the server's certificate against a trusted Certificate Authority (CA). the server does not verify the client's identity beyond the network address and any application-level authentication. so like, the server's showing its ID but it's not asking for yours.

in mutual TLS (mTLS), both endpoints present certificates during the TLS handshake. the client still validates the server's certificate, but the server also validates the client's certificate against its own trusted CA list. this provides stronger assurance that the client is an authorized entity, not just any host on the network. a client certificate signed by a trusted CA is required. this mode is used where unauthorized clients must be blocked before any data exchange occurs. it's giving VIP-only, bouncer-at-the-door energy. 👑

below are the ways by which the client can initiate an NFS over TLS connection while mounting:

✨ Example 1: Stunnel (Install stunnel)

1. configure stunnel with a forwarding port to the ganesha configured port.

example config file (/etc/stunnel/stunnel.conf):

pid = /var/run/stunnel/stunnel.pid
cert = /home/dpp/workspace/TLS_ceritificates/vm1.crt
key = /home/dpp/workspace/TLS_ceritificates/vm1.key
CAfile = /home/dpp/workspace/TLS_ceritificates/ca.crt
socket = r:TCP_NODELAY=1
foreground = yes
debug = 7
output = /var/log/stunnel.log
renegotiation = no

[nfs4]
client = yes
accept = 127.0.0.1:49152
connect = 23.13.161.10:2049
sslVersion = TLSv1.3
ciphers = ALL
verify = 2
# change above verify = 2 for tls and mtls accordingly.

2. start stunnel
3. mount using the below command:

mount -vv -t nfs -o rw -o port=49152 127.0.0.1:/exportfs0 /mnt/

🧚 Example 2: Use the tlshd (Install ktls-utils)

1. configure /etc/tlshd.conf
2. start tlshd
3. mount command:

mount -vv -t nfs -o vers=4 -o xprtsec=mtls -o rw 104.86.87.87:/exportfs0/ /mnt

---

💖 OPTIONS ✨

note: EXPORT{} needs to be populated with the proper XprtSec = none or tls or mtls, or it can be provided in EXPORT_DEFAULTS {XprtSec = none/tls/mtls}. this allows controlling of access at the export level. 💅

here's the whole server-export-meets-client-mount-meets-what-actually-happens situation:

• XprtSec=none + (no xprtsec) → mount succeeds in plaintext (unencrypted TCP/UDP). tried and true, no secrets kept.
• XprtSec=none + xprtsec=tls → mount succeeds over TLS; encryption used even though it wasn't required. overachiever behavior, honestly iconic.
• XprtSec=none + xprtsec=mtls → mount succeeds over TLS; encryption used even though it wasn't required. same vibe, mutual edition.
• XprtSec=tls + (no xprtsec) → mount fails with EACCES ("Permission denied") — server rejects non-TLS connections. blocked. 🚫
• XprtSec=tls + xprtsec=tls → mount succeeds over TLS; server certificate validated by client. the good good. ✅
• XprtSec=tls + xprtsec=mtls → mount succeeds over TLS; even if the client certificate fails, it doesnt matter. lowkey forgiving.
• XprtSec=mtls + (no xprtsec) → mount fails with EACCES — client not attempting mTLS. kicked out of the club. 😭
• XprtSec=mtls + xprtsec=tls → mount fails with EACCES — mTLS required, i.e. client should provide a valid certificate to the server. no cert, no entry. 💀
• XprtSec=mtls + xprtsec=mtls → mount succeeds only if the client presents a valid certificate trusted by the server; otherwise fails with EACCES. it's giving strict-but-fair.

🎀 TLS_CONFIG {}

• Enable_TLS(bool, default false) — turns TLS on. defaults to false, so like, no secrets protected until you say so bestie.
• TLS_CA_File(path, default "") — the path to your CA file. default is "".
  • eg: TLS_CA_File = "/etc/ganesha/tls/ca.crt";
• TLS_Cert_File(path, default "") — the path to your cert file. default is "".
  • eg: TLS_Cert_File = "/etc/ganesha/tls/ganesha.crt";
• TLS_Key_File(path, default "") — the path to your key file. default is "". 🔑
  • eg: TLS_Key_File = "/etc/ganesha/tls/ganesha.key";
• TLS_Ciphers(string, default NULL) — your cipher suite string. default is NULL.
  • eg for backend as openssl:

TLS_Ciphers = "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384";

• eg for backend as gnutls:

TLS_Ciphers = ":-CIPHER-ALL:+AES-256-GCM";

• TLS_Min_Version(string, "TLSv1.3") — sets the minimum TLS version. default is "TLSv1.3".
  • options = "TLSv1.3", "TLSv1.2";
  • eg: TLS_Min_Version = "TLSv1.3"
• Enable_KTLS(bool, default false) — to enable and disable KTLS transferes. default is false.

note: currently applicable for only openssl. if the user wants to enable/disable ktls for gnutls, use the gnutls config file. 💅

• Enable_debug(bool, default false) — to enable TLS library callback prints and full debugging logs for TLS. default is false. when you need to see everything, bestie. 🙈

---

📝 NOTES:

this module provides the user with the flexibility of using openssl or gnutls as backend, but as of now it's a compilation option. USE_TLS to compile in NFS-ganesha with TLS.

dependency:

• USE_OPENSSL to use openssl as TLS lib.
• USE_GNUTLS to use GnuTLS as TLS lib.

---

👑 AUTHOR

NFS-Ganesha-TLS feature added by <Deeraj.Patil@ibm.com>

🌈 SEE ALSO

ganesha-config <>(8)

---

and that's the whole thing bestie — GANESHA-TLS-CONFIG(8), NFS-Ganesha, Jan 01, 1980, version and date and all the vibes included. go forth and encrypt everything ✨💖🦋