| CIFS-shared file not readable: locked | ||
|---|---|---|
 | Part I. Miscellaneous subjects (and those still to be sorted) |  |
| CIFS-shared file not readable: locked | ||
|---|---|---|
| | Part I. Miscellaneous subjects (and those still to be sorted) | |
April 2010
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:
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.