Windows files on SMB/CIFS server do not automatically have read locks

Question

My memory from working with different systems in the past is that the default behavior for many windows SMB clients writing to a Netapp share is that open files would automatically have a read lock on them. Other programs (like one running a backup) would get an error trying to read this open file.

Now someone has a workflow relying on this behavior and it doesn't seem to be true. I can either open a word doc or dd a file on a linux CIFS mount, and while it's open, I can read the whole thing from another CIFS client.

Assuming I haven't imagined this behavior, is there any way to recreate it? I've tried a netapp with and without SMB2 enabled and with and without oplocks enabled. I've tried filers with different versions of OnTap. I don't see any mount options on linux that would affect the behavior. None of these configurations give me a deny-read lock by default.

Goal: Allow clients to write to SMB share, but deny read access from other clients until the file is closed.

Answer 1

From samba documentation:

Strictly speaking, an SMB server should check for locks before every read and write call on a file. Unfortunately, with the way fcntl() works, this can be slow and may overstress the rpc.lockd. This is almost always unnecessary because clients are independently supposed to make locking calls before reads and writes if locking is important to them. By default, Samba only makes locking calls when explicitly asked to by a client, but if you set strict locking = yes, it will make lock checking calls on every read and write call.

The second class of locking is the deny modes. These are set by an application when it opens a file to determine what types of access should be allowed simultaneously with its open. A client may ask for DENY_NONE, DENY_READ, DENY_WRITE, or DENY_ALL. There are also special compatibility modes called DENY_FCB and DENY_DOS.

In short, you can try using strict locking = yes and see if it make some differences. Anyway, the true solution would be to let the producer/writer process to open the file with the correct mode: DENY_ALL

Answer 2

This behavior is controlled by smb oplock or leases. The client side is where this is defined. In other words. It depends on your application. All this in pesumption that ontap fully complies to smb specs (which is 90 persent true)