Synopsis #
NFS is a natural fit for trusted UNIX-like clients. A common NFS deployment using the default AUTH_SYS security flavor relies on coordinated numeric identities and a trusted network boundary; NFS can also use stronger identity and message-protection models. Samba provides SMB for Windows, macOS, and mixed-client environments and maintains its own authentication integration. Both expose filesystem data over a network and require a separate permission, firewall, backup, and recovery design.
Neither protocol should be published directly to the public Internet. Use a trusted private network or an authenticated VPN boundary.
Choose from client and identity requirements #
| Requirement | NFS | Samba |
|---|---|---|
| Predominantly FreeBSD or UNIX-like clients | Strong fit | Possible, but often unnecessary |
| Native Windows client behavior | Limited fit | Strong fit |
| Coordinated numeric UID/GID ownership | Common with AUTH_SYS | Can map to local or directory identities |
| Active Directory integration | Not its primary role | Supported by Samba, with substantial added complexity |
| Small workgroup with named users | Possible with coordinated accounts | Common Samba role |
| Public Internet exposure | Do not use directly | Do not use directly |
Protocol selection does not override filesystem permissions. The service can only grant access that the underlying account and ACL model permit.
Define a dedicated data boundary #
Create or identify a dataset or filesystem specifically for the share. Record:
- owner, group, mode, and ACL policy;
- client identities and allowed networks;
- read-only versus writable paths;
- quota and capacity alert;
- snapshot, replication, and restore policy;
- whether applications also write the same files.
Avoid exporting an entire pool, jail root, or home hierarchy merely because it is convenient. A narrow share is easier to authorize and restore.
Qualify an NFS export #
FreeBSD NFS exports are defined in /etc/exports. Each entry must identify the filesystem, options, and permitted clients. Omitting clients can allow any reachable client to mount the export, subject to the rest of the configuration.
Begin with a read-only export to explicit hosts or a controlled network, reload the service, and inspect the effective export list from a client. With the default -sec=sys AUTH_SYS flavor, non-root users normally arrive as their client-supplied numeric credentials. Coordinate UID and GID values before allowing writes; matching names with different numeric IDs do not preserve ownership in that model.
Where client-supplied numeric credentials are not an adequate identity boundary, evaluate NFSv4 with the Kerberos security flavors krb5, krb5i, or krb5p. The latter two add integrity protection or privacy as defined by the NFS security design. Current FreeBSD exports also support RPC-with-TLS controls, including certificate-based user mapping with -tlscertuser. Kerberos, TLS certificates, name services, and key lifecycle management are separate infrastructure commitments and should be designed before changing an export from AUTH_SYS.
Use the current FreeBSD NFS documentation
and exports(5) for the exact export form. Do not infer Linux /etc/exports options.
Qualify a Samba share #
Install Samba from one coherent package repository and create /usr/local/etc/smb4.conf from the current package and upstream documentation. A small workgroup server still needs explicit users, share paths, and authorization.
Validate configuration before restarting:
# testparm
Begin with guest access disabled and one named test account. Verify read, create, rename, delete, and permission behavior from each supported client type before placing important data in the share.
Samba versions and package origins change. Confirm the current package name and rc.d service on the installed release rather than preserving a versioned package name in long-lived automation.
Keep sharing separate from backup #
A mounted network share is an access path, not a backup. Client-side deletion, compromised credentials, and application damage can propagate to the server. Retain snapshots and an independent copy that share credentials cannot rewrite freely.
See Plan a FreeBSD home server for service boundaries and Restore files from a ZFS snapshot for selective local recovery.