113

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?

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
raphael75
  • 2,982
  • 4
  • 29
  • 44
  • 1
    I didn't find the full answer, but I discovered that I could get 2 different answers to "net use" depending on if I ran it as a normal user or as an administrator. I found this site: http://woshub.com/how-to-access-mapped-network-drives-from-the-elevated-apps/ that had some interesting information, but I still don't know the exact reason. SunChero's answer below is the closest. :) – raphael75 Mar 15 '16 at 19:32
  • 1
    @raphael75, i bet when you successfully executed **net use n: \\192.168.10.120\test**, you would see a session listed in the file share server using **net session /list** belonging to another user instead of the user name you're trying to connect with in the second command line. – machinarium Jul 28 '16 at 01:55
  • 2
    The Windows User Account Control mechanism seems to be flawed when it comes to network drive mappings. So as pointed out by @raphael75, executing `net use * /d` from both the normal and elevated modes/tokens can help ensure all network connections are dropped. That worked for me on Windows 7 at least. – Martin Connell Aug 26 '18 at 12:23

12 Answers12

193

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

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
  • 10
    This worked for me. Was baffled why my samba share which was previously working suddenly wasn't. Thanks! – Christopher Townsend Mar 02 '17 at 20:51
  • 2
    When trying to map a drive connected to a router, I got the error that OP posted. You're answer fixed my problem! – Andreas Evjenth May 16 '17 at 12:44
  • In my case, rebooting the client did not work, however, this approach worked. Thanks! – precise Sep 05 '18 at 06:54
  • @ErdemKAYA thanks for that note, I've updated the answer to mention it. – StayOnTarget Sep 05 '18 at 11:15
  • 4
    I think this should be the accepted answer. It resolves the issue, while the currently accepted answer only provides a workaround. – Gary Stanton Feb 13 '19 at 19:54
  • Strongly recommend avoiding this as the solution. If run on the same machine as an Exchange server, Exchange will go down with it. – Alex Jun 10 '19 at 13:32
  • PLEASE NOTE that on Win2016 (and possibly other systems) those commands will also stop the netlogon service, so add to that: `net start netlogon` – Derreck Dean Jan 22 '20 at 15:25
  • 2
    @DerreckDean thanks - I can't verify that myself but I've added it as a note in the answer. – StayOnTarget Jan 22 '20 at 15:45
  • I am using Samba on Debian as a Server and had the same issue. This fixed it, thank you! I tried all the other answers before and unfortunately they didn't work. – Lazarus535 Mar 22 '20 at 01:01
74

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.

Paul
  • 4,160
  • 3
  • 30
  • 56
SunChero
  • 872
  • 7
  • 3
  • 3
    could you provide more details like a blog or article of the 'by design' you aforementioned? – machinarium Jul 25 '16 at 08:18
  • 7
    Here is Microsoft Knowledge Base article describing it at "by design": https://support.microsoft.com/en-us/kb/938120 – Marko Živanović Sep 21 '16 at 15:00
  • 1
    Agreed, stupid design. I tried everything possible, including workstation service restart. Finally, after 2 years of not wanting to reboot my workstation when this popped up (always in the middle of a project), I bit the bullet: I cleared all net use items then rebooted, the problem went away. – JayRO-GreyBeard Dec 17 '16 at 16:45
  • I cannot speak for IP addresses, but it seems to treat \\machine-name\share and \\machine-name.domain.com\share the same; I got the error message above trying this for myself, on Windows 2016. – Derreck Dean Jan 22 '20 at 16:12
  • 3
    You can also edit `c:\windows\system32\drivers\etc\hosts` and add an extra entry for each different user credentials, resolving to the same IP address. – silicontrip Feb 04 '21 at 02:20
  • This works, so thanks for that. But why does it work to reboot the client host and then re-issue the 'net use' command? Wouldn't the connection still be on the server? – user1062589 Sep 24 '21 at 12:50
  • The message kept appearing even if I wanted to net use two shares by the same user account. Alias helped. Thank you. – Tomas Tintera May 30 '22 at 05:57
34

Follow these steps:

  • Select the Start button, then type cmd.
  • Right-click the Command Prompt option, then choose Run as administrator.
  • Type net use, then press Enter.
  • Look for any drives listed that may be questionable. In many cases where this problem occurs, the drive may not be assigned a letter. You’ll want to remove that drive.
  • From the Command Prompt, type net use /delete \\servername\foldername where the servername\foldername is the drive that you wish to delete.
meJustAndrew
  • 6,011
  • 8
  • 50
  • 76
