Forum Discussion
W10-1903 UNC path failing 0x80070043
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
DarrenMiller finally got this installed our on DR side yesterday. Did Dell request you rolling restart both controllers on the FS prior to updating, and then again request you restart both controllers after updating firmware? They asked that I do that, then send them the gen diags after doing all of that. The 2nd set of rolling restarts did create some problems.
They are also asking for access to the storage arrays, which makes me a bit hesitant to think this firmware is production ready. That being said I haven't seen any issues with it so far, and 1903 does work properly.
tomatthe They requested rolling reboots before the upgrade and logs, but not rolling reboots after.
I'll will try rolling reboots now the upgrade is done to check it doesn't cause us any issues. We normally have to do rolling reboots once a month anyway as the controllers regularly run out of cache (long standing issue, not related to this).
I was a bit surprised by the extra steps - I've never had to do that before so it does seem they are being extra cautious with this one.
DarrenMiller They eventually said the luns were dropped during the restarts because there was a raid rebalance going at that time. I'm not sure why that would cause it to drop connections, but that's what I was told. I had replaced a drive in one of the sc2080's under the NAS head a few days before doing the restarts. From the end user side I don't believe there is any way to actually see that the system is still balancing data after replacing a disk.
The amount of disk these arrays have dropped is at about 15% in 2.5 years of use which is about 10% worse then any other array I run fwiw.
