Samba network share issue with Windows 7

Hi all,

Was having an issue here and was hoping someone could offer some assistance.

I have a Linux Box (debian) running with Samba installed and hosting a network share.

I can access the share on a 2 Windows XP machines, a windows Vista machine, AND a modded Xbox with Xbox media center with SMB support. However, for some reason, windows 7 comes up with an error box when I try to connect and says

\\10.0.0.1

More Data is available.

10.0.0.1 being my sharebox/router.

I went into gpedit.msc and then to "Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options" and selected a variety of the choices here but none seem to do the trick

I do have probleme to with a file server under Debian R4 avec Samba.

All work pretty fine with Vista (dual-boot) and from a Xbox with XBMC But from Seven Beta it's really slow and totally unusable.
File explorer freeze each time I navigate intoo file folder that are on the network Drive.
And the copy of video file is pretty impossible.
After few try the connexion is lost but I can still access the serveur via webmin or putty but it can be laggy.

I really don't understand what's goning wrong. I had some similar problem at the beginning with Vista but not at this level !!

Jibbs said:

Hi all,

Was having an issue here and was hoping someone could offer some assistance.

I have a Linux Box (debian) running with Samba installed and hosting a network share.

I can access the share on a 2 Windows XP machines, a windows Vista machine,

Similar problem here (but slightly different). Trying to access a Win7 share from Ubuntu 9.04, I just get a constant log-in dialog box. Works fine to XP...

Tried that - and disabling SMB2 and still no joy.

Gordonbp said:

Tried that - and disabling SMB2 and still no joy.

Disabling SMB2 should be unnecessary because Win7/Vista/Win2K8 will always fall back on SMB1 if the newer variant is not negotiated. In other words, they're just as happy with SMB1 and the choice is automatic depending on the capabilities of the other party.

At this stage, I'd personally be looking at a packet trace to try to understand what's failing and why. If you like, please upload a (zipped) packet trace of the connection attempt and I or somebody else here may be able to help.

(To generate a trace: www.wireshark.com, download, install, start trace, repro connection failure, stop trace, save trace, zip up, upload.)

H2SO4:

First off, thank you for the tip - this solves the issue completely on my end. What I did notice, however, is that prior to changing the authentication method options, I could access the share via \\server_hostname\\share_name\, but not through the server's LAN IP address (both boxes are on the same subnet). When I added the server's ip to /etc/hosts, the share became accessible. Again, this is before modifying auth method preferences.

That would indicate that attempting to access the share through the server's IP address in this case somehow triggers a legacy auth method, as opposed to ntlmv2, correct? If so, do you have any idea as to why this could be occurring?

The server in question is running Samba 3.0.28a.

Thanks again for your help.

trespasser said:

H2SO4:

First off, thank you for the tip - this solves the issue completely on my end. What I did notice, however, is that prior to changing the authentication method options, I could access the share via \\server_hostname\\share_name\, but not through the server's LAN IP address (both boxes are on the same subnet). When I added the server's ip to /etc/hosts, the share became accessible. Again, this is before modifying auth method preferences.

That would indicate that attempting to access the share through the server's IP address in this case somehow triggers a legacy auth method, as opposed to ntlmv2, correct? If so, do you have any idea as to why this could be occurring?

The server in question is running Samba 3.0.28a.

Thanks again for your help.

No problem, glad to hear that worked for you.

The choice of authentication mechanism invoked by the client depends on two main factors:

1) whether the "target" name is IP/FQDN or a single-label hostname,
2) whether the client is a member of an AD domain.

As you've found, the use of an IP address or a FQDN (host.domain.com) as the target causes a different security path to be taken compared to a single-label host. Adding domain membership introduces another layer of complexity because IP/FQDN access will then rely on Kerberos while single-label still falls back on NTLM.

These settings can mostly be controlled through policy, so joining a "real" domain with multiple layers of group policy settings may produce varying results, depending on what the domain admins have specified.

Hope this helps.

Hi Trespasser, I have run into the very same thing where Windows 7 shares and printers are unavailable from my Linux boxes. I get the very same dialog box that regardless of entering my user name and password from windows, it never lets me get to the share or print to the windows shared printer. Please give me details on EXACTLY what you did to solve the problem and indicate all steps for both windows and linux sides.
Thank you

billydv,

I merely followed h2so4's advice above (the post with a screenshot) to change the auth method on my client box.