5.5.2 Unix and Locking

Windows systems cooperate well to avoid overwriting each other's changes. But if a file stored on a Samba system is accessed by a Unix process, this process won't know a thing about Windows oplocks and could easily ride roughshod over a lock. Some Unix systems have been enhanced to understand the Windows oplocks maintained by Samba. Currently the support exists only in SGI Irix 6.5.2f and later; Linux and FreeBSD should soon follow.

If you have a system that understands oplocks, set kernel oplocks = yes in the Samba configuration file. That should eliminate conflicts between Unix processes and Windows users.

If your system does not support kernel oplocks, you could end up with corrupted data when somebody runs a Unix process that reads or writes a file that Windows users also access. However, Samba provides a rough protection mechanism in the absence of kernel oplocks: the veto oplock files option. If you can anticipate which Samba files are used by both Windows users and Unix users, set their names in a veto oplock files option. This will suppress the use of oplocks on matching filenames, which will supress client caching, and let the Windows and Unix programs use system locking or update times to detect competition for the same file. A sample option is:

veto oplock files = /*.dbm/

This option allows both Unix processes and Windows users to edit files ending in the suffix .dbm. Note that the syntax of this option is similar to veto files.

Samba's options for locks and oplocks are given in Table 5.8.