Docs / File Services

File Services

SimpleVirt File Services presents SMB and NFS file shares carved from a cluster's SimpleVirt HCI (CephFS) storage, on one highly-available floating address. It lets a cluster that already runs VMs also serve files to clients — a team share, a scratch area, an application's data directory — without a separate NAS.

It is a preview, off by default behind the file_services experimental flag. The serving path is production-quality in the code, but it must be proven on a real multi-host cluster before the flag is removed; treat it as evaluation-only until then. Read known limitation 12 for the boundaries that will not change in v1.

How it works

  • Shares are plain directories on the cluster's shared CephFS, each with an optional CephFS directory quota. NFS is served by nfs-ganesha; SMB by smbd. Both serve the directory over the kernel CephFS mount — there is no second storage path.
  • The floating address is controller-driven: SimpleVirt-Command picks one reachable member to hold the address and serve, and re-homes it to another member if that host fails (on its next reconcile pass, ~30 seconds). While the controller itself is down, the current placement is frozen — shares keep serving where they are.
  • Realized state is reported honestly: the File Services tab shows which host is actually serving, whether the daemons are up, and whether anything is declared but not served.

Prerequisites

  • A cluster with SimpleVirt HCI (Ceph) storage and the composite HCI file store (hcifs) mounted on its members (the HCI setup does this).
  • At least two reachable members, so the share server can fail over.
  • An appliance image that carries the share-server packages (the current image does; an older image reports "not serving" honestly rather than pretending).
  • A free IPv4 address on the storage network for the floating address. IPv6 is not supported yet and is refused at declare time.

Enable and declare a share

In SimpleVirt-Command, open the cluster's File Services tab.

  1. Enable File Services, set the highly-available address (an IPv4 address or CIDR), choose the protocols, and save.
  2. For SMB, add at least one SMB account under SMB accounts. SMB has no safe unauthenticated mode, so an SMB (or NFS + SMB) share does not serve until an account exists. The password is shown once at creation — copy it then; rotate to issue a new one.
  3. Add a share: a name, a protocol (NFS, SMB, or NFS + SMB), an optional read-only flag, and the allowed clients (CIDRs). Leaving allowed clients blank scopes the share to the floating address's own subnet — it is never left open to the whole network.

The Serving status panel then shows the serving host, the live export/share counts, and whether the daemons are active.

Mount a share

NFS (NFSv4 only) — mount the floating address at /<share-name>:

mount -t nfs4 <address>:/<share-name> /mnt/share

SMB — connect to \\<address>\<share-name> with an SMB account's username and password. On Linux:

mount -t cifs //<address>/<share-name> /mnt/share -o username=<account>,vers=3.1.1,seal

In-flight SMB traffic is sealed (encryption required) and SMB1/NetBIOS are disabled.

Remove vs. delete data

Removing a share is non-destructive by default: it stops exporting the share but keeps its data on CephFS. Reusing a name later is safe — directories are keyed by each share's stable id, so a new share with a reused name gets a fresh, empty directory and can never re-export a previous share's files.

To reclaim the space, choose delete data when removing the share; this runs the explicit, operator-confirmed destructive path on a reachable member. To change a share's quota, read-only flag, or allowed clients, edit it in place rather than removing and re-adding — editing keeps the same directory and data.

Backup responsibility

Share contents live in the HCI CephFS and follow the HCI pool's protection geometry. File Services provides no per-share snapshot or backup in this release; supply your own backup for data that matters. See backup responsibility.

Known boundaries (v1)

  • Failover is controller-driven, not quorum-owned; a controller outage freezes placement, and a controller↔server partition can briefly double-claim the address (CephFS keeps the data consistent, and the window closes within one reconcile).
  • An SMB session resets on a failover — reconnect to resume; persistent handles are not configured.
  • SMB authentication (NTLMv2, local accounts) has no rate-limiting; keep the storage network trusted and rely on the allowed-client scope.

See known limitation 12 for the full statement.

This page is part of the SimpleVirt 1.0.0 documentation set. The same guides ship inside the appliance images at /usr/share/doc/simplevirt.