Bug 5315 - Rename fails on an open file with ShareMode=0
Summary: Rename fails on an open file with ShareMode=0
Status: ASSIGNED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.25b
Hardware: x86 Other
: P3 major
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-09 03:46 UTC by Nick Repin
Modified: 2009-09-17 16:18 UTC (History)
0 users

See Also:


Attachments
Patch for 3.2 (1.33 KB, patch)
2008-03-10 22:44 UTC, Jeremy Allison
no flags Details
Second patch for 3.2 (3.27 KB, patch)
2008-03-11 15:27 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Repin 2008-03-09 03:46:29 UTC
Samba 3.0.25b-1.el5_1.4, on Fedora 7 x86. I believe the error exists in the more recent versions of Samba, too.

I'm renaming an open file on a Samba share (user access) from a Windows Server 2003 SP2 with the following (Windows kernel mode):

      st = ZwCreateFile( &hFile, 
         GENERIC_READ | GENERIC_WRITE | DELETE,
         &tObjAttr, &iosb, NULL, FILE_ATTRIBUTE_NORMAL, 
         SHAREMODE,
         FILE_OPEN, FILE_NON_DIRECTORY_FILE | FILE_SEQUENTIAL_ONLY | FILE_SYNCHRONOUS_IO_NONALERT, NULL, 0 );
     st = ZwSetInformationFile( hFile, &iosb, pInfo, ULONG( nInfoLength ), FileRenameInformation );

When SHAREMODE=0, rename succeeds on Windows-based shares, but fails on a Samba share. I expect it to succeed on Samba shares.

When SHAREMODE=7, rename succeeds on Samba.


Logs:
----------------------------------------
When SHAREMODE=0, rename succeeds on Windows-based shares, but fails on a Samba share. I expect it to succeed on Samba shares.

[2008/03/09 20:43:48, 3] smbd/trans2.c:call_trans2setfilepathinfo(5732)
  call_trans2setfilepathinfo(8) tape2.fsrm (fnum 12970) info_level=1010 totdata=40
[2008/03/09 20:43:48, 10] smbd/trans2.c:smb_file_rename_information(4523)
  smb_file_rename_information: SMB_FILE_RENAME_INFORMATION (fnum 12970) tape2.fsrm -> ./qqq.qqq.fsrm
[2008/03/09 20:43:48, 5] smbd/filename.c:unix_convert(147)
  unix_convert called on file "./qqq.qqq.fsrm"
[2008/03/09 20:43:48, 8] smbd/dosmode.c:dos_mode(371)
  dos_mode: tape2.fsrm
[2008/03/09 20:43:48, 8] smbd/dosmode.c:dos_mode_from_sbuf(188)
  dos_mode_from_sbuf returning a
[2008/03/09 20:43:48, 8] smbd/dosmode.c:dos_mode(409)
  dos_mode returning a
[2008/03/09 20:43:48, 3] smbd/dosmode.c:unix_mode(142)
  unix_mode(tape2.fsrm) returning 0744
[2008/03/09 20:43:48, 10] smbd/open.c:open_file_ntcreate(1184)
  open_file_ntcreate: fname=tape2.fsrm, dos_attrs=0x80 access_mask=0x10000 share_access=0x7 create_disposition = 0x1 create_options=0x0 unix mode=0744 oplock_request=0
[2008/03/09 20:43:48, 8] smbd/dosmode.c:dos_mode(371)
  dos_mode: tape2.fsrm
[2008/03/09 20:43:48, 8] smbd/dosmode.c:dos_mode_from_sbuf(188)
  dos_mode_from_sbuf returning a
[2008/03/09 20:43:48, 8] smbd/dosmode.c:dos_mode(409)
  dos_mode returning a
[2008/03/09 20:43:48, 10] smbd/open.c:open_file_ntcreate(1347)
  open_file_ntcreate: fname=tape2.fsrm, after mapping access_mask=0x10000
[2008/03/09 20:43:48, 5] smbd/files.c:file_new(123)
  allocated file structure 8875, fnum = 12971 (3 used)
[2008/03/09 20:43:48, 10] locking/locking.c:parse_share_modes(507)
  parse_share_modes: delete_on_close: 0, num_share_modes: 1
[2008/03/09 20:43:48, 10] locking/locking.c:parse_share_modes(607)
  parse_share_modes: share_mode_entry[0]:  pid = 10283, share_access = 0x0, private_options = 0x44, access_mask = 0xf01ff, mid = 0x0, type= 0x3, file_id = 2, uid = 500, flags = 2, dev = 0x802, inode = 2490382
