Network Shares not seen with MS account

Mystere said:

Dude, I had asked you several times if you had done just this, and you told me you had....

Regardless, the registry hack is probably dropping you back to SMB1 which will be much slower than SMB2 and less secure.. For you local firewalled network, the security may not be an issue (although, there have been viruses known to take advantage of SMB1)...

So, are you saying that your computer has SMB2 under Parameters? I would hazard an educated guess that it doesn't. I have four win 10 10240 comps here and only one had the SMB2 entry, and, guess what, that was the only one that failed with the path not found error. I have tried entries of SMB1, SMB2, SMB3, SMB4 and only SMB2 gives the failure that can be seen on all my comps, including a win 8.1 one. The effect is totally repeatable.

The 'hack', as you call it, does nothing but make file sharing work as intended and can hardly be controversial considering only one of my comps has it and I suspect the SMB2 entry comes from Vista days.

I also don't think this problem has anything to do with how your shares are set up or, indeed, whether you have any shares set up at all as this gives an Empty Folder' message on a working system. My supposition is that it is a protocol issue and the Lanman Server doesn't acknowledge the request for share info hence the Lanman Client's response that there is no path to the server.

Something was changed in win 10 sometime after 10130 as I reverted one of my comps to 10130 and the path not found error wasn't there.

As for reverting to SMB1, I don't agree that is happening as I quote below:-

Q: How can I quickly check what version of SMB is being used between my machine and the server?
A: There are now several different versions (or dialects) of the SMB protocol that were introduced with different versions of Windows:

• SMB 1 - Windows 2000
• SMB 2 - Windows Server 2008 and WIndows Vista SP1
• SMB 2.1 - Windows Server 2008 R2 and Windows 7
• SMB 3.0 - Windows Server 2012 and Windows 8

The version of SMB used between a client and the server will be the highest dialect supported by both the client and server.
This means if a Windows 8 machine is talking to a Windows 8 or Windows Server 2012 machine, it will use SMB 3.0. If a Windows 8 machine is talking to Windows Server 2008 R2, then the highest common level is SMB 2.1.

Ztruker said:

What is the key you are working with?

HKLM\CurrentControlSet\Services\LanmanServer\Parameters. Under Parameters I had an entry, 'SMB2', that I deleted.

Good article here https://support.microsoft.com/en-us/kb/2696547

This shows that a 0 value disables the SMB entry. My SMB2 had a 0 thus disabling it. I changed the value to 1 and it all worked fine.

I suggest that these entries are now irrelevant in a modern system which is why they don't appear in new win 10 installs. Checked my win 8.1 system and it has no SMB entry, either.

I'm just going to go with no SMB entries! But I have learnt a few things in the process.

Cheers,

Lindsay.

linw said:

The 'hack', as you call it, does nothing but make file sharing work as intended and can hardly be controversial considering only one of my comps has it and I suspect the SMB2 entry comes from Vista days.

It doesn't "do nothing but make file sharing work". It is a key that is responsible for controlling which version of networking is used. If it was set to 0, then that disabled SMB2. This was often necessary for various NAS's because they used older versions of SMB/CIFS that required older protocols to work. Modern NAS's don't have that problem.

What i'm saying, is you have to know what you're doing when you do stuff like this. And know what the effects are besides the obvious one you're trying to solve. In this case, it appears that if the key is not present, it enables SMB2 by default. The same effect would be achieved by setting the value to rather than deleting the key.

That doesn't explain Jimbo's problems, as he has claimed numerous times he's done clean installs...

Hi there

I think the SMB stuff came about because I was using SAMBA as well in the mix --- flushing everything out fixed the whole kybosh.

I don't have ANY problems either now with an XP Machine (VM) also being able to share with W10 (including the Storage spaces on W10).

Latest version of SAMBA on Linux server seems to be OK too. I'm sure that using various OS'es including W2003 server, W012 server, W8, W8.1 and various Linux distros probably hosed the whole thing up.

Anyway Build 10240 all working and accessible by the rest of the network.

As for "You have to know what you are doing" doesn't really apply if you are simply TESTING or LEARNING stuff --another reason for ALWAYS HAVING BACKUPS so you can restore if something goes wrong or you don't like the result of your change(s).

Sometimes in order to Learn you have to find out by "seeing what this does" -- sometimes it will work sometimes it will break something. I believe it's called "Experimenting". You can't always predict in advance what something will do whether it's a PHYSICS / CHEMISTRY / ENGINEERING or even a COMPUTING experiment.

Cheers
jimbo

I agree with your latter sentiments, jimbo. Anyway, I am no novice as I have been doing this stuff for 40 years!

Why would I need to worry trying this out when I have four computers with no SMB entry as a guide, an exported reg key, and full and regular imaging to fall back on? It wasn't working and no one I could find knew what was wrong. The worst that could have happened was my networking could foul up. Oh, I forgot, it already was fouled up.

Anyway, trying to find the problem had me doing lots of far more risky things!

Please don't anyone tell me about the registry bogey man. I just don't need the patronising.

Sincere apologies for the omission. Very careless of me.

Yes, the SMB omission is the norm from my small sample.

Cheers,

Lindsay.