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
Reproduced and am investigating this... I think I see the problem. Jeremy.
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
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.
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.
*** Bug 5651 has been marked as a duplicate of this bug. ***
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?
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.
Created attachment 13018 [details] Possible patch for master This is still WIP but makes it work and passes make test.
(In reply to Ralph Böhme from comment #8) Gonna look at this and try and figure it out. Thanks for looking at this properly Ralph !
Created attachment 13048 [details] Patch for 4.6 backported from master All commits cherry-picked besides the last one.
Created attachment 13049 [details] Patch for 4.5 backported from master All commits cherry-picked except the last two test related.
Created attachment 13050 [details] Patch for 4.4 backported from master
Re-assigning to Karolin for inclusion in 4.6.next, 4.5.next, 4.4.next.
(In reply to Jeremy Allison from comment #13) Pushed to autobuild-v4-{6,5,4}-test.
(In reply to Karolin Seeger from comment #14) Pushed to all branches. Closing out bug report. Thanks!