Bug 7537 - streams_xattr and kernel oplocks results in NT_STATUS_NETWORK_BUSY
streams_xattr and kernel oplocks results in NT_STATUS_NETWORK_BUSY
Status: ASSIGNED
Product: Samba 3.5
Classification: Unclassified
Component: VFS Modules
3.5.4
Other Linux
: P3 normal
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
: 5651 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-30 03:24 UTC by Björn Jacke
Modified: 2016-02-23 05:42 UTC (History)
7 users (show)

See Also:


Attachments
Patch that fixes it in master. (751 bytes, patch)
2010-07-02 17:31 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Jacke 2010-06-30 03:24:52 UTC
when a windows client want to write a stream, in this case the summary information on a .txt file, then Samba returns NT_STATUS_NETWORK_BUSY ("Network is busy"). Disabling kernel oplocks solves this error. This was tested with kernel versions 2.6.32 and 2.6.34 and samba 3.5.4.

This is reproducible with a straight forward smb.conf with a share with streams_xattr enabled. On an XP client just create a txt document, enter some summary information in the properties dialog and try to save.

[2010/06/29 18:32:26.377193, 10] modules/vfs_streams_xattr.c:366(streams_xattr_open)
  streams_xattr_open called for Neuer Ordner/Neu Textdokument.txt:{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}:$DATA
[2010/06/29 18:32:26.377217, 10] modules/vfs_streams_xattr.c:123(streams_xattr_get_name)
  xattr_name: user.DosStream.{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}:$DATA, stream_name: :{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}:$DATA
[2010/06/29 18:32:26.377236, 10] modules/vfs_streams_xattr.c:366(streams_xattr_open)
  streams_xattr_open called for Neuer Ordner/Neu Textdokument.txt
[2010/06/29 18:32:26.377264, 10] smbd/open.c:167(fd_open)
  fd_open: name Neuer Ordner/Neu Textdokument.txt:{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}:$DATA, flags = 0102 mode = 0760, fd = -1. Resource temporarily unavailable
[2010/06/29 18:32:26.377290,  3] smbd/open.c:458(open_file)
  Error opening file Neuer Ordner/Neu Textdokument.txt:{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}:$DATA (NT_STATUS_NETWORK_BUSY) (local_flags=66) (flags=66)
[2010/06/29 18:32:26.377312,  5] smbd/files.c:497(file_free)
  freed files structure 10710 (3 used)
[2010/06/29 18:32:26.377329, 10] smbd/open.c:3244(create_file_unixpath)
  create_file_unixpath: NT_STATUS_NETWORK_BUSY
[2010/06/29 18:32:26.377352, 10] lib/dbwrap_tdb.c:100(db_tdb_fetch_locked)
  Locking key 11080000000000006482
[2010/06/29 18:32:26.377373, 10] lib/dbwrap_tdb.c:129(db_tdb_fetch_locked)
  Allocated locked data 0x0xb89a83d0
[2010/06/29 18:32:26.377389, 10] locking/locking.c:552(parse_share_modes)
  parse_share_modes: delete_on_close: 0, owrt: Di 29 Jun 2010 18:30:01 CEST CEST, cwrt: Do 01 Jan 1970 01:00:00 CET CET, tok: 0, num_share_modes: 2
[2010/06/29 18:32:26.377429, 10] locking/locking.c:655(parse_share_modes)
  parse_share_modes: share_mode_entry[0]:  pid = 5556, share_access = 0x7, private_options = 0x0, access_mask = 0x20089, mid = 0x0, type= 0x3, gen_id = 3883, uid = 1000, flags = 0, file_id 811:8264:0
[2010/06/29 18:32:26.377456, 10] locking/locking.c:655(parse_share_modes)
  parse_share_modes: share_mode_entry[1]:  pid = 5556, share_access = 0x7, private_options = 0x0, access_mask = 0x80, mid = 0x0, type= 0x0, gen_id = 3886, uid = 1000, flags = 0, file_id 811:8264:0
[2010/06/29 18:32:26.377476, 10] locking/locking.c:726(unparse_share_modes)
  unparse_share_modes: del: 0, owrt: Di 29 Jun 2010 18:30:01 CEST CEST cwrt: Do 01 Jan 1970 01:00:00 CET CET, tok: 0, num: 2
[2010/06/29 18:32:26.377514, 10] locking/locking.c:518(print_share_mode_table)
  print_share_mode_table: share_mode_entry[0]:  pid = 5556, share_access = 0x7, private_options = 0x0, access_mask = 0x20089, mid = 0x0, type= 0x3, gen_id = 3883, uid = 1000, flags = 0, file_id 811:8264:0
[2010/06/29 18:32:26.377541, 10] locking/locking.c:518(print_share_mode_table)
  print_share_mode_table: share_mode_entry[1]: UNUSED pid = 5556, share_access = 0x7, private_options = 0x0, access_mask = 0x80, mid = 0x0, type= 0x40, gen_id = 3886, uid = 1000, flags = 0, file_id 811:8264:0
[2010/06/29 18:32:26.377562, 10] lib/dbwrap_tdb.c:42(db_tdb_record_destr)
  Unlocking key 11080000000000006482
[2010/06/29 18:32:26.377594,  2] smbd/close.c:656(close_normal_file)
  dos1106 closed file Neuer Ordner/Neu Textdokument.txt (numopen=2) NT_STATUS_OK
[2010/06/29 18:32:26.377613,  5] smbd/files.c:497(file_free)
  freed files structure 10709 (2 used)
[2010/06/29 18:32:26.377630, 10] smbd/open.c:3487(create_file_default)
  create_file: NT_STATUS_NETWORK_BUSY
Comment 1 Jeremy Allison 2010-06-30 14:19:05 UTC
Reproduced and am investigating this...

I think I see the problem.

Jeremy.
Comment 2 Volker Lendecke 2010-07-01 03:43:53 UTC
This is a known issue. streams_xattr and kernel oplocks just don't go together. The fix is a bit invasive. I did not have time to do it when I discovered it.

Volker
Comment 3 Björn Jacke 2010-07-01 04:21:07 UTC
if this is a known issue this should really be mentioned in the man page and in the log files when streams_xattr is being used and kernel oplocks are not disabled.
Comment 4 Jeremy Allison 2010-07-02 17:31:15 UTC
Created attachment 5824 [details]
Patch that fixes it in master.

Ok, this fixes it - but the problem is it then breaks oplocks on the base file when we open a stream....

I can't see any other way to address this :-(.

Jeremy.
Comment 5 Björn Jacke 2012-08-22 09:38:09 UTC
*** Bug 5651 has been marked as a duplicate of this bug. ***
Comment 6 Björn Jacke 2012-08-22 09:41:44 UTC
Volker, Jeremy: do you see a way for a fix here or should we add a big log level 0 warning at loading time of streams_xattr that kernel oplocks and streams_xattr should not be used together?
Comment 7 Volker Lendecke 2012-08-22 15:24:13 UTC
In theory it should be fixable. But the oplock and kernel oplock interactions are tricky, so without a dedicated need from someone who puts budget into it I don't see this happening any time soon.