CIFS-shared file not readable: locked

This case is somewhat reminiscent of : We have a Samba server configured

[global]
disable netbios = yes
workgroup = LWP
security = user
browseable = no
mangled names = no
unix extensions = yes
; create mask = 0644
; Create mask off and map archive =no on by to get permissions right - JB 20100312
map archive = no

kernel oplocks = False

log level = 3

passdb backend = ldapsam:ldaps://ldapserver.mydomain.com
ldap suffix = <snipped>
ldap passwd sync = no
ldap admin dn = <snipped>

load printers = no
printing = bsd
printcap name = /dev/null
show add printer wizard = no
disable spoolss = yes

encrypt passwords = true

#  smb encrypt = mandatory
#  update encrypted = yes
#  client signing = mandatory

<snip>

[apps]
path = /srv/apps
read only = yes
guest ok = yes
    

The program acroread is on [apps], and we have a client that mounts [apps].

Presumably, an earlier instance of acroread crashed, and now when we try to start it, it says:

Indeed, /opt/netapps/Adobe/Reader9/Reader/intellinux/bin/acroread is locked according to the server:

and we cannot even cat the file on the client, and this is true for all the clients.

Unmounting the users' CIFS mount from the client, even rebooting the client does not terminate the smbd process on the server that holds the lock. Sending it SIGKILL does, and immediately makes acroread available to all users again.

Based on the Samba locking docs and the Advanced Disk Shares chapter of the online O'Reilly Samba book, I believe that we should reconfigure it with fake oplocks turned on and byte range locks off:

  fake oplocks = yes
  locking = no
    

Even though [apps] isn't on a read-only medium, the files there are never supposed to be locked by any single client, but it doesn't hurt to allow the extra caching that oplocking actually is.