map network drive to NAS but get error 64 or 58

[mrstrong]

Hi,

 

I'm trying to map a network drive to our NAS (a QNAP) via

net use s: \\qnap\share

but get

System error 64 has occurred.

or

System error 58 has occurred.

 

Tried posting on qnap and MS forums but no joy

 

FYI

Qnap is joined to our windows server 2008 R2 domain

Other identical windows 7 laptops map the drive fine

No errors in windows event logs

The laptop maps other network drives to other shares on a 2008 R2 server just fine

and all other networking appears ok, e.g. internet.

 

Tried with wired / wireless, different user(network admin login), removed and re-joined laptop to domain, updated group policy

Still same error every time.

 

At a loss as to how to proceed with troubleshooting this issue.

Wireshark to see if samba errors ?

Never used Wireshark before so may need a good tutorial!

 

Any advice welcome as it's driving me mad now.

Ed

[cpjitservices]

Is it an NFS Share and are you using Windows 7 Pro ? IF you are 7 Pro wont mount/map an NFS share.

[mrstrong]

Yes it's win 7 pro and I can map it fine on other win 7 pro laptops (of the same make and model).

Guess it's samba ?

[cpjitservices]

Have you turned the Windows firewall off on the PC's just to rule that out... or if it's off already turn it on.. ?

[Duke5A]

Hmm, might be an NTLMv1 vs NTLMv2 issue. You can try changing the negotiation policy using gpedit.msc on the Windows 7 box.

 

Computer Configuration > Windwos Settings > Security Settings > Local Policies >Security Options > "Network Security: LAN Manager authentication level

 

Change it to 'Send LM & NTLM - use NTLMv2 session security if negotiated' and restart the system.

[mrstrong]

Hi,

 

Yes Windows firewall is off.

Thanks Duke5A, I'd already tried that tweak

[mrstrong]

Looking in event logs found error about virtualbox guest additions

so uninstalled as not needed (was left in the original PC image).

 

Is it possible the windows network software could have been messed up by this ?

 

Ipconfig is showing several disconnected adapters

(and one working wireless LAN adapter)

E.g. "Tunnel adapter"

"Tunnel adapter isatap"

 

Is there a way to reinstall just "microsoft networking" e.g. the TCP/IP stack components?

May be worth a try ?

[mac_shinobi]

You can reset the tcp.ip stack and winsocks by running a command prompt as admin --> using the two netsh commands

 

TCP/IP Reset

 

http://support.microsoft.com/kb/299357

 

netsh int ip reset c:\resetlog.txt

 

Winsock Reset

 

http://windowsxp.mvps.org/winsock.htm

 

netsh winsock reset catalog

 

Can also look at the hosts file and reset that to defaults ?

Edited April 29, 2013 by mac_shinobi

[mrstrong]

Thanks mac_shinobi, I'll give that a try

[AJWhite1970]

Bit of a long shot but this hotfix came out last week, may be worth a try?

 

Error message when you try to map a drive to a network share in Windows 7 or Windows Server 2008 R2

 

Andrew

[DMcCoy]

Always remember to check the clocks on the server/nas and workstation. If it's more than 5 minutes difference then it's probably not going to authenticate.

[mrstrong]

mac_shinobi: tcp reset didn't work ...

 

but looking again in the event logs there are some suspicious entries.

 

Event ID 5719 Source NETLOGON

Google brings up loads of stuff on this

I'm thinking maybe it's ok e.g. from reading "More information" at Event ID 5719 is logged when you start a computer

 

Event ID 1001 Source Dhcp-Client

Again this is ok I think as ipconfig shows I have got a valid IP and all other networking seems to work fine, just can't

connect to QNAP.

 

I tried running gpupdate and in the logs I can see:

 

Event ID 4321 Source NetBT

 

The name "our-domain-name :1d" could not be registered on the interface with IP address laptops-ip-address. The computer with the IP address QNAPs-ip-address did not allow the name to be claimed by this computer.

 

And finally a

 

Event ID 1030 Source GroupPolicy

 

Not sure if this could be the issue ?

 

Checked the clocks are set fine.

I'll take a look at the hotfix, thanks.

[mac_shinobi]

For synology nas devices but same windows error messages - may point you in the right direction / give you some clues ref the errors

 

http://forum.synology.com/wiki/index.php/Tips_and_common_error_messages_for_Windows_when_mapping_a_network_drive

[southhamster]

I've seen this problem connecting to a QNAP 219 Pii from a win 7 client.apologies if you've tried it, but using the server IP instead pg the name fixed it got me

[m25man]

I posted about this years ago regarding NAS mappings.

http://www.edugeek.net/forums/windows-7/84160-problems-accessing-nas-windows-7-clients.html#post741942

 

Since Win7 was introduced Kerberos is used by default in a Windows domain, when a windows client attempts to establish a secure connection to a UNC path using Netbios names it will use Kerberos in a Windows manner which your NAS just doesn't understand.

When connecting by \\ipaddress\path the client assumes Linux or NTLM and all is well.

 

