An NFS export is configured on a Data Domain, and the senior engineer mounts it from the backup host and copies a file in each direction before signing the file-services line. Why is that the right way to close file-service testing?
Select an answer to reveal the explanation.
Short Explanation
Server settings describe the service; the client is where it works or doesn't. Mounting from the actual host and writing a file, then reading it back, checks exports, permissions, and disks all at once from the seat your users will sit in. Checkboxes don't write files.
Full Explanation
Functional verification belongs on the consumer's side of the wire, and a write-plus-read-back covers the real chain in one gesture: the export is visible to that host under its network-address or host restrictions, the squash and permission model allows actual writes, the filesystem accepts and stores the data, and reading it back confirms the data comes out intact. A failure in that sequence is also self-localizing, which is what makes it a test rather than a demo. The write-and-read-back view is right because it exercises mount permissions, filesystem write, and intact read-back from the backup host's seat instead of trusting server-side configuration. The mount-and-directory-listing view proves only read-side visibility; a classic acceptance gap is an export that lists happily but refuses writes because of root squash or a read-only option, discovered later by a backup job. The portmap-query view misattributes the test's value: RPC services are part of NFS plumbing, but the copy test earns its keep on permission and data-path coverage, not on forcing a single lookup. The dedup-at-write-time view is wrong because, although deduplication does act on writes, a lone test file carries no meaningful redundancy, so treating the copy as a reduction-efficiency test reads significance into a number that only becomes meaningful with real duplicate data. Exam caveat: test from the host identity that will really serve backups - exports restricted by network or host can pass from a laptop and fail from the media server. Operational check: a file written from the client, read back with matching checksum, removed afterward, and the result recorded against the file-services line item.