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
GOOD NEWS... I'm just on phone with my local Dell Engineer, the RM640 Patch is out since friday 19.
Don't hesitate to ask them
Have fun
Sybuxbeat me to it, hope to get this installed this week. If anyone has has loaded it already and had any comments it would be appreciated. Presumably it fixes the 1903 issue, but I haven't been able to get a copy of the release notes yet.
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.
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 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.
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."
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.
ftp://customer:Y3V2s-uH@ftp.compellent.com/SOFTWARE/FluidFS/680-115-002_FluidFS_v6_Release_Notes.pdf
Pretty minimal changes,
Fixed Issues in FluidFS Version 6.0.400016
The following issues were fixed in FluidFS 6.0.400016:
Area Description
NAS Volumes, Shares,
and Exports
After installing Windows 10 update 1903, SMB shares are not accessible using the UNC path.
System Functionality The system incorrectly reports that duplicate IP addresses are in use for nodes on the cluster.
The system incorrectly reports battery failures during the battery calibration process