[2008/03/09 20:43:48, 10] smbd/open.c:delay_for_oplocks(736)
  Sending break request to PID 10283
[2008/03/09 20:43:48, 10] smbd/open.c:defer_open(802)
  defer_open_sharing_error: time [1205048628.480165] adding deferred open entry for mid 29314
[2008/03/09 20:43:48, 10] smbd/process.c:push_deferred_smb_message(214)
  push_deferred_open_smb_message: pushing message len 120 mid 29314 timeout time [1205048688.480165]
[2008/03/09 20:43:48, 10] smbd/process.c:push_queued_message(110)
  push_message: pushed message length 120 on deferred_open_queue
[2008/03/09 20:43:48, 10] locking/locking.c:unparse_share_modes(665)
  unparse_share_modes: del: 0, tok = 0, num: 2
[2008/03/09 20:43:48, 10] locking/locking.c:print_share_mode_table(482)
  print_share_mode_table: share_mode_entry[0]:  pid = 10283, share_access = 0x0, private_options = 0x44, access_mask = 0xf01ff, mid = 0x7282, type= 0x3, file_id = 2, uid = 500, flags = 2, dev = 0x802, inode = 2490382
[2008/03/09 20:43:48, 10] locking/locking.c:print_share_mode_table(482)
  print_share_mode_table: share_mode_entry[1]:  pid = 10283, share_access = 0x0, private_options = 0x0, access_mask = 0x0, mid = 0x7282, type= 0x20, file_id = 0, uid = 4294967295, flags = 0, dev = 0x802, inode = 2490382
[2008/03/09 20:43:48, 5] smbd/files.c:file_free(454)
  freed files structure 12971 (2 used)
[2008/03/09 20:43:48, 3] smbd/reply.c:rename_internals_fsp(4318)
  rename_internals_fsp: Error NT_STATUS_SHARING_VIOLATION rename tape2.fsrm -> ./qqq.qqq.fsrm


--------------------------------------------------------------


When SHAREMODE=7, renaming succeeds on Samba:

[2008/03/09 21:21:29, 10] smbd/trans2.c:smb_file_rename_information(4523)
  smb_file_rename_information: SMB_FILE_RENAME_INFORMATION (fnum 12975) tape3.fsrm -> ./rrr.rrr.fsrm
[2008/03/09 21:21:29, 5] smbd/filename.c:unix_convert(147)
  unix_convert called on file "./rrr.rrr.fsrm"
[2008/03/09 21:21:29, 8] smbd/dosmode.c:dos_mode(371)
  dos_mode: tape3.fsrm
[2008/03/09 21:21:29, 8] smbd/dosmode.c:dos_mode_from_sbuf(188)
  dos_mode_from_sbuf returning a
[2008/03/09 21:21:29, 8] smbd/dosmode.c:dos_mode(409)
  dos_mode returning a
[2008/03/09 21:21:29, 3] smbd/dosmode.c:unix_mode(142)
  unix_mode(tape3.fsrm) returning 0744
[2008/03/09 21:21:29, 10] smbd/open.c:open_file_ntcreate(1184)
  open_file_ntcreate: fname=tape3.fsrm, dos_attrs=0x80 access_mask=0x10000 share_access=0x7 create_disposition = 0x1 create_options=0x0 unix mode=0744 oplock_request=0
[2008/03/09 21:21:29, 8] smbd/dosmode.c:dos_mode(371)
  dos_mode: tape3.fsrm
[2008/03/09 21:21:29, 8] smbd/dosmode.c:dos_mode_from_sbuf(188)
  dos_mode_from_sbuf returning a
[2008/03/09 21:21:29, 8] smbd/dosmode.c:dos_mode(409)
  dos_mode returning a
[2008/03/09 21:21:29, 10] smbd/open.c:open_file_ntcreate(1347)
  open_file_ntcreate: fname=tape3.fsrm, after mapping access_mask=0x10000
[2008/03/09 21:21:29, 5] smbd/files.c:file_new(123)
  allocated file structure 8880, fnum = 12976 (2 used)
[2008/03/09 21:21:29, 10] locking/locking.c:parse_share_modes(507)
  parse_share_modes: delete_on_close: 0, num_share_modes: 1
