Concept and mechanism
Valid configuration is a preparation step. testparm checks internal smb.conf correctness but does not guarantee share availability or functional access. Similarly, editing /etc/exports does not prove the effective export table was updated. Observe the service and apply changes in a controlled manner before concluding that the client ignores new policy. The application also needs a concurrency contract. NFS close-to-open helps coherence under defined access patterns but does not provide perfect coherence among simultaneous writers. Validate appropriate locking or serialization; disabling caches does not automatically make an application safe when it does not coordinate writes.
Guided application
During migration, content and metadata should be accepted separately. DataSync documentation distinguishes what can be preserved according to source, destination, and options. On the presented SMB-to-NFS path, Windows ACLs are not preserved as equivalent authorization; destination access needs design and validation. Matching content hashes do not prove ownership, permissions, or share configuration. In a fictional example, an administrator reads files while the scheduler fails. Acceptance requires checking required operations with the actual account, preserving recovery, and giving RUN dependencies, alerts, and procedures. These scenarios do not represent internal BNP Paribas shares and involve no executed real mounts, copies, or changes.
Matching hashes do not demonstrate that the scheduler account can process destination files.
Common pitfalls
testparm as functional check; diff as active state; close-to-open as serialization; matching content as matching ACL.
Related topics: Shares and mounting · Identity and permissions · Security and write acknowledgement
Accept the change with evidence of content, access, behavior, and recovery.
Reference: DataSync metadata preservation by source and destination · DR NAS 2026-09; selected Linux NFS, Samba, Windows SMB and ONTAP behavior