Synopsis #
Use NFSv3 with AUTH_SYS only between trusted clients whose numeric user and group identities are coordinated. The client supplies those identities; mapping client root to nobody does not stop a client administrator from impersonating another UID. For an untrusted network, choose a stronger authentication and transport design before exporting data.
This procedure uses server 192.0.2.10, client 192.0.2.20, and dataset zroot/share mounted at /srv/share. Replace the documentation addresses with private addresses and substitute the actual pool. Keep NFS, mountd, rpcbind, and locking services inside the trusted network or VPN. Export restrictions do not replace a firewall.
Match the intended account #
On both systems, inspect the account that will use the files:
$ id shareuser
Its UID and primary GID must agree numerically. Matching account names alone are insufficient. If creating a dedicated account, select unused IDs on both hosts; for example:
# pw groupadd -n shareuser -g 2001
# pw useradd -n shareuser -u 2001 -g shareuser -m -s /bin/sh
Do not renumber an existing account without reviewing ownership of its existing files.
Prepare a narrow server filesystem #
On the server:
# zfs create -o mountpoint=/srv/share zroot/share
# chown shareuser:shareuser /srv/share
# chmod 0770 /srv/share
Create a small file as shareuser, rather than as root:
$ printf 'shared data\n' > /srv/share/example
$ chmod 0600 /srv/share/example
Add this read-only entry to /etc/exports, preserving other exports:
/srv/share -ro -maproot=nobody 192.0.2.20
The explicit client address matters. An entry without clients can export the filesystem to every reachable client.
Start the server and locking services #
Enable the server services and TCP NFS:
# sysrc rpcbind_enable=YES nfs_server_enable=YES mountd_enable=YES
# sysrc nfs_server_flags='-t'
# sysrc rpc_statd_enable=YES rpc_lockd_enable=YES
# service rpcbind start
# service nfsd start
# service statd start
# service lockd start
Starting nfsd also starts mountd. Review an existing nfs_server_flags value before replacing it. NFSv3 uses RPC services in addition to TCP 2049; opening only that port is insufficient. Review actual listeners and the site’s firewall policy:
# sockstat -4 -6 -l
$ showmount -e 192.0.2.10
Mount from the client #
On the client:
# sysrc nfs_client_enable=YES rpc_statd_enable=YES rpc_lockd_enable=YES
# service nfsclient start
# service statd start
# service lockd start
# mkdir -p /mnt/share
# mount -t nfs -o nfsv3,tcp 192.0.2.10:/srv/share /mnt/share
As shareuser, read the file and attempt a temporary write:
$ cat /mnt/share/example
$ touch /mnt/share/write-check
Reading should succeed; the write should report a read-only filesystem. Client root should not be able to read the private file through this export. These are distinct checks of filesystem ownership, export policy, and root mapping.
Enable and verify writes #
Unmount on the client:
# umount /mnt/share
On the server, remove only -ro from the selected export:
/srv/share -maproot=nobody 192.0.2.20
Reload the exports:
# service mountd reload
Mount again on the client with the preceding mount command. As shareuser, check create, rename, read, and delete operations:
$ umask 027
$ printf 'client data\n' > /mnt/share/write-check
$ mv /mnt/share/write-check /mnt/share/renamed-check
$ cat /mnt/share/renamed-check
$ stat -f '%u:%g %Lp' /mnt/share/renamed-check
$ rm /mnt/share/renamed-check
Check the same file’s numeric ownership on the server before deleting it when diagnosing identity problems. Applications that use advisory locks also need working locking services on both systems. A successful copy alone does not qualify an application’s locking or concurrent-write behavior.
Mount at boot when required #
After a successful manual mount, add one client /etc/fstab entry:
192.0.2.10:/srv/share /mnt/share nfs rw,nfsv3,tcp 0 0
Perform a controlled reboot and repeat the account, mount, and file checks. A boot-time mount depends on the server and network being available; retain administrative access when adding it. Use umount /mnt/share before changing the mount or removing the entry.
A writable share is an access path, not a backup. Keep snapshots and an independent copy, and use selective ZFS recovery when a client damages a file.