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 allowe
It seems it is enough to restart the windows explorer service:
It helped in my case.
In Windows 10, I solved this problem with the Windows Credential Manager. I found multiple credentials for the NAS unit that I was having trouble with. After deleting both credentials, I was able to access the NAS mapped network drives without a problem.
Follow these steps:
Start
button, then type cmd
.Command Prompt
option, then choose Run as administrator
.net use
, then press Enter
.net use /delete \\servername\foldername
where the servername\foldername is the drive that you wish to delete.net use \\<host> /delete
should work, but many times it does not.
net stop workstation
as @DaveInCaz offered works in such cases.
I have some why and hows I couldn't fit into a comment.
It's not enough to restart the Workstation service (e.g. from services.msc console)
The service probably needs to be disabled for some short period of time. If you do this restart from a script, might be better to add a 1 second delay.
In cases when net use \\<host> /delete
does not work because another program is still using that share, you can identify such program and remove the blocking handle without closing it. Use Sysinternals Process Explorer, press Ctrl+F for search and enter the name of host machine owning such share. Click on each result, program window behind search dialog jumps to found program's handle. Right click that handle and select Close Handle. (or just close such program if you can) This works only in regular cases where there really is a program blocking the share disconnect. Not in those weird cases when it's blocked for no reason.
elevated account has it's own environment. This brings some unexpected behavior.
If you do net use
command in an elevated cmd/PS console, it will not affect which user will Windows Explorer use to access the share.
And also other way around, if you run a program from the share and the program will ask and get elevated access, that program will loose connection to that share and any files it might need to run. You need to run net use
from elevated cmd/PS to create an elevated share connection to that share.
Removing Recent folders from Quick Access in Windows Explorer (top of left panel) might help in certain cases.
If the Host you are connecting to offers different access levels based on user, and/or has a Guest user (anonymous) share access, this is a situation you might often run into.
When you access a share using your username, folder inside such share might get assigned to Quick Access panel as a Recent item. When you open Windows Explorer after restart, Recent items inside Quick Access will be checked and a connection will be made to the Host machine and will stay open in form of a MUP. If your share accepts both authorized and anonymous connections, just opening Windows Explorer will create anonymous connection and when you click on a share which needs authorization, you will not get credential dialog but an error.
It may be that the Windows Credential Manager is holding onto credentials for the network share.
Load up Credential Manager (the easiest way is perhaps just to Search for that in the Start Menu), see if there are any Windows Credentials for your network share, and try deleting/updating them.
Here is a Powershell alternative to @UuDdLrLrSs answer.
Get-Service workstation | Restart-Service -Force