those same UNIX/NFS processes
Byte Range locking is implemented for concurrent Windows and UNIX access with UNIX advisory byte range locking via the fcntl function, and NFS propagates the locks over the NFS mount to the disk file. Since UNIX byte range locking is advisory, other processes accessing the file must be properly coded to participate in the locking protocol. The CIFS/9000 smbd process actually calls the UNIX fcntl function to implement Windows byte range locking. Thus, a Windows client accessing a NFS mounted file on a CIFS/9000 share using Windows byte range locks will interoperate with other Windows clients using byte range locks (even from other CIFS/9000 servers) or with UNIX processes that are properly coded to participate in the byte range locking protocol. When both processes correctly participate in UNIX advisory locking, byte range locking is fully effective in a mixed
Opportunistic (Oplocks) locking should be disabled for any share that has mixed Windows and UNIX client access, regardless of an NFS mount. UNIX and NFS have no concept of an oplock, therefore cannot send an oplock break when a Windows client has cached a copy of a file. A UNIX process could open and write to a disk file that has been modified in the Windows client cache, which results in an unacceptable risk of data corruption. Oplocks should be disabled in a mixed
Mandatory, Byte Range, and Opportunistic locking are all enabled by default. Disable oplocks for
[share_name]
share modes = yes <default config – shown for example only> locking = yes <default config – shown for example only> oplocks = no
veto oplocks can be used to specify particular files on a share that will encounter mixed Windows and UNIX access, and prevent the CIFS/9000 server from granting oplock requests upon those files. By enabling veto oplocks for
[share_name]
share modes = yes <default config – shown for example only> locking = yes <default config – shown for example only> oplocks = yes
veto oplock files = /filename.ext/
6See Appendix B.5
23
