Disconnecting / logging out from Windows network share without restarting Workstation service

Question

I have a file server running (SMB) that I connected to in Explorer (Windows 7 Professional) by visiting \\1.2.3.4 directly. I logged in as one user, without saving credentials, and now wish to log out (actually I want to change to a different user, but being able to log out in general would be useful).

I have searched around for ways to do this and found a bunch of info that suggests using some form of net use \\1.2.3.4 /del:

• How to logout from a Windows shared folder?
• How do I change the user I am logged in with on a Network Share?
• Using Different Credentials to Access Shared Folders in Windows 7 (www.raymond.cc)
• How do I remove login credentials for a network location in Win7? (serverfault.com)
• Logging out of a network share drive without reboot?
• Etc.

However, none of these actually seemed to work for me. I run net use * /del, then use net use to verify that the list is empty, and yet the share mysteriously remains in explorer, unaffected, accessible, and still using the previous login.

Another thing I tried, which also failed, was doing e.g. net use \\1.2.3.4 /user:newusername to switch the credentials. However, even when net use showed an empty connection list, this still produced an error stating that multiple connections to the same resource with different users were not allowed - why there were connections that didn't show up in net use's list is a mystery to me.

I then found this article How to logout from shared folder (microsoft.com), which recommends:

1. net use * /del (or whatever server).
2. Clear credentials from Credential Manager.
3. Restart the Workstation service.

This procedure worked for me. There was nothing of interest in the Credential Manager, as I did not save credentials, however restarting the Workstation service after clearing the connections with net was the key (I did have to close all explorer windows to get the service to restart).

My question is: This is not very convenient at all, especially when I have to explain it to less tech-savvy users. While I could certainly create e.g. a batch script to automate the whole thing, is there an actual, proper, consistent way to do this that doesn't involve restarting services (and possibly doesn't involve the command line, although personally I don't mind)?

Also, a sub-question: It is weird to me that the vast majority of resources I found on this matter didn't suggest restarting Workstation, and the suggested process of using net use alone seemed to work at least for the other people who posted comments on those posts. Is the Workstation restart unique to me and indicative of some other issue on my machine, or was it just left out of all the instructions for some reason? Only the microsoft.com support post had instructions that recommended this step, which is what finally got it working for me.

Logging out of a share seems like it would be a common enough use case to justify some simple way to do it, so I am baffled by how difficult it was for me to figure this out.

---

Other things I've tried with no effect:

