Bug 8115 - Windows 7 SP1 - Unable to browse share using SMB2
Summary: Windows 7 SP1 - Unable to browse share using SMB2
Status: RESOLVED WONTFIX
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: SMB2 (show other bugs)
Version: 3.5.6
Hardware: All All
: P5 major
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-01 21:19 UTC by samba_bugs
Modified: 2011-05-03 00:37 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description samba_bugs 2011-05-01 21:19:38 UTC
Hi,
I am using Samba Server Version 3.5.6 with enabled SMB2 quiet a while now without any problems. Used clients are Windows 7 x64, Windows XP x32 and MacOS.

Now I got new Notebook with a fresh install of Windows 7 SP1 x64. With this system it is not possible to get a list of shares when using \\name . There is a 0x80070035 error (Network path not found). Running the windows diagnostics, the given error is "\\name\IPC$" could not be found". I switched between SMB2 and NT1 several times and as soon as I use NT1 the error disappears. The other machine with Windows 7 x64 (without SP1) reports no errors at all, regardless of NT1 or SMB2.
When using SMB2 it is still possible to access data when directly accessing the shares using \\name\share1, even browsing is possible then.

The behaviour seems to be identical to that one reported in bug 7078, but there was another version used and for me the error only occurs with Windows 7 SP1.

Please let me know, if you need further information, as this is my first reported bug.

Best regards,
Matthias
Comment 1 Jeremy Allison 2011-05-03 00:37:49 UTC
SMB2 is not fully supported in 3.5.x, it's classified as "experimental".

Please test with the latest 3.6.0 pre release and see if you can reproduce this. We're not officially supporting SMB2 in 3.5.x, it was designed for OEM's to test against (which they did and hence the full SMB2 support built into 3.6.0).

Jeremy.