Forum Discussion
W10-1903 UNC path failing 0x80070043
- Jun 13, 2019
Hi everyone. We got access to the Dell KB and see the issue in Dell/EMCs 'Unity' CIFS implementation.
From the DELL EMC KB attached to thread (below), the Unity SMB Server implementation is failing on the "SMB2_NETNAME_CONTEXT" and "SMB2_COMPRESSION_CAPABILITIES" we added in 1903. These were changes designed to add some new capabilities to SMB; we make some variant of these at most OS releases. If an SMB/CIFS server doesn't recognize capabilities, it should ignore them, not fail. Otherwise Dell would have to update their SMB implementation every time we released a new SMB capability that didn't also include a protocol dialect revision (like "SMB 3.1.2"), forever and ever.
Error Messages in the Unity c4_safe_ktrace.log:
sade:SMB: 3:[nas_serverx] Unrecognized SMB2 negotiate context type 0003
sade:SMB: 3:[nas_serverx] Unrecognized SMB2 negotiate context type 0003SMB client sends the compression context before the netname context, so the server encounters the compression context first. The Unity server would probably encounter the same problem with the netname context. Instead of failing when their SMB Server version doesn't support more advanced capabilities, it should be ignoring those capabilities. This is what Windows and other 3rd party SMB products do.
kurgan thanks for opening this techcommunity item, I'm sorry I didn't see it until now.
Ned Pyle | Principal Program Manager, MS | @nerdpyle on twitter
tomatthe I installed the new version on our DR FluidFS this morning. It all went smoothly and it now works with SMB3 and Windows 10 1903!
I'm going to give it a few more days testing before installing it on the production servers but it looks ok so far.
DarrenMiller Still trying to get Dell to review the diags I sent them and get me the actual firmware.
FWIW a friend of mine who also runs this system sent me the info below. Hopefully unlikely anyone else will run into this, but sounds like a bad situation.
"
The problem that occurred on our end occurred during the initial diagnostics process. We were working with the individual assigned to help get us prepped for the update, and so we pulled the ISO, and were running the initial tests. Part of that process – they had asked us to update the support password. When we did, the process tossed an error. They didn’t think anything about it. However, that process created a seed that didn’t exist, and the system literally hung during the diagnostic process trying to sync that file between the two nodes. It was difficult to diagnosis and we had to have someone from the team that actually wrote the queuing system for the product determine the problem and write a small utility to stop the cascade of badness. We were actually at a point of essentially re-imaging both nodes because no one could figure out all Thursday and Friday what the hell was going on.
Once that was fixed, the firmware update took 25-30 minutes – tops."