Nas Connnection Help

Question

I have a Nas connected to a private network. I can ping the IP address and by name. The issue is that in file explorer, I can't access the NAS. I can see it in my network but when I go to access, I get an error. I can go to my search bar and run the IP address and get access, but when my computer restarts I no longer can access it by the IP and have to run by name. It makes it extremely annoying to do every day when I go to log in. I usually have a mapped drive to each folder I use most frequently. I am using a Thecus N5500 Nas with a Netgear managed switch and an Asus router. I should also mention that other computers on the network are having the same issue. My computer was working fine, until recently. The other computers have had this issue for a couple of months. I have enabled NetBios and SMB 1 on all the computers and some other suggestions I have found online.

Update:
I should mention that I am not an IT professional or have had any real training. The company I work for has a total of four people. I have a degree in computer science, and when network or any computer issues arise, I am the one that deals with them. I search and try to shift through all the nonsense until I find something that seems genuine. It's a lot of trial and error. I know that isn't the best way of doing things but, I work with what I have. Also, the Thecus NAS is old the user interface is poor. I updated the firmware and, most of the radio buttons still don't show what they mean.

Answer 1

Hello Josh,

In that last trace, the NAS selected SMBv1. I don't know if it will continue to do that but, if it does, then that would resolve the particular problem.

In case that the NAS does negotiate SMBv2/3 again, there is one more thing that you can try: for each each of mapped drive letters to the Thecus N5500 stored in the registry under HKCU\Network, add a REG_DWORD value with name ProviderFlags and value 1.

I have updated http://gary-nebbett.blogspot.com/2021/06/mapped-network-drive-reconnection.html to describe what this setting does and how it works. It is not a complete solution but it can often help.

I found quite a few references to this workaround when researching this problem, but always without an explanation of what it did or why it helped. Having now discovered answers to those questions, I am happy to recommend it.

Gary

Answer 2

Hi,

First check SMBclient log on your windows 10 to see if there are something related for us to troubleshooting.

If other machines have the same issue, it seems the problem is more related with NAS side. Make sure you have patched your windows 10 with fully windows updates.

Best Regards,
Candy

--------------------------------------------------------------

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 3

Hello @josh anderson ,

I am a bit confused by your initial problem description. It sounds as though, at first, accessing the NAS via a name like \N5500 does not work but a name like \192.168.1.200 does work; it also sounds as though, after a restart, a name like \192.168.1.200 does not work but now \N5500 does work.

Are drive letters mapped to folders on the NAS?

It is possible to enable more tracing to get a better understanding of what is happening, but it sometimes difficult to judge what level of tracing is appropriate for the problem. Furthermore, interpretation of the (binary) trace data is often not easy and you might need to share trace data in the forum so that it can be viewed by experienced members.

The most specific tracing that might be helpful can be performed with the commands logman start why -ets -p Microsoft-Windows-SMBClient -bs 64 -nb 999 -o why.etl and logman stop why -ets (to start and stop a trace).

A broader trace can be performed with the commands netsh trace start scenario=lan capture=yes report=disabled tracefile=why.etl and netsh trace stop.

More specialized traces might be needed later, depending on what the first traces indicate.

The process of creating a trace is: start the trace, reproduce the problem and then stop the trace.

Gary

Answer 4

Hello @josh anderson ,

I have a theory. Let me explain it first and then discuss how to proceed. The authoritative source of information about SMB is the Microsoft specification "[MS-SMB2]: Server Message Block (SMB) Protocol Versions 2 and 3".

Section "3.2.4.2.2 Negotiating the Protocol" of this document says:

When a new connection is established, the client MUST negotiate capabilities with the server. The
client MAY<111> use either of two possible methods for negotiation.

The first is a multi-protocol negotiation that involves sending an SMB message to negotiate the use of
SMB2. If the server does not implement the SMB 2 Protocol, this method allows the negotiation to fall
back to older SMB dialects, as specified in [MS-SMB].

The second method is to send an SMB2-Only negotiate message. This method will result in successful
negotiation only for servers that implement the SMB 2 Protocol.

The footnote <111> says:

The Windows-based client will initiate a multi-protocol negotiation unless it
has previously negotiated with this server and the negotiated server's DialectRevision is equal to
0x0202, 0x0210, 0x0300, 0x0302, or 0x0311. In the latter case, it will initiate an SMB2-Only
negotiate.

What seems to be happening is that your PC is attempting to reconnect to your Thecus N5500 using an SMB2-Only negotiate message. The Thecus N5500 seems to be just silently ignoring this negotiate message. Perhaps it expects the first SMB message on a new connection to always be a multi-protocol negotiation.

I know that we have covered the following ground before (flip-flopping between name and IP address) but can you try the following: start a trace using the netsh trace start scenario=lan capture=yes report=disabled tracefile=why.etl command (it will be a bit more helpful than the other command in this context), then (perhaps via Windows File Explorer) disconnect all drive letters to the Thecus N5500 (so that there is no reason for Windows to remember it) and reconnect a drive letter to the Thecus N5500 using the same path that it original had (e.g. if the existing (and non-working) connection used the name "N5500" then try to use that again to reconnect after the disconnect). Finally, stop the trace with the command netsh trace stop.

Hopefully, the disconnect and reconnect will force the use of a multi-protocol negotiation and the connection will then work.

If we can verify this behaviour then we can think about how to practically resolve your problem.

Gary

Answer 5

Hello Josh,

Many thanks for that trace data - it is not exactly what I expected, but at least it is not in conflict with my theory :-)

Here is an extract:

More or less every second, the client tries to "negotiate" a SMB2 (or higher) SMB connection, but gets no answer. Then follows a "quiet" period (no traffic), when I guess that you followed my advice to disconnect all shares to N5500 (at 17:34:53 UTC (10:34:53 by your local time)). Suddenly the client starts the negotiation with an SMB v1 offer, which (very surprisingly) is accepted.

My theory is that a "direct" offer of SMB v2/3 will not be accepted without first offering SMBv1 - the trace seems to partially confirm this.

The odd thing is that in this trace, the renewed protocol negotiation (at 17:35:17) completes with a negotiated version of SMB v1 (NT LM 0.12) - my theory would say that the initial offering of SMB v2/3 was only made because this version had been negotiated in the past (and it is odd that this level was not negotiated again in this trace).

It is now almost 22:00 in my time zone (Switzerland) and I have more to say, but it will take a new day to gather my thoughts.

Briefly said, it it my belief that support for old implementations of SMB (with specific "issues" in conflict with performant implementations of the newest version of the protocol) have been abandoned by Microsoft. My Internet searches suggest that a "Thecus N5500" might be approaching 12 years old.

I fear that the best that we will be able to do is to identify workarounds that work "most of the time".

Gary