Bug 442120 - CIFS locking issue: multiple clients cannot open same file on 2003 SP1 server
CIFS locking issue: multiple clients cannot open same file on 2003 SP1 server
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jeff Layton
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2008-04-11 16:21 EDT by Vince Worthington
Modified: 2014-06-18 03:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-18 15:38:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test data collected during tests (1.21 MB, application/octet-stream)
2008-04-11 17:46 EDT, Vince Worthington
no flags Details

  None (edit)
Description Vince Worthington 2008-04-11 16:21:26 EDT
Description of problem:
Multiple RHEL5 clients cannot open same OpenOffice Writer document on Windows
2003 SP1 server share mounted via CIFS due to NT_STATUS_LOCK_CONFLICT

Version-Release number of selected component (if applicable):
All RHEL5 kernel versions (jlayton's -86 test kernel most recently tested)
samba-3.0.25b-1.el5_1.4 (if even important)

How reproducible:

Steps to Reproduce:
1. Mount share from Windows-Fileserver via mount.cifs on both machines
2. Open an existing document from within OpenOffice Writer on client machine 1:
-> Works: file is opened in read-write-mode
3. Open the same document from within OpenOffice Writer on client machine 2
(while it is still opened on client machine 1):

Actual results:
Open fails with dialog to select file type/format for the file

Expected results:
File opens read-only for 2nd client

Additional info:
In discussing with Jeff and looking at straces etc. this appears to be expected
behavior.  oowriter on the first client first opens the file readonly, then once
this succeeds, closes and re-opens the file readwrite and uses fcntl() to set
F_WRLCK on the file:

12:20:48.739288 open("/mnt/tmp/WHATSNEW.doc", O_RDWR) = 34
12:20:48.741040 fcntl(34, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0,
len=0}) = 0

This causes the file to be locked on the 2003 server.  As a result, when the
next client opens the file, the file open succeeds, but attempts to read fail:

12:21:57.474083 open("/mnt/tmp/WHATSNEW.doc", O_RDONLY|O_LARGEFILE) = 33
12:21:57.481314 read(33, 0xb25f26d0, 4) = -1 EACCES (Permission denied)
12:21:57.503099 fcntl64(33, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0,
len=0}, 0xbfc90744) = 0
12:21:57.504082 close(33)

the error seen in the tcpdump from the 2003 server is NT_STATUS_LOCK_CONFLICT.

will follow up with data collected and with some info about where in the
data/log files the behavior is seen.

The customer is expecting "second/additional" openers to be able to open the
file but only be able to open it read-only, as occurs when the file is on local
storage.  We've already explained that the F_WRLCK is an advisory lock, but this
doesn't exactly translate to CIFS/SMB.  The customer is still looking for a way
to do this....

Comment 2 Vince Worthington 2008-04-11 17:46:55 EDT
Created attachment 302174 [details]
test data collected during tests
Comment 5 Jeff Layton 2008-04-18 15:04:11 EDT
One of the reasons that the default mode on CIFS shares without posix extensions
has the sgid bit set but the group execute bit cleared is because windows
enforces mandatory locking. Unfortunately, changing this mode does not disable
mandatory locks.

I think this is not something fixable due to limitations on the server. With
CIFS, we do "best-effort" to map POSIX semantics onto windows shares. This is
one place where they just don't match up.

My recommendation would be to consider a samba server to store these documents
on. The windows machines could still access them, and Linux boxes mounting with
CIFS could use posix extensions to get advisory locking. It's not clear to me,
however, how well this would work if you, say had a windows and linux machine
open and try to lock the same file, but I believe it will probably work well
enough (the samba guys are pretty good at this).

It's probably worth experimenting with -- if you do, let me know what you find...

If they want or must use this server for some reason, then they'll probably need
to consider mounting with "-o nobrl". Of course though, that will disable
byte-range locks altogether (they'll always return successful) and they'll need
to be very careful to prevent data corruption.

I've actually not played much with CIFS brl's with unix extensions enabled, so
I'll plan to do that in the next day or two. Still though, you'll probably want
to communicate to the customer that this is not likely to be fixable and they
should probably explore other options...
Comment 6 Jeff Layton 2008-04-18 15:36:53 EDT
Yes. Using a samba server should give them appropriate posix semantics
(everything should just work as long as POSIX extensions are working). Aside
from that I don't see much in the way of options...

They might be able to use the Microsoft SFU NFS server. That might be a
possibility if they're stuck with this server (though I'm not at all sure what
the locking semantics are like with that server).

Comment 7 RHEL Product and Program Management 2008-04-18 15:38:04 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 

Note You need to log in before you can comment on or make changes to this bug.