Strange oplock behavior with Alfresco's CIFS server

[willisadams]

We're running the 201606 Early Release on CentOS 7.

One of my users is having an intermittent problem accessing some files he uploads to the Alfresco server via the built-in CIFS server. 

My user will create a file in Alfresco using the built-in CIFS server.  He will create the file using his desktop PC running Windows 10 or sometimes the file will be created via a network scanner.  When he then tries to access this file on the CIFS server from his other workstation, running Debian 8 (Jessie), he will be unable to do so.

The alfresco.log file shows the following error for each time that he attempts to access the file:

<blockquote>14:53:29,389 ERROR [org.alfresco.fileserver] [AlfJLANWorker9] Failed to defer request for local oplock break, oplock=[Local Type=Exclusive,\Sites\customer-service\documentLibrary\James Files\2113sn.pdf,Owner=T1,PID=15136,UID=5,TreeID=1,FileId=3,DeferList=3 BreakInProgress]
</blockquote>

But if he logs into the Alfresco Share through his web browser and renames the file then he'll be able to access it on his Debian machine.  (If he re-names the file again, back to its original name, the error returns.)

Note that this does not happen with all or even most of his files.  The vast majority of the time he has no problems at all downloading files he's uploaded to the CIFS server.  This has happened only a handful of times over the past week or so.

Also, even though we have about a dozen users who have uploaded a combined tens of thousands of documents since we've started using Alfresco last year, we have not previously encountered this problem.

Any ideas on what the problem could be and what steps I could take in order to resolve it?  Please let me know if you need more information.

[afaust]

I fear no one will be able to really explain the cause / behaviour in detail as CIFS / SMB1 is an archaic protocol. As far as I know, oplocks are not persisted to the database and only held in memory. They are identified by name instead of node identity, which explains why a simple rename can help circumvent the issue. A restart of the server will cause in all oplock state to be discarded and each file should be clean of any residual oplocks that may not have been cleard.

[willisadams]

Thanks for the reply, Axel.  I did restart Alfresco which temporarily released the lock.  Unfortunately, the lock came back after a few minutes.  The next day the lock was gone.  I suspect there's a program running on either the user's Windows 10 machine or their Debian machine which is locking the files, but I haven't narrowed it down to which program just yet.  I'd appreciate any suggestions that you might have for troubleshooting this the next time it happens.  Is there a Linux equivalent to the "Process Explorer" application in Windows where I can search for which programs are accessing a particular file? 

If all else fails, I can use WebDAV instead of SMB for the Windows 10 and Debian machines, but our network scanner only supports SMB, unfortunately.

[afaust]

Well on any Linux machine you have to typical tools such as top, ps and lsof to find out what is going on. These are all command line utilities, but there may also be graphical UIs similar to the process explorer (on Linux I never feel the need for a graphical UI - real men use command line tools, as my old CTO used to say).

[willisadams · Accepted solution]

Just to follow-up...  I think I was able to isolate the issue to the Debian workstation that had Alfresco mounted as a CIFS/SMB share.  Once I changed that system to mount Alfresco using WebDAV instead (using davfs2) the locking issues haven't reappeared. 

I was not able to figure out why Debian was behaving the way it was, though.  I suspect it has something to do with Mozilla Thunderbird, though.  The issue always seemed to start when the user would attempt to attach a file stored on Alfresco to an email.  I'm not enough of a Linux guru to figure it out, but maybe this will be a clue for someone more knowledgeable in the future who has this problem.