Question about Set-SMBClientConfiguration

[Mike Leone]

I am looking for some confirmation. If I issue a 

 set-smbclientconfiguration -UseOpportunisticLocking $FALSE

 set-smbclientconfiguration -OplocksDisabled $TRUE

This would apply to file reads from any drive - i.e., from a local drive, as well as reads performed  on a file share/mapped drive?

--

Mike. Leone, <mailto:tur...@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

[con...@cadzow.com.au]

It's been a while since I had to seriously spend time on OpLocks, but my recollection is that one of these settings relates to the legacy oplocks in Windows NT and one is the more modern version in Windows 2000 and above. However, they only affect SMB1. I don't know why Windows 10/11 would expose anything related to the old NT4 version, except perhaps compatibility for certain legacy APIs. Opportunistic locking was reworked in SMB2 and can't be turned off. Additionally, it only applies to network shares, not reading local files. The point is to optimise access to shared data across a network such as a multi-user databases where there is no 'database server' to manage client requests. An application running in a single-user, local environment would not use any sort of SMB locking and would probably just throw an error if two instances of a process tried to access the same parts of a file. I recollect running around a lot turning off Oplocks in the late 1990s and early 2000s because all sorts of custom database apps would choke on it, but it may well have equally been bad network cabling, bad network adaptor drivers etc. All those things are far superior now.

I could stand to be corrected.

[Mike Leone]

On Tue, Sep 2, 2025 at 10:02 PM 'con...@cadzow.com.au' via ntpowershell <ntpowe...@googlegroups.com> wrote:

It's been a while since I had to seriously spend time on OpLocks, but my recollection is that one of these settings relates to the legacy oplocks in Windows NT and one is the more modern version in Windows 2000 and above. However, they only affect SMB1. I don't know why Windows 10/11 would expose anything related to the old NT4 version, except perhaps compatibility for certain legacy APIs. Opportunistic locking was reworked in SMB2 and can't be turned off. Additionally, it only applies to network shares, not reading local files. The point is to optimise access to shared data across a network such as a multi-user databases where there is no 'database server' to manage client requests. An application running in a single-user, local environment would not use any sort of SMB locking and would probably just throw an error if two instances of a process tried to access the same parts of a file. I recollect running around a lot turning off Oplocks in the late 1990s and early 2000s because all sorts of custom database apps would choke on it, but it may well have equally been bad network cabling, bad network adaptor drivers etc. All those things are far superior now.

Interesting. In my particular case, we use an application from Oracle (Web Content Center), and my devs are insistent that the application handles any file locking issues, and therefore file locking must be turned off in the OS. (me, I'm not entirely sure that's completely possible, but hey - whatever ... LOL). And since the application  is reading/writing to a network file share (the share is presented by a Win 2019 file server cluster), I make it a point to issue the 2 below commands on each application node (the app is load balanced, using an F5 load balancer, which  - if they're telling me right - effectively makes it act like an active/passive cluster - i.e., only 1 application node is reading/writing a particular file at a time; both nodes are *NOT* trying to read/write to the same file at the same time. Which, to me, means there shouldn't be any file locking issues, but hey, what do I know?).

And my friend the AI Google tells me "While SMB involves various locking mechanisms for file access and concurrency, these are typically managed by the operating system and the SMB protocol itself, not through a simple configuration parameter within Set-SmbServerConfiguration." Which is more or less what I thought, that the OS handles any locking. And I dunno how to tell Windows and/or an SMB protocol to not do any locking. LOL

I also set the “LeasingMode” to “None” on the actual file server itself. Just in case ....

I could stand to be corrected.

On Tuesday, September 2, 2025 at 10:45:09 PM UTC+9:30 Mike Leone wrote:

I am looking for some confirmation. If I issue a 

 set-smbclientconfiguration -UseOpportunisticLocking $FALSE

 set-smbclientconfiguration -OplocksDisabled $TRUE

This would apply to file reads from any drive - i.e., from a local drive, as well as reads performed  on a file share/mapped drive?

--

Mike. Leone, <mailto:tur...@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

--
You received this message because you are subscribed to the Google Groups "ntpowershell" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntpowershell...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ntpowershell/2d9f8724-0963-4851-8e8b-27c4cf009739n%40googlegroups.com.

[con...@cadzow.com.au]

The other thing worth mentioning is that controlling oplocks is not controlling 'locks', it's controlling 'opportunistic' locks. The idea is that the client requests read/write access to a block of data and asks if it can be opportunistic. The server might answer yes or no. If it's opportunistic, the server grants the lock but any other clients that request the block will be only given read-only access. The original client can therefore assume it contains the authoritative version of the data and doesn't need to request another copy to see if it's changed, thereby preserving bandwidth. (This scheme was devised back when networks were routinely 10Mbps or had remote servers on very slow Kbps-type WAN links.) The second client might request an oplock break so it can write to the data, and theoretically the server sends a message to the original client to notify it that the lock is now invalid and it should request the data again. So you can see how this will corrupt databases if all the clients don't play nice. This is all happening in the SMB protocol, not the application. So it's better to turn off oplocks on the server and/or client so they can all read and write blocks of data using a much more reliable scheme. But as I mentioned, if I remember correctly this was all reworked in SMB2 and can no longer be turned off.

So whatever the settings are for oplocks will (a) only affect SMB1 traffic and (b) not affect whether the client or server are doing any 'locking'. The underlying concept of SMB is access to blocks of data. I don't see how an application that does its own locking would care about any 'locking' occurring in the SMB protocol, and I don't see how an application that operates over SMB would want to do its own locking.

Geoff Vass