[SOLVED] Mapped Network Drives - Multiple Connections errors

[DanF]

One of my clients has a small office with a simple NAS setup. Two main folders on a Synology NAS and 4 computers. There's 4 users on the NAS having R/W access to these 2 folders, which are then mapped on the PCs.

PCs are not shared, so they authenticate to the NAS using the local users on Synology. There is no domain or AD in place.

The problem started recently. Everything was fine since approximately 5 years. They, more often than note, get the following error upon starting their computers in the morning and accessing the drives:

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

What I've tried so far:
- Remove any related saved credentials from Windows Credentials Manager
- Remap the drives using DNS name
- IPv6 turned off (just in case)
- Restart a few times, still worked.

The following day 2 computers had the same issue only to one of the mapped drives.

What I've tried following this (still unsure of the results):
- Remap one of the drives by IP, while the other was kept via DNS

Additional notes:
- I've given them a batch file to delete the drives and re-create them. This works without the need to restart.
- Stopping and starting the workstation service also works.

These are of course temporary workarounds and won't solve the issue. I wonder if anyone has encountered a similar problem. I have a feeling that this started since we've upgraded Windows to build 2004.

 

[Computer Bloke]

"Multiple Connections to the server or shared resource not allowed"

Is that the whole error message, or is it actually "Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed"? (Error 1219, to its friends.)

 

[DanF]

Is that the whole error message, or is it actually "Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed"? (Error 1219, to its friends.)

Correct, thanks. Modified the OP.

 

[Computer Bloke]

I've encountered this a few times, usually where there were old login scripts that set up drive mapping using explicit credentials.

Since you've already found that removing and recreating the mapping makes the problem go away, the quick fix is to add your script to do that to the Startup folder ("C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp") on the affected machines and call it a day.

 

[glennd]

I've encountered this a few times, usually where there were old login scripts that set up drive mapping using explicit credentials.

Since you've already found that removing and recreating the mapping makes the problem go away, the quick fix is to add your script to do that to the Startup folder ("C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp") on the affected machines and call it a day.

Does this mean, for example, that the PC is accessing two shares on the Synology using two different credentials?

 

[Moltuae]

I've encountered this a few times, usually where there were old login scripts that set up drive mapping using explicit credentials.

Since you've already found that removing and recreating the mapping makes the problem go away, the quick fix is to add your script to do that to the Startup folder ("C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp") on the affected machines and call it a day.

This^

And I would also add that running ...

net use

... from a command prompt will show you which connections are still open and causing the problem.

If necessary, you can also add a line to your script to remove any such existing connection.

Eg:

net use //nas/share /delete

net use //10.10.10.101/share /delete

net use n: /delete

Or

net use * /delete /yes

... to remove all existing network connections before your script remaps them.

 

[Markverhyden]

I've encountered this a few times, usually where there were old login scripts that set up drive mapping using explicit credentials.

Since you've already found that removing and recreating the mapping makes the problem go away, the quick fix is to add your script to do that to the Startup folder ("C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp") on the affected machines and call it a day.

Nickel solution to the dime problem. Use this on all non-domain environments.

 

[HCHTech]

We are seeing this exact problem for a client we have in the same situation. I'm thinking an update (either to DSM or Windows) must have changed something, or perhaps the Credential store is wonky. We haven't scripted the solution yet because we are stubborn - trying to figure out what changed and where the actual problem lies. The inconvenience-cost for the client is high, though so I don't think we'll hold out for long.

 

[DanF]

We are seeing this exact problem for a client we have in the same situation. I'm thinking an update (either to DSM or Windows) must have changed something, or perhaps the Credential store is wonky. We haven't scripted the solution yet because we are stubborn - trying to figure out what changed and where the actual problem lies. The inconvenience-cost for the client is high, though so I don't think we'll hold out for long.

My client only has 4 systems, but they call me every other morning with the same issue, so it's an inconvenience for both of us. I gave one person a script that removes the mapping and re-does it, so at least they can do something if we're not available for some reason or another.