This can be managed using GP but there are penalties for dumbing down your security, by making your clients more NAS friendly you are enabling ways of allowing connections to be established under the radar so to speak so worms etc have another route into your file systems.

[mrstrong]

Hi,

 

thanks for the info which is very interesting.

 

Unfortunately it doesn't fix my issue.

 

I get the same error with \\name and \\IP

 

Plus already tried send LM and send LM & NTLM only

 

Was thinking of re-installing "client for microsoft networks" but on a netbook

so no drive for windows dvd.

[mac_shinobi]

Image via the network ( WDS / PXE boot / WinPE bootable usb and imagex to apply a wim ) or something along those lines ?

[mrstrong]

Think I've found it

 

manually changed all "local policies -> security options" via secpol.msc on a bad client to match those on a good client and what do you know ?

net view \\NAS

now working like a good 'un! MS son of a ...

About 10 diffs and needed a reboot to pick up so not sure which one(s) did the trick.

Will investigate some more and post back

[mac_shinobi]

Think I've found it

 

manually changed all "local policies -> security options" via secpol.msc on a bad client to match those on a good client and what do you know ?

net view \\NAS

now working like a good 'un! MS son of a ...

About 10 diffs and needed a reboot to pick up so not sure which one(s) did the trick.

Will investigate some more and post back

 

That is good to know although with ref to the NTLM setting I'm sure it was suggested to use the below setting

 

Change it to 'Send LM & NTLM - use NTLMv2 session security if negotiated'

 

 

Hmm, might be an NTLMv1 vs NTLMv2 issue. You can try changing the negotiation policy using gpedit.msc on the Windows 7 box.

 

Computer Configuration > Windwos Settings > Security Settings > Local Policies >Security Options > "Network Security: LAN Manager authentication level

 

Change it to 'Send LM & NTLM - use NTLMv2 session security if negotiated' and restart the system.

[mrstrong]

Hi,

 

yes

'Send LM & NTLM - use NTLMv2 session security if negotiated' and restart the system

 

was one of the first things I tried but it was not enough on it's own.

 

Actually on a working client I had

Network security: LAN Manager authentication level	Not Defined

I.e. no registry key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

 

Looks like the security options on the bad client have been changed from the defaults (though not sure how?!)

as the bad client was imaged from a working client.

 

Found this article on how to reset them

How to reset all Windows 7 or Vista Security settings to its default values

But then read

How do I restore security settings to a known working state?

which says that method is not supported on vista upwards:

may even result in the operating system becoming unstable

so decided to just change manually to match a working client

 

Made changes one at a time with a reboot after each change:

 

Network security: Minimum session security for NTLM SSP based (including secure RPC) clients	Require 128-bit encryption
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers	Require 128-bit encryption
Network access: Do not allow anonymous enumeration of SAM accounts and shares	Disabled

 

Then after this change everything starts working:

Microsoft network client: Digitally sign communications (always)	Disabled

 

Some other differences e.g. Microsoft network server: Digitally sign communications (always) was Enabled

when default says should be disabled but not relevant in this client scenario.

 

Annoying the MS net command didn't give me a good error message but at least I've learnt a bit and got it working

in the end

 

Thanks

[mac_shinobi]

What were you using to change the settings on the bad non working client. Local security policy editor or you using and creating the reg keys or importing the reg keys from a working pc or what exactly. Also thanks for the update !!

[mrstrong]

Nothing clever: just ran secpol.msc locally on a bad client and changed the settings manually.

Only seen a few bad clients so far so a manual fix won't be too onerous.

 

You've got me thinking though, is there a more efficient way to roll this out to all clients, e.g. can it be done via group policy

or a startup script that loads the registry values? And is there an easy way to identify which registry entries relate to specific secpol.msc settings ?

[mac_shinobi]

Nothing clever: just ran secpol.msc locally on a bad client and changed the settings manually.

Only seen a few bad clients so far so a manual fix won't be too onerous.

 

You've got me thinking though, is there a more efficient way to roll this out to all clients, e.g. can it be done via group policy

or a startup script that loads the registry values? And is there an easy way to identify which registry entries relate to specific secpol.msc settings ?

 

Something like regshot :

 

regshot | Free System Administration software downloads at SourceForge.net

 

Snapshot before changing the settings and then a snapshot afterwards and it should give you a registry file that you could try and push out via GPO or the likes

 

regedit.exe \\server\reg\patch.reg /s

 

something like the above to apply it silently ( obviously that should be the unc path to the relevant registry file.

[mrstrong]

thanks,

 

just fixed another one with only 3 changes so to summarize here's what was changed via secpol.msc under

Security Settings->Local Policies->Security Options

Might help some other poor sod

 

Microsoft network client: Digitally sign communications (always)	Disabled
Network security: LAN Manager authentication level	Send LM & NTLM - use NTLMv2 session security if negotiated
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients	Require 128-bit encryption

[mac_shinobi]

Thanks for the update and like you said - will help someone else out at some point hopefully