• Closing all Explorer windows before and after using net use commands (as suggested in Kody Browns's answer), as well as futzing with the "separate process per folder window" settings hoping it was some sort of per-process credential caching (also inspired by that answer).
• Changing homegroup connection management settings (suggested by holmzi_online's answer at the above microsoft.com post).
• Killing all explorer processes (including the main one) and restarting explorer after net use * /del (suggested by Robert Greer here, although that issue was with mapped drives).

Answer 1

Start -> Control Panel -> User Accounts and Family Safety -> User Accounts -> Manage your credentials.

Expand one of your "Windows Credentials", and then click on "Remove from vault".

Answer 2

I got it working by doing the following:

1. Run net use * /delete
2. Clear the credentials (e.g. mine is 172.26.190.129, and the date of create is today, just it)
3. Disable "local connect" (Control Panel\Networking and Internet\Net Connect\Local Connect)
4. Wait a moment (I don't why but I think it may break some links from my Win7 to Ubuntu and may clear some cache)
5. Enable "local connect" and it worked..

Answer 3

Not an answer but too long for a comment:

This happened to me. For me, the local computer is Windows 10 21H2 and the remote computer is Windows 7.

Special case maybe: remote computer had "advanced sharing settings" - "public folder sharing" - as ON. This means, first time I went to \\COMPUTERNAME it logged in as "guest". No username / password prompt.

I know I was guest, because from the local computer on the remote computer I made a file in c:\users\public\public documents\ (which is accessible as guest) and then checked the owner of that file using properties - security - advanced - owner. (Note, the guest account displays as off in user accounts - manage accounts. I guess it's still active for network login though.)

So if I had first tried to access a protected resource, I might have been forced to provide a username password and then I probably would not have noticed this issue.

Note, I can confirm I also have no cached credentials listed in credential manager. However, other people on the internet do, and removing those fixes it for them (eg: https://serverfault.com/questions/911503/how-to-log-out-from-network-path). I wonder if I don't because I'm logged in as guest. So there's not really a credential. But then again there is enough of one I can't use another. But this would be a different situation than OP who logged in explicitly the first time (unless somehow he still logged in as guest? In which case the access requirements of the first thing you try to access remotely may play a role here.)

And I tried all these and they didn't work and all said "network connection could not be found":

net use \\COMPUTERNAME /delete
net use \\COMPUTERNAME\IPC$ /delete
net use \\COMPUTERNAME\ADMIN$ /delete
net use * /delete

One more tidbit: on the local computer I used Process Explorer to search for a string among all processes and I searched for the remote computer name. It yielded an open file handle in the svchost for the Workstation service. Force-closing that handle via procexp did not help, unfortunately.

But I believe it lends strength to the suspicion that the Workstation service is caching these credentials in an inaccessible way.

So for me, restarting the Workstation (aka LanmanWorkstation) service fixed it. (Note: you can't really do this in powershell, at least v5.1. Because Workstation has dependent services. You'd have to extract those, find out which ones are running, stop them, store that list, restart LanmanWorkstation -force (which I believe causes dependent services to die ungracefully), then restart the dependent services that were running previously. Oh, and do this recursively for all dependents of dependents and so on. However, services.msc does it all for you. For me the only dependent service that services.msc restarted was Computer Browser aka browser)

Answer 4

2) You are not alone in this issue. Most people probably never experience it because they only have one user and/or multiple users but all with the same password. I seem to experience it all the time. I'm assuming it is because I have the same user name on multiple computers but with different passwords.. (I am not in a domain; laptop is Windows 8.1 with Windows and Linux-based servers..)

(from memory) If I open the root share of a computer, such as \raspi, before accessing a locked down share such as \raspi\private I will have that issue. It seems that a connection is made using the public/open share first and then it gets stored.

As for 1), I only need to close the Explorer windows and (sometimes command prompts) that have accessed that share. I have never had to restart the workstation service.

But it may work for me because I always tell Windows to "launch folder windows in a separate process"..

Just a thought..

Answer 5

Following the instructions at Resolving a Windows Error 1219 from Altaro.com worked for me. In particular, downloading Process Explorer, choosing Find/Find Handle or DLL, and searching for the name of my server revealed that opening a Windows Explorer window with quick links to the server immediately re-established a connection to the server such that net use \\server fails with Error 1219. When Process Explorer shows no active handles, net use \\server succeeds.

Answer 6

This might be a long shot, but did you wait long enough after using net use * /d? As far as I know, even after deleting the share, Windows keeps the session open if there are open handles (Explorer window, etc.). And even after closing those handles, there is a time-out period during which it will reconnect the share. The default seems to be 10-15 minutes. You can shorten this in the registry.

See https://blogs.msdn.microsoft.com/oldnewthing/20110223-00/?p=11413

However, it seems that "KeepConn" is no longer used in newer versions of Windows. See "Idle Connection Timer" on this page: http://blogs.msdn.com/b/openspecification/archive/2013/03/19/cifs-and-smb-timeouts-in-windows.aspx

Answer 7

net use * /del
net stop Workstation /Y
cmdkey /delete:<resourcename>
net start Workstation
net start browser

Way 2: use Multiple NetBIOS names for one computer:

reg add "HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters" /v OptionalNames /t REG_MULTI_SZ /d "NetBIOSName01\0 NetBIOSName02\0 NetBIOSName03\0"

Then you can connect the resources of different users using different NetBIOS names.

net use L: \\NetBIOSName01 /user:<username01> <password01> /P:Yes
net use M: \\NetBIOSName02 /user:<username02> <password02> /P:Yes
net use N: \\NetBIOSName03 /user:<username03> <password03> /P:Yes

Edit %windir%\system32\drivers\etc\lmhosts and add

<Server IP>  NetBIOSName01            #PRE
<Server IP>  NetBIOSName02            #PRE
<Server IP>  NetBIOSName03            #PRE
<Server IP>  <OriginalNetBIOSname>            #PRE

in all network workstation

All users will connect to its resources.