When a client opens a file it can request an "oplock" or file lease. This is (to simplify a bit) a guarentee that no one else has the file open simultaneously. It allows the client to not send any updates on the file to the server, thus reducing a network file access to local access (once the file is in client cache). An "oplock break" is when the server sends a request to the client to flush all its changes back to the server, so the file is in a consistent state for other opens to succeed. If a client fails to respond to this asynchronous request then the file can be corrupted. Hence the "turn off oplocks" answer if people are having multi-user file access problems.
Unless the kernel is "oplock aware" (SGI IRIX and Linux are the only two UNIXes that are at the moment) then if a local UNIX process accesses the file simultaneously then Samba has no way of telling this is occuring, so the guarentee to the client is broken. This can corrupt the file. Short answer - it you have UNIX clients accessing the same file as smbd locally or via NFS and you're not running Linux or IRIX then turn off oplocks for that file or share.
"Share modes". These are modes of opening a file, that guarentee an invarient - such as DENY_WRITE - which means that if any other opens are requested with write access after this current open has succeeded then they should be denied with a "sharing violation" error message. Samba handles these internally inside smbd. UNIX clients accessing the same file ignore these invarients. Just proving that if you need simultaneous file access from a Windows and UNIX client you *must* have an application that is written to lock records correctly on both sides. Few applications are written like this, and even fewer are cross platform (UNIX and Windows) so in practice this isn't much of a problem.
"Locking". This really means "byte range locking" - such as lock 10 bytes at file offset 24 for write access. This is the area in which well written UNIX and Windows apps will cooperate. Windows locks (at least from NT or above) are 64-bit unsigned offsets. UNIX locks are either 31 bit or 63 bit and are signed (the top bit is used for the sign). Samba handles these by first ensuring that all the Windows locks don't conflict (ie. if other Windows clients have competing locks then just reject immediately) - this allows us to support 64-bit Windows locks on 32-bit filesystems. Secondly any locks that are valid are then mapped onto UNIX fcntl byte range locks. These are the locks that will be seen by UNIX processes. If there is a conflict here the lock is rejected.
Note that if a client has an oplock then it "knows" that no other client can have the file open so usually doesn't bother to send to lock request to the server - this means once again if you need to share files between UNIX and Windows processes either use IRIX or Linux, or turn off oplocks for these files/shares.