A backup server writing to a CIFS target on the Data Domain passed every commissioning test. Two weeks later a routine patch reboot leaves the first nightly job failing quietly, because nobody noticed the share had been a manual mapping that did not come back with the server. What did the deployment miss?

File-share connectivity only exists while the client side maintains the session, and reboots are certain, so the deployment task includes persistence at the operating system: mappings configured to reconnect at startup, stored credentials that outlive logouts, and on Linux equivalents such as fstab or autofs entries for that pattern. Handover proof should then simulate reality, reboot the client, and confirm the mount is present and a test backup passes before signature, because silent target loss discovered by the first failed job is exactly the failure class this test exists to kill. Appliance-side persistent mounts are a misnomer, since SMB sessions are initiated by the client after boot and the appliance cannot presciently hold a session for a machine that is rebooting. Certificates belong to different mechanisms entirely, as plain CIFS mappings need no client certificate, and invoking them here mixes up authentication material with session persistence. Trusting the backup scheduler to remap drives is an application-specific patch over a host-configuration gap and keeps failures one software update away rather than fixed at the layer that owns mounts. Exam caveat: verify credential-storage policy permits the saved credentials persistence requires. Operational check: reboot the client without interactive login, confirm the mapping returns, and run a real job end to end.