Search the docs

Limitations in Hammerspace 5.3

The following constraints apply to the technology preview of NFS over TLS in Hammerspace 5.3.

  • Technology preview only — not validated or supported for production environments.

  • All-or-nothing — no mixed TLS/non-TLS cluster configurations; no per-share TLS.

  • No RDMA while TLS is required — RPC-with-TLS (RFC 9289) runs over TCP only. While TLS is required, client access over NFS/RDMA fails. Clients that mount over RDMA must remount over TCP with xprtsec=mtls.

  • Referral shares are not supported — NFS referral shares are not supported in a TLS-enabled cluster.

  • Certificate revocation not implemented — Hammerspace does not support certificate revocation lists (CRL) or OCSP. To stop trusting a certificate that you uploaded, remove it from the trust store.

  • Removing a node does not revoke its certificate — A node removed from the cluster keeps its certificate, its private key, and the Hammerspace root CA certificate, and the certificate remains valid until it expires. A host holding them can authenticate to the cluster as a Hammerspace node. Before a removed node leaves your control, reinstall it or wipe its system disks. If you cannot, contact Hammerspace Support. Every 5.3 node has a certificate, so this applies whether or not TLS is enabled: the certificate remains valid if TLS is enabled later.

  • No certificate renewal or expiration alerts — Hammerspace does not renew certificates automatically and raises no event before a certificate expires. Administrators cannot renew node certificates or replace the system CA. See Certificate Lifetimes and Expiration.

  • Cipher suites are fixed and cannot be configured — pd-protod and pd-di do not use system defaults. They use TLS 1.3 with AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305. Only the kernel side — DSX knfsd and clients, through tlshd — goes through GnuTLS. There is no UI or CLI to customize cipher suites.

  • No per-user certificate authentication — the transport is secured and the host is authenticated; user identity comes from the share’s RPC security flavor.

  • No SmartNIC TLS offload — TLS processing runs on host CPUs.

  • External movers receive no system-issued certificates — and no PKI health monitoring or PKI_* events. See External Movers (DI and Cloud Mover Containers).

  • Third-party storage support is limited — see Reference: Supported Third-Party Backend Storage.

  • Strict client OS requirements — see Reference: Client Requirements.