[SOLVED] Samba "oplock break failed" error - cannot open files on SMB share from network

rylan76 · 01-21-2013, 09:44 AM

Hi guys

I'm running Centos 6 with Samba 3.5.4.-68.el6 - it has been working fine for several weeks since I set it up. It is running as fileserver and PDC.

Now, my Windows users on the LAN(on Windows 7) suddenly cannot open certain files on the shares that I set up... If I SSH into the machine, I can copy / access the same files no problem.

/var/log/messages contain entries like:

Code:

Jan 21 16:26:20 machinename smbd[3641]: Oplock break failed for file Print/filename.xls

for each file that they cannot open over the network from the Samba file server.

My smb.conf is:

Code:

[global]	
workgroup = mydomain
server string = Samba Server Version %v
netbios name = DOMPDC
interfaces = lo eth0
hosts allow = 127. 172.
admin users = root
log file = /var/log/samba/log.%m
max log size = 50
security = user
passdb backend = tdbsam
domain master = yes 
domain logons = yes
encrypt passwords = yes
os level = 65
log level = 3
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=16384 SO_SNDBUF=16384
preferred master = auto
local master = yes
wins support = yes
name resolve order = bcast host lmhosts wins
dns proxy = yes
lm announce = no
logon script = %U.bat
logon path = 
logon drive =
#logon drive = O:
load printers = no
time server = yes
ntlm auth = yes
client ntlmv2 auth = yes
client lanman auth = yes
client use spnego = yes
lanman auth = yes
remote announce = 172.16.0.0
deadtime=2
keepalive=10
winbind separator = +
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes
#client use spnego = yes
kernel oplocks = no
	
[HR]
path = /mnt/Users/HR
guest ok = no
writable = yes
create mask = 0777
directory mask = 0777
browseable = yes
public = yes
valid users = sn cg eo nd
Veto files = /*.inf/*.lnk/*.mp3/*.avi/*.mp4/*.divx/*.acc/*.ogg/*.pif/*.cmd/*.exe/

The /mnt/Users/HR share is an NFS4 export from another Linux machine (192.168.1.2). E. g. on the machine containing the physical disc I have an NFS export to the Samba server, which I mount on the Samba server with

Code:

mount 192.168.1.2:/shares/HR /mnt/Users/HR -o user,exec,dev,suid,rw

What can I do to resolve this "oplock break failed" problem?

I have already

Quote:

1. Tried restarting samba.

Within moments of restart the error message again pops up in /var/log/messages

2. Restarting the Windows instances.

Once the user restarts, he still cannot open the file that is named as having an oplock break failure in /var/log/messages.

3. Logged off all users except one (in case there is some contention issue)

I had just one user on the LAN access the files that are having problems, after restarting samba. He can work for a while, but then within about 10 minutes he again cannot access files and the files start appearing in the log with "oplock break failed for file" reported by Samba.

The Samba setup had been working for two or three weeks before this with absolutely no problems, but for some reason it has now started happening.

Any comments or advice appreciated!

Thank you

Ser Olmy · 01-21-2013, 10:27 AM

If this problem suddenly appeared out of the blue even though nothing was changed on either the Samba server or the NFS backend, it could be network related (routers, firewalls, NAT etc). If you've recently introduced new Windows clients running a later version of Windows, it could also be SMB/CIFS related. (Here's some information about SMB/CIFS oplocks.)

"Oplock break failed" means Samba thinks the file is in use and "opportunistically locked" by another client, but is unable to force this client to release the oplock and write cached information back to the file.

There could be several reasons for this. The file may in fact be in use, but something prevents Samba from sending a break message to the client, or it never receives a reply. This could be an SMB dialect issue or simply a bug in Samba.

It is also possible that the file is not actually in use, but Samba believes that it is due to stale session information. In that case, Samba sends a break message to a client that may actually be offline, and once the timeout period has expired you get the "oplock break failed" message in the log.

You could try the following:

- add SO_KEEPALIVE to "socket options" to have Samba check clients for reachability at regular intervals and remove stale sessions

- disable oplocks on the share in question "oplocks = no" (this may affect performance)

- upgrade to the latest Samba release to eliminate protocol/SMB dialect issues

rylan76 · 01-23-2013, 01:32 AM

Thank you for your reply! Helped a lot.

Eventually arrived at this - the problem was mainly with MS-Office files that would not open over the network from the Samba share in Excel and Word:

Still waiting for confirmation from my users, but it seems my problem of Office applications on Windows client machines not being able to open .xlsx / .xls and .docx and .doc files over the network has been solved!

I had to add these options to the [global] of my smb.conf:

Code:

kernel oplocks = no
nt acl support = no
strict locking = no

And to each share definition where I want users capable of opening and saving Office files I added the following - unsure if some of the above overlap with these below:

Code:

[sharename]
.
.
.
oplocks = no
acl check permissions = false
level2 oplocks = no
locking = no
strict locking = no
share modes = no

With Centos 6 Samba 3.5.4-68.el6 "share modes" is complained about as "deprecated" but appears to be still valid.

Once I added the above settings to [global] as indicated and to each share definition in smb.conf as indicated, so far, users on those shares are able to use Excel and Word to open and save files on the Samba file server share without problems. Still waiting for complete confirmation today when everybody comes in to work, but this seems to have solved the issue with interoperation of Samba shares in my environment and MS-Office 2010 applications...

jebe88 · 04-10-2013, 09:29 AM

I had the same problem with MS Office 2010 accessing samba shares of NFS mounts.
After lot of testing I found out, that the problem is due to the fact that the MS Office applications use byte-range locks with additional timeout. So, the only thing I needed to add to my smb.conf was
[share]
blocking locks = no
which disables exactly this timeout-type of byte-range locking mechanism.