Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed

Question

Using Windows 2008 R2. On our server we get this error: "Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again." when trying to map a drive on the command line. However, there are no open Explorer windows to the remote computer, and nothing shows on the remote computer when I do a "net use".

Why does windows think something is connected when "net use" reports that there are no drives or folders open to it??

How can I force Win to stop thinking something is connected without restarting?

It appears that I get the error if I specify a username and password. If I just put in:

 net use n: \\192.168.10.120\test  

it works, but if I put in

 net use n: \\192.168.10.120\test "<password>" /user:"<domain\username>"  

it gives the error. Why would that be?

Answer 1

In our network I have found that restarting the Workstation service on the client computer is able to resolve this problem. This has worked in cases where a reboot of the client would also fix the problem. But restarting the service is much quicker & easier [and may work when a reboot does not].

My impression is that the local Windows PC is caching some old information and this seems to clear it out.

For information on restarting a service, see this question. It boils down to running the following commands on a command line:

C:\> net stop workstation /y C:\> net start workstation 

Note - the /y flag will force the service to stop even if this will interrupt existing connections. But otherwise it will prompt the user and wait. So this may be necessary for scripting.

---

Be aware that on Windows Server 2016 (+ possibly others) these commands may also stop the netlogon service. If so you will have to add: net start netlogon

Answer 2

Even if you remove the shared folder via net use * /del, on the server side there is still a connection up there.

In order to get around this problem which Microsoft created by design you should map the drive in a way to let windows think it's another share on another server. The simplest way to do that is to use DNS aliases or ip addresses. In your case, if your first mapping uses the ip address like \\IP\Share with your current credential, you should use something like \\ServerName\Share password /user:Domain\Username this should create a new share with the new credentials.

Microsoft call this behavior by design .. i call it just stupid design.