[2008/03/09 21:21:29, 10] locking/locking.c:parse_share_modes(607)
  parse_share_modes: share_mode_entry[0]:  pid = 10283, share_access = 0x7, private_options = 0x44, access_mask = 0xf01ff, mid = 0x0, type= 0x10, file_id = 7, uid = 500, flags = 2, dev = 0x802, inode = 2490383
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(428)
  share_conflict: entry->access_mask = 0xf01ff, entry->share_access = 0x7, entry->private_options = 0x44
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(431)
  share_conflict: access_mask = 0x10000, share_access = 0x7
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(480)
  share_conflict: [1] am (0xf01ff) & right (0x6) = 0x6
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(480)
  share_conflict: [1] sa (0x7) & share (0x2) = 0x2
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(482)
  share_conflict: [2] am (0x10000) & right (0x6) = 0x0
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(482)
  share_conflict: [2] sa (0x7) & share (0x2) = 0x2
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(485)
  share_conflict: [3] am (0xf01ff) & right (0x21) = 0x21
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(485)
  share_conflict: [3] sa (0x7) & share (0x1) = 0x1
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(487)
  share_conflict: [4] am (0x10000) & right (0x21) = 0x0
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(487)
  share_conflict: [4] sa (0x7) & share (0x1) = 0x1
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(490)
  share_conflict: [5] am (0xf01ff) & right (0x10000) = 0x10000
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(490)
  share_conflict: [5] sa (0x7) & share (0x4) = 0x4
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(492)
  share_conflict: [6] am (0x10000) & right (0x10000) = 0x10000
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(492)
  share_conflict: [6] sa (0x7) & share (0x4) = 0x4
[2008/03/09 21:21:29, 10] smbd/open.c:share_conflict(494)
  share_conflict: No conflict.
[2008/03/09 21:21:29, 4] smbd/open.c:open_file_ntcreate(1605)
  calling open_file with flags=0x0 flags2=0x0 mode=0744, access_mask = 0x10000, open_access_mask = 0x10000
[2008/03/09 21:21:29, 2] smbd/open.c:open_file(391)
  share opened file tape3.fsrm read=No write=No (numopen=2)
[2008/03/09 21:21:29, 10] locking/locking.c:unparse_share_modes(665)
  unparse_share_modes: del: 0, tok = 0, num: 2
[2008/03/09 21:21:29, 10] locking/locking.c:print_share_mode_table(482)
  print_share_mode_table: share_mode_entry[0]:  pid = 10283, share_access = 0x7, private_options = 0x44, access_mask = 0xf01ff, mid = 0x0, type= 0x10, file_id = 7, uid = 500, flags = 2, dev = 0x802, inode = 2490383
[2008/03/09 21:21:29, 10] locking/locking.c:print_share_mode_table(482)
  print_share_mode_table: share_mode_entry[1]:  pid = 10283, share_access = 0x7, private_options = 0x0, access_mask = 0x10000, mid = 0x0, type= 0x0, file_id = 8, uid = 500, flags = 0, dev = 0x802, inode = 2490383
[2008/03/09 21:21:29, 10] locking/locking.c:parse_share_modes(507)
  parse_share_modes: delete_on_close: 0, num_share_modes: 2
[2008/03/09 21:21:29, 10] locking/locking.c:parse_share_modes(607)
  parse_share_modes: share_mode_entry[0]:  pid = 10283, share_access = 0x7, private_options = 0x44, access_mask = 0xf01ff, mid = 0x0, type= 0x10, file_id = 7, uid = 500, flags = 2, dev = 0x802, inode = 2490383
[2008/03/09 21:21:29, 10] locking/locking.c:parse_share_modes(607)
  parse_share_modes: share_mode_entry[1]:  pid = 10283, share_access = 0x7, private_options = 0x0, access_mask = 0x10000, mid = 0x0, type= 0x0, file_id = 8, uid = 500, flags = 0, dev = 0x802, inode = 2490383
[2008/03/09 21:21:29, 10] locking/locking.c:unparse_share_modes(665)
  unparse_share_modes: del: 0, tok = 0, num: 2
[2008/03/09 21:21:29, 10] locking/locking.c:print_share_mode_table(482)
  print_share_mode_table: share_mode_entry[0]:  pid = 10283, share_access = 0x7, private_options = 0x44, access_mask = 0xf01ff, mid = 0x0, type= 0x10, file_id = 7, uid = 500, flags = 2, dev = 0x802, inode = 2490383
[2008/03/09 21:21:29, 10] locking/locking.c:print_share_mode_table(482)
  print_share_mode_table: share_mode_entry[1]: UNUSED pid = 10283, share_access = 0x7, private_options = 0x0, access_mask = 0x10000, mid = 0x0, type= 0x40, file_id = 8, uid = 500, flags = 0, dev = 0x802, inode = 2490383
[2008/03/09 21:21:29, 2] smbd/close.c:close_normal_file(399)
  share closed file tape3.fsrm (numopen=1) NT_STATUS_OK
