Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a Samba share on a LAN with 2008 PDC/DNS. Smb authenticates with AD and I have several Win7 Machines that can connect fine.

I recently added a couple of new computers to the LAN which were imaged the same way (same software, etc.; different hardware so different drivers) as the other machines and they have the same policies set.

I can not get the new machines to connect to the samba share no matter what. I am always met with either Unspecified Error 0x80004005 or Network Path not found.

I've turned off the firewall; set LANMAN auth to respond to NTLM only/send LM & NTLM responses/use NTLM session security if negotiated in Local Sec Policy > SEcurity Options; tried both ip and hostname to connect.

SMB log shows that authentication succeeds; but then connection is immediately killed by the client.

tcpdump shows nothing remarkable except that when trying to connect from the client via hostname there is an unknown packet type error:

ack 201 win 255 NBT Session Packet: Unknown packet type 0xABData: (41 bytes)

Here's a couple of lines from that error:

11:18:37.964991 IP 001-client.domain.local.49372 > smb.domain.local.netbios-ssn: P 1670:2146(476) ack 201 win 255 NBT Session Packet: Unknown packet type 0xABData: (41 bytes)
[000] AA 46 96 FA D5 99 33 75  0C C4 20 CE 26 42 F3 61  \252F\226\372\325\2313u \014\304 \316&B\363a
[010] F0 8C FB 65 18 17 40 A5  DB 42 BB 94 37 53 92 EC  \360\214\373e\030\027@\245 \333B\273\2247S\222\354
[020] 55 98 7F C4 AE 3D 6B 10  C4                       U\230\177\304\256=k\020 \304

11:18:37.964998 IP smb.domain.local.netbios-ssn > 001-client.domain.local.49372: . ack 2146 win 100

[edit for strike: this turned out to be an issue with arp cache and the client being issued an old ip from dhcp that previously belonged to another machine]

I'm also getting this error consistently:

[2012/09/10 11:50:00.529650,  2] smbd/sesssetup.c:1413(setup_new_vc_session)
  setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources.

Here's smb.conf just in case (though don't see how if other machines are working fine):

    workgroup = MYDOMAIN
    realm = MYDOMAIN.LOCAL
    server string = domain|smb share
    interfaces = eth1
    security = ADS
    password server =
    log level = 2
    log file = /var/log/samba/%m.log
    smb ports = 139
    strict locking = no
    load printers = No
    local master = No
    domain master = No
    wins server =
    wins support = Yes
    idmap uid = 500-10000000
    idmap gid = 500-10000000
    winbind separator = +
    winbind enum users = Yes
    winbind enum groups = Yes
    winbind use default domain = Yes

    comment = SMB Share
    path = /home/share/smb/
    valid users = @"MYDOMAIN+Domain Users"
    admin users = @"MYDOMAIN+Domain Admins"
    guest ok = no
    read only = No
    create mask = 0765
    force directory mode = 0777

Any ideas what else I could try or look for? Or what might be the problem?


Update 1

Noticed on the other machines that Local Security Policy > LAN Manager authentication level was Not Defined. There is no way to set it as such through the LSP editor, so had to go into regedit and delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\lmcompatibilitylevel

However, this didn't solve the issue. Am now met with Accessing the resource '\\smb\share' has been disallowed. or Unspecified Error depending on who I'm logged in as (regular user == former; admin == latter)

Update 2

It's incredibly frustrating when you ask a question on SF and in the interim keep searching for answers only to find a couple of hours later your own question is repeatedly the first google result ;)

Update 3

I ran Wireshark on the client, and so far as I can tell everything on the Samba end is working correctly. I see in a Negotiate Protocol Request an NT Status of STATUS_SUCCESS (which may very well be the authentication success, but don't know).

Everything is pointing to an issue on the Client itself. On other machines, everything works as expected. Including a VM running on my box. It works using both admin and regular user credentials.

NB the client I'm trying to get this working on has Firewall off and no a/v etc for the time being while trying to work this out.

I've updated the NIC driver and there is only 1 iface available. DNS is working and I've matched up all the settings I can find to the working VM and other working machines.

Getting desperate so any ideas would be awesome.

share|improve this question
up vote 4 down vote accepted

So the issue seems to have been that secpol was set to Digitally Sign Communications (Always).

To fix: Secpol.msc > Local Policies > Security Options > Microsoft network client: Digitally sign communications (always) => Disable


share|improve this answer
SMB signing issues are indeed quite often the cause for connection failures with obscure error messages. But instead of disabling signing altogether, I would advocate enabling it on the Samba server side as it is an important security feature. server signing = mandatory in the [global] section of /etc/samba/smb.conf should take care of the problem. – the-wabbit Mar 5 '15 at 12:04
Maybe this answer might help so that samba signs connections automatically? – djhaskin987 Jun 21 at 19:12

I got 0x80004005 permission error:

enter image description here

for another reason I have no active Client for Microsoft Networks in my WiFi dangle Network panel and:

  • Change Network security: LAN Manager Authentication Level to “Send LM & NTLM responses”
  • Change Minimum Session Security for NTLM SSP to disable “Require 128-bit encryption” into “No Minimum Security”.

and possibly:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.