Bug 8670 - Kernel patch seems to break sharing an NFS mount with Samba
Kernel patch seems to break sharing an NFS mount with Samba
Status: NEW
Product: Samba 3.5
Classification: Unclassified
Component: File services
3.5.12
All All
: P5 normal
: ---
Assigned To: Volker Lendecke
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-19 12:47 UTC by joschibrauchle
Modified: 2011-12-19 13:13 UTC (History)
0 users

See Also:


Attachments
smb.conf (456 bytes, text/plain)
2011-12-19 12:47 UTC, joschibrauchle
no flags Details
Log from SLES11SP1 kernel 2.6.32.12 - working (487.51 KB, text/plain)
2011-12-19 12:49 UTC, joschibrauchle
no flags Details
Log from SLES11SP1 kernel 2.6.32.29 - not working (19.27 KB, text/plain)
2011-12-19 12:50 UTC, joschibrauchle
no flags Details
Strace on smbd on kernel 2.6.32.29 - not working (3.57 MB, text/plain)
2011-12-19 12:51 UTC, joschibrauchle
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description joschibrauchle 2011-12-19 12:47:23 UTC
I am reporting a problem that was originally posted to the samba list by Philip Ong: http://lists.samba.org/archive/samba/2011-October/164564.html

Scenario:
Server with Samba 3.5.12, exporting a share that is mounted via NFS.
Samba config includes (default setting):
-------
kernel oplocks = yes
-------

Problem:
Kernel commit (for SLES11 SP1 http://kernel.opensuse.org/cgit/kernel/commit/?h=SLE11-SP1&id=dd143426eaaadea159c8dd2d3c9ff5e9da94bcfd) seems to break the copying/saving of files to such a share, which was possible before this commit.

Steps to reproduce:
0) use kernel that include above mentioned commit
1) mount NFS share without "nolock" option
2) share NFS mount via Samba
3) copy or save a file on Samba share

Actual result:
Error Message when saving or copying a file to such a share:
 - Windows client: "The process cannot access the file because another process has locked a portion of the file"
 - In log.smbd: "smbd/oplock_linux.c:120(linux_set_kernel_oplock)
  linux_set_kernel_oplock: Refused oplock on file <FILENAME>, fd = 32, file_id = 15:100811:0. (Invalid argument)"

Expected result: 
Saving/copying files on share works without problems.

Possible solutions:
a) revert to a kernel without the mentioned patch
b) turn off kernel oplocks with: "kernel oplocks = yes"
c) mount NFS share with "nolock" option

Please find attached:
- smb.conf
- debug level 10 log of working kernel without mentioned patch
- debug level 10 log of non-working kernel including the patch
- strace of smbd on non-working kernel (taken at different time instance with different user)
Comment 1 joschibrauchle 2011-12-19 12:47:49 UTC
Created attachment 7204 [details]
smb.conf
Comment 2 joschibrauchle 2011-12-19 12:49:18 UTC
Created attachment 7205 [details]
Log from SLES11SP1 kernel 2.6.32.12 - working

User brauchle succesfully saves "New Text Document.txt"
Comment 3 joschibrauchle 2011-12-19 12:50:10 UTC
Created attachment 7206 [details]
Log from SLES11SP1 kernel 2.6.32.29 - not working

User brauchle tries to save "New Text Document.txt", which fails
Comment 4 joschibrauchle 2011-12-19 12:51:03 UTC
Created attachment 7207 [details]
Strace on smbd on kernel 2.6.32.29 - not working

User "zzteststaff" tries to save "New Text Document.txt", which fails
Comment 5 joschibrauchle 2011-12-19 12:51:54 UTC
NFS mount (no custom options):
mount -t nfs <SERVER>:<PATH> /mnt
Comment 6 joschibrauchle 2011-12-19 12:55:06 UTC
For the possible solutions I have an obvious typo:
b) turn off kernel oplocks with: "kernel oplocks = no"
Comment 7 joschibrauchle 2011-12-19 12:56:25 UTC
(In reply to comment #3)
> Created attachment 7206 [details]
> Log from SLES11SP1 kernel 2.6.32.20 - not working
> 
> User brauchle tries to save "New Text Document.txt", which fails
An here this is kernel 2.6.32.29 of SLES11SP1...
Comment 8 joschibrauchle 2011-12-19 13:13:24 UTC
Actually I just noticed that BOTH logs (working and non-working case) contain the line:
linux_set_kernel_oplock: Refused oplock on file ... (Invalid agrument)

But the non-working one somewhere later fails with "NT_STATUS_FILE_LOCK_CONFLICT"