CIFS-shared file not readable: locked

Jurjen Bokma

April 2010


This case is somewhat reminiscent of Conference under Docker: 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:

user@client:~$ acroread
> exec: 691: /opt/netapps/Adobe/Reader9/Reader/intellinux/bin/acroread: 
> Resource temporarily unavailable

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

user@server:~$ sudo smbstatus |egrep 'acroread|^Pid'
Registered MSG_REQ_POOL_USAGE
Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED
lp_load_ex: refreshing parameters
Initialising global parameters
params.c:pm_process() - Processing configuration file "/etc/samba/smb.conf"
Processing section "[global]"
Processing section "[homes]"
Processing section "[apps]"
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
29835        65534      DENY_NONE  0x120089    RDONLY     EXCLUSIVE        /srv/apps   Adobe/Reader9/Reader/intellinux/bin/acroread   Thu Apr 15 09:45:21 2010    

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.