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