Dreaded Win7 0x80070035 with Samba

I have a Win7 machine which is connected to a perfectly ordinary Samba share. Suddenly, it has started refusing to connect to it with error 0x80070035 -- "the network path was not found". Attempting to login with its IP address \\192.168.x.x does not work either. When I attempt to diagnose the problem, it helpfully tells me that there's nothing there to connect to, which I know is complete baloney. I can ping the IP address. I can ping the server by hostname. I can even ping it by its SAMBA name. It just never tried.

Checking in the firewall settings, "file and printer sharing" was disabled. Enabling it made zero difference. I also made sure 'network discovery' and 'core networking' weren't firewalled.

I set the NTLM authentication level to 2 in the registry as many things suggest(being Win7 Home, Microsoft helpfully removed the control panel applet to manage that properly), this also made no difference.

I've uninstalled any antivirus and firewall products, and disabled the firewall on the server itself for the time being.

Enabling NETBIOS under WINS settings inside TCP/IP advanced settings made no difference.

I've updated to a newer version of Samba(inconveniencing the office as everyone needed to put their passwords back in) to no effect.

Another identical(same model, same OS, same software, same apparent configuration) Windows 7 machine works absolutely fine, just like this one did before it threw this fit.

I've added the following lines to smb.conf at the suggestion of various sources:

netbios name = myservername
client ntlmv2 auth = yes
client lanman auth = yes
ntlm auth = yes
lanman auth = yes

...to no effect.

Hunting on the internet for this error finds dozens of users screaming about the problem and dozens of conflicting solutions, none of which work for me.

The server logs show absolutely zero indication that the PC in question has ever even tried to access the samba share. Meanwhile all our Windows XP clients still work fine, as well as the identical Windows 7 machine across the room -- identical model, identical OS, identical apparent settings, on the exact same local network.

Does anyone have any insights?

---------- Post updated at 10:59 AM ---------- Previous update was at 10:37 AM ----------

Resetting Windows Firewall to defaults (then re-enabling file+printer sharing, etc) made no difference.

Deleting and re-installing the network device made no difference.

netsh winsock reset made no difference.

---------- Post updated at 11:19 AM ---------- Previous update was at 10:59 AM ----------

Running a long cable from her PC to the same switch the server is plugged into made no difference.

Could you please post your samba config? If the problem occurred suddenly: did you try rolling back to an earlier restoration point (I don't know the English word...) on the client? Can you access other services within your network? Is there a firewall on the samba server? And what OS is it?

The server is Linux. Its firewall is presently disabled.

Everything else works with perfection, including other things hosted on the server. Just not samba file shares. It's presently using winscp as an ugly workaround. The Win7 machine refuses to acknowledge its existence there. It sees other Windows machines but not the Linux one.

I can't bring the Windows client to an earlier restore point. I don't even know what I'd be trying to undo, anyhow.

###############################################################################
######## START OF GLOBAL SETTINGS #############################################

[global]
workgroup = WORKGROUP
netbios name = MECGENTOO
#client ntlmv2 auth = yes
#client lanman auth = yes
#ntlm auth = yes
#lanman auth = yes

smb ports = 139

invalid users = "Cap User"

# Map Windows users to UNIX users here
username map = /etc/samba/smbusers


# Uncomment this logging level for login debugging
# log level = 3 auth:10 passdb:5

# All connnecting Windows clients must present a valid username/password
security = user

# Accounts with no password can login
null passwords = yes

encrypt passwords = yes

# The UNIX account 'nobody' is used for guest logins
guest account = nobody

# Administrators login as root
admin users = root

# Tell samba to serve WINS.
wins support = yes

# This would tell it to be a WINS client.
# wins server = 192.168.0.41

# Give it control over network browsing
local master = yes
os level = 99
domain master = yes
preferred master = yes


# This should allow addresses 192.168.0.1-192.168.0.127 to use samba,
# while "hosts deny = All" prevents all others.
hosts allow = 192.168.0.0/255.255.255.128 127.

# Deny all hosts except those we know
hosts deny = All

# 10.1.1.0/255.255.255.0
# hosts allow = 192.168.0. 10.1.1. 127.

# Limit samba to the first network card
interfaces = lan

load printers = no
#printing = cups
#printcap name = cups

######## END OF GLOBAL SETTINGS ###############################################
###############################################################################

###############################################################################
######## START OF SHARE SETTINGS ##############################################

[Archive]
comment=Old or unsorted or backup files
path=/opt/mecgentoo-shared/Archive
create mask = 0660
directory mask = 2770
writeable=yes

...and so on. There's lots more different shares.

The 'hosts allow' is completely intentional. Random clients that aren't recognized by our DHCP server will get IP addresses > 128, which will prevent them from talking to our SAMBA server. Only office computers that our DHCP server has static addresses assigned to will be able to get into SAMBA.

The computer in question has .18 on the wired and .19 on the wireless, so is definitely allowed no matter what.

Did I mention that every other client except this computer still works? Even our network scanner still works.

---------- Post updated at 01:33 PM ---------- Previous update was at 12:39 PM ----------

There were no Windows updates installed between the time this Win7 client was able to connect and when it suddenly started refusing to. None whatsoever.

---------- Post updated at 01:59 PM ---------- Previous update was at 01:33 PM ----------

Had a suggestion to restart the Workstation and/or Computer Browser services.

Attempting to stop the Computer Browser service gets "Error 1061: The service cannot accept control messages at this time".

Attempting to stop the Workstation service gets exactly the same thing.

Something in Win7 might be broken. Your conf looks good and is working anyway, so I'd try to repair the system (repair install via the Win CD). Sorry I couldn't help any more.

SOLVED, FOR THE MOMENT!

Taking a close look at the error dumps when windows diagnostics failed, I noticed it was looking at port 445 and ONLY port 445... So I commented out this line, allowing samba to use the ports it thinks appropriate:

# smb ports = 139

...and the boss' computer was miraculously able to connect again.

For the moment, anyway. It's teased me before by working briefly then dying, and there was no reason for it to suddenly start refusing to use port 139 after using it for months. Let's hope this sticks.

That's weird... But as long as it's working

Even though this is a few months old, you might still be interested in a possible solution. I have a similar problem between my Win7 VM and my Kubuntu host. To fix it, I just have to restart smbd before starting Win7. I use the following command:

sudo restart smbd

It happened again. Same problem computer. This time, directing to \\server-ip-address bypassed whatever problem, for now.

[edit] Appears to have been instigated by letting the computer sleep with networked documents open. A bad idea at the best of times, but can leave Windows confused when it awakens. A few reboots later it started behaving again.

If this problem happens again I would compare the settings in

control panel>Network and Internet>Network and Sharing Center> Advanced sharing settings

between the problematic Win 7 client and a working one. Compare every item.

Also I've seen this device screw up on Windows 7 suddenly occur (obviously a Windows bug) with this solution (a cut and paste from the web):

Here is the solution to "error code 0x80070035 network path was not found" on Windows Vista and Windows 7 Computers. Click on the "START" button, select "CONTROL PANEL", and go into "DEVICE MANAGER". Click on "NETWORK ADAPTERS", then click on "VIEW", and select "SHOW HIDDEN DEVICES". In the expanded view you will see a long list of numbered "MICROSOFT 6to4 ADAPTER". My Windows 7 Professional desktop had 200 of them. Right click and select "DELETE" on all but 1 of them. You can only do 1 at a time so it does take a while. When you have only 1 left, restart computer and enjoy being able to see your other network computers, including HOMEGROUP files.