Windows Server 2016 shares not accessible

Question

After rebooting Windows Server 2016 Essentials, all shares are in-accessible. When accessing the server locally using eg \\myserv I get a list of all shares, but when trying to enter one "The network path could not be found: 0x80070035".

I tried disabling the Windows Firewall, that didn't help. I checked the ports 139 and 445 using nmap

root@prox1:~# nmap -p 445,139 10.10.20.20
Starting Nmap 6.47 ( http://nmap.org ) at 2017-10-01 13:23 CEST
Nmap scan report for 10.10.20.20
Host is up (0.00034s latency).
PORT    STATE  SERVICE
139/tcp closed netbios-ssn
445/tcp closed microsoft-ds

And they appear to be closed. What can I do. Tried restarting the server another 3 times already, still not working.

Also checked locally using netstat:

C:\Users\Admin>netstat -a -o -n | find "445"
TCP    0.0.0.0:445            0.0.0.0:0              ABHÖREN         4
TCP    [::]:445               [::]:0                 ABHÖREN         4

There the ports appear to be open? Firewall disabled, there is nothing in between the two machines!! Also the only change was rebooting the Windows server (guest) running on a Proxmox Linux host (KVM virtualization). All other ports (HTTP, RDP, ...) are still open.

Prior to this, the server was running for 3 months in exactly this configuration. I feared the reboot already (it almost always causes some problems) but eventually had to and now again my weekend is ruined... :-(

EDIT: Further inspection with TCPView and netstat -a revealed that the DNS process (dns.exe) allocates a couple of thousands of ports (growing) in the range 49000 - 65000.

SOLVED(!?): Because this is just a VM server I thought, it wouldn't hurt to try and add another network interface. And to my suprise everything worked on the second interface. Now since this is also the Active Directory Server I think I can't just switch IP addresses so out of desperation, I just changed the IP adresses of the old adapter to the new and vice versa. Suprising me again, everything now works on the old IP address (with the new adapter), whereas the old adapter (with the temporary IP) is still not working

Here you can see the DNS is set to 127.0.0.1 (same for both adapters), also the default values were kept for NetBIOS on both interfaces!

Can somebody help me figure out how this has happend and how to prevent it?

Have you checked the event log? Your comment about "fearing" the reboot as it almost always causes problems is contradictory to commonly accepted best practices. Had the system been regularly updated and rebooted it almost certainly would not usually cause any issues. Which also leads me to ask, have you installed all the latest updates? — Appleoddity, Oct 01 '17 at 14:55
*Server* service is running. It's always something that doesn't work after reboot, that's why I only do it sporadically to install updates. What specifically should I check in the event log? Going through errors and warnings I didn't find anything sticking out... — schneida, Oct 01 '17 at 17:00
I'm really struggling with the event log, is there any way to filter for relevant stuff. I tried critical and error but it complains about too many datasources and won't display anything. How do I check all the different stuff in the Microsoft subfolder, there are endless amounts of different event logs. The System and Application mostly complain about Passwort Change Notification Service, Service Control Manager and DistributedCOM — schneida, Oct 01 '17 at 17:39
Only the application and system logs are relevant. Filter for warnings and errors. I don't know what else to say, but a problem like this should definitely reveal itself in the event logs in some way. You can't assume what you are seeing isn't related. The way all of us learn what is valid, not valid, related or not - is to study them and eliminate the events when you understand what they mean. — Appleoddity, Oct 02 '17 at 04:41
I see you edited your question. The port shows open on the server and closed from a remote machine. So, something IS blocking the communications. Only you can tell us what that is. — Appleoddity, Oct 02 '17 at 04:43
Thousands of ports is normal!? It keeps adding and adding although there are only ~10 computers in the network. The Server runs virtualized on Proxmox (KVM), I'm checking the ports on the Linux hosting the machine. Either the Linux host has a Firewall or the Windows guest. Since I disabled the Windows Firewall and checked the Linux host that there is no firewall enabled, I don't know what else could be in-between! Since it was caused through a reboot of only the Windows Server, I don't think the Linux host is responsible... — schneida, Oct 02 '17 at 04:51
Yes, it is completely normal. https://technet.microsoft.com/en-us/library/dd197515(v=ws.10).aspx — Appleoddity, Oct 02 '17 at 04:58
Did you check what location your server has configured itself to? Is it domain or public? I've seen a bug with the network location awareness service. Try restarting it and see if it helps. If it does, set it to delayed start. — Appleoddity, Oct 02 '17 at 05:05
They are both domain (and with both I mean the second adapter that I added, see my edited question). — schneida, Oct 02 '17 at 05:25
Enable NetBios over TCP/IP. I saw that in a related post too, but thought nah, no way he disabled NetBios. — Appleoddity, Oct 02 '17 at 12:05

score 2 · Answer 1 · answered Oct 02 '17 at 14:34

2

The interface that works has NetBIOS over TCP/IP enabled.

It actually makes sense that this would solve the issue if you truly don't have a DNS server configured on your network interfaces. The image you show does not show a DNS server configured.

Being this is a domain controller, you should have 127.0.0.1 as the primary DNS server, and any other domain controllers as the secondary, tertiary, etc. All OTHER machines on the network that are not domain controllers should have one or more of your domain controllers configured as their DNS server - preferably via DHCP options.

Without a valid DNS setting this domain controller is going to have all kinds of problems, and NetBIOS is an alternative name resolution service for file sharing.

answered Oct 02 '17 at 14:34

Appleoddity

3,488
2
13
33

Sorry this is not the case. The DNS is set up propperly on both interfaces to 127.0.0.1 / ::1 on IPv6 (since this is the only AD Server - not sure if a secondary is even possible with Windows Server 2016 Essentials). Also the NetBIOS settings were kept exactly the same on both interfaces. I can reproduce the not showing 127.0.0.1 as DNS also on my Windows 10 computer at home! – schneida Oct 02 '17 at 15:05
Yes, it sounds like maybe it doesn't show the loopback address for DNS servers. Although that is strange. I could test that later. However, you can't say you kept the settings the same because it clearly shows in your images that it is not and I can only suspect this is related in someway to DNS resolution. – Appleoddity Oct 02 '17 at 15:06
This advice is backwards. Your AD/DNS servers should have another AD/DNS servers as the primary DNS. The last DNS server should be 127.0.0.1. – longneck Oct 02 '17 at 15:07
@Appleoddity I promise you I have kept all settings the same :-) In german we have saying - I put my hand into the fire to assure you nothing changed, except the things I said I did! – schneida Oct 02 '17 at 15:12
@longneck do you know if Essentials can even handle a secondary AD/DNS server? I would probably need CALs etc then - right? – schneida Oct 02 '17 at 15:13
@Schneida - I understand what you are saying. It doesn't really matter what you say you changed or not changed. The FACT is that on one interface NetBIOS over TCP/IP is ENABLED and on the other interface NetBIOS over TCP/IP is DISABLED. You're asking for whys and hows of this problem occurring - I'm pointing out the obvious difference here. IMHO, it is nearly 100% certain that this is related to your issue in some way. – Appleoddity Oct 02 '17 at 15:15
Oh, if you only have a single AD server, then 127.0.0.1 is the way to go. I have no idea about licensing. – longneck Oct 02 '17 at 15:15
@longneck - I've always set it up with localhost as primary. However, I did check your response and see that there doesn't really appear to be much general consensus on this. Being it has never caused me an issue that I know of, I will stick to my current practice. Interesting piece of information though that I will explore more later - thanks. – Appleoddity Oct 02 '17 at 15:17
@Appleoddity I agree with you that NetBIOS probably has something to do with it, but I think it's a symptom and not the cause. Does NetBIOS explain that the port are closed on the broken interface (still are close non the .80 interface, but working on the .20)? – schneida Oct 02 '17 at 15:19
1

@Schneida - thanks for the additional images in your question. Those default settings should result in NetBIOS being enabled. I'm leaning towards a corrupt network interface installation. Have you tried `netsh int ip reset` and `netsh winsock reset` then reboot? Apart from that I would remove the adapter and re-add it, or double check it's configuration on the VMHost. Something is screwy on that adapter, I think we both can agree. I'd love to know what is wrong - but obviously, the problem appears to be solved. – Appleoddity Oct 02 '17 at 15:24
I'll give it a try tonight! Hopefully my fear of reboots won't cause any troubles this time ;-) – schneida Oct 02 '17 at 15:25
@Schneida - I also notice both MAC addresses are significantly different, which I feel is strange and may be a clue. Typically virtual adapters will have the same first 3 bytes for MAC address. – Appleoddity Oct 02 '17 at 15:26

score 0 · Answer 2 · answered Nov 05 '18 at 01:14

I just had this issue and as Appleoddity pointed out, it is the NetBOIS setting. I had it set to Default, changed it to Enabled and restarted. But the status details still showed it as not enabled. Using the reset commands didn't work either.

I solved it by removing the network adapter and re-adding it.

Windows Server 2016 shares not accessible

2 Answers2