Mohsin Javed Cheema
  • 698
  • 1
  • 9
  • 14
12

Here is a Powershell alternative to another answer which uses the net stop|start command.

Get-Service workstation | Restart-Service -Force
StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
Frank Fu
  • 3,483
  • 2
  • 28
  • 38
7

net use \\<host> /delete fastest and targeted (not affecting other connections), but many times it does not work for one of many reasons.

net stop workstation as @DaveInCaz offered should help in some cases.

If all fails, restart LanmanWorkstation service, you can use this script:

@echo.
@echo Restarting
net stop LanmanWorkstation /y
@PING.EXE -n 2 0.0.0.0 >nul
net start LanmanWorkstation

Notes:

  • 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.

papo
  • 1,606
  • 19
  • 18
7

It seems it is enough to restart the windows explorer service:

  1. Open task manager
  2. Find the Windows Explorer proces
  3. Select it. After selection, the "Restart" button will appear in the bottom right corner.
  4. Click the "restart" button. Windows explorer will be reloaded.

It helped in my case.

Lubo
  • 157
  • 1
  • 3
5

It may be that the Windows Credential Manager is holding onto credentials for the network share.

Credential Manager - Windows Credentials

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.

mwfearnley
  • 3,303
  • 2
  • 34
  • 35
2

If you, like me, opened this page because you browsed the error, and this was among the first results

Make sure you don't have the shared folder open in Windows

  1. I was trying to run a batch script to map \\192.168.10.15\Shared to a drive letter
  2. Got the error
  3. I run net use /delete \\192.168.10.15\Shared
  4. Tried to run the batch again, same error
  5. Googled the error, found this page, helped nothing
  6. I noticed I had previously opened \\192.168.10.15\Shared directly from "Run" and it was opened in a window
  7. Closed the window
  8. Tried again
  9. It worked
The One
  • 4,560
  • 5
  • 36
  • 52
0

I had given an answer in Super User site for the thread "Open a network drive with different user" (https://superuser.com/questions/577113/open-a-network-drive-with-different-user/1524707#1524707)

I want to use a router's USB drive as a network storage for different users, as this thread I met the error message

"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."

Beside the method using "NET USE" command, I found another way from the webpage

http://backupchain.com/i/how-to-fix-error-1219-multiple-connections-to-a-server-or-shared-resource-by-the-same-user

It is better to solve the Windows connection limitation by editing the hosts file which is under the directory "C:\Windows\System32\Drivers\etc".

For example, my router IP address is 192.168.1.1 and its USB drive has three share folders as \user1, \user2 and \user3 which separated for three users, then we can add the following three lines in hosts file,

192.168.1.1 server1

192.168.1.1 server2

192.168.1.1 server3

in this example we map the server1 to user #1, server2 to user #2 and server3 to user #3.

After reboot the PC, we can connect the folder \user1 for user #1, \user2 for user #2 and \user3 for user #3 simultaneously in Windows File Explorer, that is

if we type the router name as \\server1 in folder indication field of Explorer, it will show all shared folders of router's USB drive in Explorer right pane and sever1 under "Network" item in left pane of Explorer, then the user #1 may access the share folder \user1.

At this time if we type \\server2 or \\server3 in the directory indication field of Explorer, then we may connect the router's USB drive as server2 or server3 and access the share folder \user2 or \user3 for user #2 or user #3 and keep the "server1" connection simultaneously.

Using this method we may also use the "NET USE" command to do these actions.

phchen2
  • 377
  • 4
  • 6
0

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.

0

This worked for me:

  • Install and run Microsoft Sysinternals tcpview
  • In the menu bar, enter the server ip address in the search bar
  • Process name system appears. Right mouse click on that line and choose Close connection
D.Vanhaute
  • 348
  • 1
  • 8
-1

Solution for Windows 11 (and possibly Windows 10) with a networked drive that includes both private and public folders.

If the user has previously connected to the public folder using anonymous access (without saved credentials), and the public folder is pinned under the "Quick Access" in File Explorer, Windows will automatically assume that the user wants to access the drive folders with anonymous access when File Explorer is opened. This will prevent the user from attempting to use credentials to access private folders that require a username and password.

Remove the public folder from the "Quick Access" section nested inside of the "Home" branch (located in the Navigation Pane), either manually unpinning the folder, or by pressing the button [Clear] under: Folder Options > Privacy > "Clear File Explorer history" - Warning: This will clear all files under the Recent Accessed Files lists. A restart should not be required.

This will prevent File Explorer from automatically assigning anonymous access to the networked drive, and allow the user access to the private folders with credentials.

arobson13
  • 59
  • 5