Bug 442120
| Summary: | CIFS locking issue: multiple clients cannot open same file on 2003 SP1 server | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Vince Worthington <vincew> | ||||
| Component: | kernel | Assignee: | Jeff Layton <jlayton> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Martin Jenner <mjenner> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.1 | CC: | steved, tao | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-04-18 19:38:04 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Created attachment 302174 [details]
test data collected during tests
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... 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). Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. |
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: always 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.... --vince