Comment 1 Volker Lendecke 2008-03-09 03:52:26 UTC
Please upload network traces of both attempts, against Samba and against Windows.

Thanks,

Volker
Comment 2 Stefan Metzmacher 2008-03-10 04:03:50 UTC
RAW-OPLOCK demonstrates this in the BATCH19 and BATCH20 subtests.

metze
Comment 3 Nick Repin 2008-03-10 04:07:36 UTC
Hi, do you still need the network traces? It will take a few days for me to callect them. Thank you
Comment 4 Nick Repin 2008-03-10 04:08:27 UTC
Sorry, I meant to say "...to collect them".
Comment 5 Volker Lendecke 2008-03-10 04:11:04 UTC
No, I don't think so now that metze has discovered this independently. It might take a few days to fix this though, we're all pretty busy :-)

Volker
Comment 6 Nick Repin 2008-03-10 04:18:47 UTC
There is no rush, take your time. Actually, I found the bug because our clients use NAS devices. It's unlikely they'll update them with your fix any soon. But I thought it makes sense to report it anyway. Thank you
Comment 7 Jeremy Allison 2008-03-10 13:02:27 UTC
This one is very interesting. It's also related I think to the failure of the Samba4 RAW-OPLOCK EXCLUSIVE3 test (when not run in S3 mode). What it looks like is that under circumstances where a file is already open from the same use with the "same" context (not exactly sure yet what I mean by "context" :-) that Windows server re-uses the existing open handle on a trans2 setpathinfo call rather than doing another open.
This explains the rename fail as we always require a second open for setEOF and rename, which conflict with the existing open with SHARE_MODE of zero (no sharing).
Unfortunately, on setEOF the oplock is broken, but on rename it isn't. Minor details I'm sure we can code around :-). Now - how to test my theory..... ?

Jeremy.
Comment 8 Jeremy Allison 2008-03-10 13:07:49 UTC
Ok, I think we can test this theory by writing a test that does the following against Windows :

NtCreateX(exclusive) - returns handle H.
trans2 qfileinfo on handle H SMB_FILE_POSITION_INFORMATION -> save (will be zero).
trans2 setpathinfo SMB_FILE_POSITION_INFORMATION to non-zero.
trans2 qfileinfo on handle H SMB_FILE_POSITION_INFORMATION -> see if it is zero or not.

This should cause Windows server to go down the same codepaths as the SetEOF and Rename cases and allow us to test if the handle is reused. If I'm correct and it is, we then need to determine under what contexts allow reuse (almost certainly matching tid and vuid).

Jeremy.
Comment 9 Jeremy Allison 2008-03-10 22:44:06 UTC
Created attachment 3171 [details]
Patch for 3.2

Here is a patch for the test_raw_oplock_exclusive3() Samba4 torture test (currently not run against the S3 server) - the one that gives the message :

setpathinfo EOF should trigger a break to none

In fixing this I have a good idea how to fix the rename problems reported in this bug - the ones that fail with :

setpathinfo rename info should not trigger a break nor a violation
TEST BATCH19 FAILED! - torture/raw/oplock.c:2099: Incorrect status NT_STATUS_SHARING_VIOLATION - should be NT_STATUS_OK
open a file with an batch oplock (share mode: all)
setpathinfo rename info should not trigger a break nor a violation
TEST BATCH20 FAILED! - torture/raw/oplock.c:2204: Incorrect status NT_STATUS_SHARING_VIOLATION - should be NT_STATUS_OK

as all 3 errors are related I think.

I have a prototype patch for the rename problem but it isn't working yet. I hope to do more on this tomorrow.

Jeremy.
Comment 10 Jeremy Allison 2008-03-11 15:27:03 UTC
Created attachment 3172 [details]
Second patch for 3.2

If you git-pull the 3.2 source code it should now pass your test (I'm hoping). If you can confirm that would be great.
Thanks.

Jeremy
Comment 11 Nick Repin 2008-04-25 03:58:21 UTC
I'm sorry, I'm not very proficient in Linux to easily build Samba from sources. Besides, the patch doesn't work with Samba 3.0.28a apparently because the source files were reformatted.
I'd be happy to test if I had a binary RPM for CentOS.
Thanks
Comment 12 Björn Jacke 2009-09-17 15:56:03 UTC
Nick, did this problem vanish with recent samba releases?
Comment 13 Nick Repin 2009-09-17 16:18:01 UTC
Hi Björn, I am sorry, but I have no ability to test the new version in any foreseeable future. Regards, Nick