Windows 10 losing access to Samba directories

[curlysir]

Microsoft won't "fix" it because it's not a bug. It's a feature present only in SMBv1 and SMBv1 has been deliberately disabled in recent versions of Windows for reasons of security.

EDIT: Re-reading your post #15 I think we're talking about a different problem. The problem I and kfp were talking about was not being able to access Samba shares. That is, shares on Linux-like machines, i.e. the router, NAS's and Linux PC's. From what you've said it seems like access to those type of shares (i.e. the router) is working OK. But your problem is accessing shared folders residing on other Windows PC's. Is this correct?

Yes, sorry for slightly going off target. I had the Samba share problem on my Windows 10 machine and it was related to SMBv1 not being installed. Installing that fixed the Samba problem for me.

 

[FreshJR]

Again, for security reasons so users don’t connect to rogue servers unknowingly.

https://support.microsoft.com/en-ca...disabled-by-default-in-windows-10-server-2016

I still do not like the approach.

The ideal scenario is

1) You attempt to access a network share directly via IP, hostname, or even the discontinued network browser

2) You get a message that says, it seems like you are trying to access another device.

Would you like to
-) Enter credentials
-) Continue as guest

3) Upon any access error, you get a message that says, it seems like we could not access this device

Would you like to
-) Re-Enter Creditials
-) Continue as guest

A little button in windows explorer that says “Reconnect as Different User” wouldn’t kill anybody either.
—

The automatic use of existing windows credentials (skipping the above intuitive prompt) should only been used if the network in question had domain managed user accounts. The above headaches would not exist since the credentials/permissions would ALWAYS match.

Before the network browser was depreciated, would it kill them to include “connect as” as a right click context menu item to fix literally 99% of the connection errors associated with network sharing.

Instead, to actually access “connect as” functionality you had to dig through a UI in a completely separate area and then stumble upon “map network drive”. Before clicking “map network drive” it didn’t even hint that it would act any different than the network browser. It indeed was the only thing that allowed different credentials.

If this wasn’t convoluted enough, it actually was possible to get a “connect as” prompt via the network browser. The “connect as” prompt appeared if the other networked device did not have a duplicate username already present your computer.

This innocent seeming dialog box was also a MASSIVE doubled edged sword.

If the other networked device ever changed its credentials, windows would forever attempt the incorrect creditials for all eternity. Not once would it say, hmm these creditials haven’t worked the last 1000times, maybe we should try updating them.

Of course if you wanted to update (or re-attempt) the creditials you could of course open run, type in “control userpasswords2”, go to manage saved credentials section, and update the credentials there. This step and also all the error messages along the way were very intuitive. /s

Don’t even get me started on the file permissions/share permissions in windows. Or the mismatching default WORKGORUP names along different windows releases.

Hide&Seek across the entire operating system coupled with Trial&Error is not a valid solution to get working network shares for average windows users.

—

Sure this all becomes simple after you experience all the pitfalls, but I guess I missed the windows help file “network file sharing for dummies” that explained how all of this was supposed to work.

Wouldn’t hurt to put all tools on once place as well either.

 

[kfp]

I still do not like the approach. <snip>
Sure this all becomes simple after you experience all the pitfalls, but I guess I missed the windows help file “network file sharing for dummies” that explained how all of this was supposed to work.

Wouldn’t hurt to put all tools on once place as well either.

Hey @FreshJR, thanks for your detailed post and didn't want to reply immediately further because I don't use guest shares on a day-to-day basis.

I just set up a dummy guest share, and was able to mount it without being prompted for the password, so I guess that implies it didn't try to use my current credentials to mount it (it wouldn't work anyways because local user doesn't exist on the samba server).

Here is the entire process of mounting guest share:

• File Exporer
• Map network drive
• \\server\share
• uncheck "Reconnect at sign-in" (I checked it the next time and it has no effect)
• uncheck "Connect using different credentials"
• Finish

Then it's mounted and folder opens automatically.
This is with Windows 10 Pro (1803), and I verified this was over SMB2.
Are most people that have the guest account problem using a different version of Windows? This link does mention that

1. Windows 10 Enterprise and Windows 10 Education no longer allow a user to connect to a remote share by using guest credentials by default
   
2. Windows Server 2016 Datacenter and Standard edition no longer allow a user to connect to a remote share by using guest credentials by default
   
3. Windows 10 Home and Professional editions are unchanged from their previous default behavior

Or are we even talking about the same thing here? Is the behaviour different when logged into a Windows Guest account and trying to mount a share that requires authentication?

 

[Robaye]

This may not apply here, but just in case. It was useful for my issue.

SBMV2
https://www.snbforums.com/threads/problems-using-smbv2-only.46364/
Remember that "browsing" network shares in Windows Explorer is a function of SMBv1, you can't do that in SMBv2. With only SMBv2 enabled you have to manually type in the complete address of the share into the application, or map the drive.

https://answers.microsoft.com/en-us...-network/37140a9c-f47b-4d19-97e2-2710a7deab27

 

[vrapp]

DeviceName is being discontinued in recent windows updates.
(...)
After Windows 10 (version 1709) I found that "Network Browser" (aka DNS resolution) stopped working unless I enabled SMBv1 or evidently changed a group policy security setting.

This is different. Network Browser (in fact, "Computer Browser" was the name) used to discover all machines in the network. This is what has been disabled in SMBv2, but you still can access any machine if you know its devicename, by typing \\devicename .

 

[FreshJR]

Necrobumping this thread.

In response to my gripes with samba, some users said they could not reproduce these issues.

Well today, I found a new bug YAY!!! (bug with windows not the router). *I have video proof

I went to access a file share, but as always, windows tried logging in with an incorrect user name.

It did prompt me to input a new username after failing, but in the background it ignored my input and STILL kept trying the non-working username it was attempting to use before!

I tried to override the username with Map Network Drives .... and it did not work.
I then deleted the saved credentials, and it STILL tried used the credentials that were deleted. (WHAT THE HELL?!?!)

Deleting the outdated credentials has always been my go-to fix

I confirmed it was using the old credentials by granting more permissions to the credentials windows keeps trying to continually use.

As my new go-to workaround with Samba shares, you cannot rely on "Map Network Drive" or deleting "Saved Credentials" as a fix anymore.

You have to both delete "Saved Credentials" and restart the windows machine that keeps trying the incorrect credentials.

Video Proof.
https://ufile.io/cgdyj

Fell free to tell me if I am doing something wrong, but the shares work correctly in iOS, Android, Mac, and Linux !!

I welcome the demise of the windows as Samba on windows has been driving users mad since the beginning of time, and this is one of my many pet peeves with windows. The code needs a revamp instead of patches.

---

@vrapp this can potentially be related to your access issue, but my error boxes were different from yours.

Apparently you cannot use more than 1 log-in per networked device you are trying to access.