Lately we did both Windows and DSM updates. If I don't find a real fix, then the start-up script will be my workaround. Is your client on a domain or workgroup?

 

[HCHTech]

Same - my client is on a workgroup as well.

 

[Sky-Knight]

if exist t:\nul ( net use t: /delete )
net use t: \\server\share /persistent:no /user:login password

Fix your login scripts to check for the existence of a map, and remove it before establishing one that is set to not exist on reboot.

 

[Porthos]

Sorta off-topic, Do any of these clients have Malwarebytes premium?

 

[YeOldeStonecat]

I handle with GPO for domains and rarely see this, but on older systems where the old bat login files are still used, I'd sometimes see this. No rhyme or reason. Some workstations the network would exhibit it...other times they won't. And most other computers on that same network wouldn't have the symptoms.

But because of it I started preferring to have the /d command in the login script.
Such as:
net use o: /d >nul
net use o: \\fox2\da

 

[Moltuae]

if exist t:\nul ( net use t: /delete )

I usually just use delete unconditionally (since I run the scripts hidden anyway) but I like that. It's a more elegant solution.

 

[DanF]

Sorta off-topic, Do any of these clients have Malwarebytes premium?

No, not mine at least.

 

[Sky-Knight]

I usually just use delete unconditionally (since I run the scripts hidden anyway) but I like that. It's a more elegant solution.

Yeah I had to do this because I had issues with scripts sometimes crapping out when the net use threw an error. Which it will do if the map doesn't exist. It's not an all the time thing... and it's been decades.

It's funny though how all this old junk is coming back around as I remove domains from networks, I don't have GPOs anymore and clients aren't springing for 365 Premium so I don't have inTune either. So we're back to ye old .cmd scripts in the user's startup folder.

Funny how we come full circle... I'd update to powershell scripts but mucking with those execution permissions? BAH, I'll use the ancient methods that magically just work.

 

[HCHTech]

Sorta off-topic, Do any of these clients have Malwarebytes premium?

Nope, my client doesn't have MBAM or MBEP. There are about 8 computers there, and we've had mapping problems on 3 or 4 of them. At least one is a laptop that they use from home over a VPN as well as when in the office connected directly to their network. We typically make the user credentials for the NAS match the credentials for the computer, but the laptop is different for some reason. I think we'll change that just to line up with SOP, then start putting scripts in place. It's worked solidly for 4 years now without them, but that's life!

 

[DanF]

Nope, my client doesn't have MBAM or MBEP. There are about 8 computers there, and we've had mapping problems on 3 or 4 of them. At least one is a laptop that they use from home over a VPN as well as when in the office connected directly to their network. We typically make the user credentials for the NAS match the credentials for the computer, but the laptop is different for some reason. I think we'll change that just to line up with SOP, then start putting scripts in place. It's worked solidly for 4 years now without them, but that's life!

That's one thing I haven't tried actually, to use the same username/pass on the NAS as on the client PC. But I have the impression you have them set up like this and you still have issues, right?

 

[Sky-Knight]

If you do not provide credentials in a net use, Windows will attempt to use whatever the user logged into Windows with first. If that works for the test connection, but doesn't for the resource you wind up with this error.

So you should clear any credentials saved in the credential manager for that resource. You should then use net use to list all connections to that device, including the IPC$ connection and delete those.

Then you can use the above script to re-establish with a working login, and it should go away forever. Syncing up the username / password is another way to help smooth this over but it requires a reboot or logout / login cycle to fix it. And, in my experience it still causes issues from time to time.

The only way I know to keep this junk from coming back is to use the script above. This issue isn't new... it's been around since shares existed, and the same best practices have applied for decades. We'll never know what makes it go nuts though... because they do seem to show up in waves for some odd reason.

 

[DanF]

Thanks to all for the help, tips, and explanations.

For those coming across this post in the future: today I've added the script to startup on the machines and they seem to work well. I've used the one specifically shared by Sky-Night (post #11).