Fix : Windows 10 accessing network drives : Password incorrect


Recommended Posts

I ran into an issue that was driving me nuts after installing Windows 10 on 2 computers. I could not access any of my network drives from either of those machines. It kept telling me my password was incorrect, but it wasn't. But I would go to a Windows 8 or Windows 7 machine, enter the username and password and it would connect first try.

Normally when you connect to a network drive it prompts you for your username and your password.

On windows 10 in the username box instead of entering just the username enter the computer name plus the username.

Example.

computername\owner  (Do not put \\computername ... that will not work so leave the \\ off)

Now enter the password and you should be able to access the network share just fine.

Hope this helps anyone else that was pulling their hair put.

Edited by warwagon

I have a different issues with windows 10 and networking.

 

I have windows 10 on one PC so far, and everything is fine as far as internet speed, but network transfers i'm getting about 100kb/s or less.

PC has a intel nic in it, so far wasn't able to figure out what the hell is going on.

This has always been this way, like on a domain for instance. DOMAINNAME\USERNAME for authentication and \\COMPUTERNAME\SHARE for UNC.

 

But on previous version of Windows, shared folder access just on the same workgroup specifying the computer name as the username was never required.

But on previous version of Windows, shared folder access just on the same workgroup specifying the computer name as the username was never required.

 

if anything if they're dropping relative workgroup based-assumptions for attempting to authenticate then that's a massive bonus. Or Windows HomeGroup support is broken. I'm happy either way.

with spending so much time in RDP/terminals i auto add the workgroup\domain in that format as it is, my Asus NAS requires authentication from its own ACL. Its the master browser for the workgroup "workgroup" which ironically matches my windows "workgroup" name. (diff un & pwd though)

 

W7 exhibits the same scenario though when working in a domain on a client/shares (*.int\username is entered, not \\*.int\username) especially as it is not your primary domain your authenticating against (e.g. 2 way transitive trusts between forests/domains.) in an admin capacity also uses this format without \\

 

I didnt yesterday on W10 and noticed the same issue :) if you're not used to the above situation, it could be very confusing.

  • 3 weeks later...

"same workgroup specifying the computer name as the username was never required."

 

Workgroups have NOTHING to do with authentication.. nothing..  They are place holder for where your computer goes in that stupid browse list, nothing more..

 

And you sure and the hell do not have to use workgroup name in authentication nor does it matter what domain\username you put when authenticating to a machine that is not a member of a domain.

 

post-14624-0-84051300-1437426476.png

 

Are you saying this is from win10 machine to a windows 7 machine - again nonsense and does not matter what domain you put when authing to a machines local users

 

post-14624-0-54007600-1437426891.png

 

Nor do you even have to put in a domain portion

 

post-14624-0-42465200-1437427097.png

 

edit:  Here is going to \\i5-w7 in explorer to get dialog box..  See the domain it has is the win10 box computer name -- which sure in the hell is not the domain or name of my i5-w7 box.. I have no idea what you were doing wrong or what your issue was.. But it has nothing do with domain names having to be in the username box..

 

post-14624-0-32089600-1437566998.png

 

  • 1 month later...

Not sure what your issue was andy bird, but As i have clearly shown with screen shots you don't need to put in the computername or workgroup name to access a share with username from that box..

Not sure what your issue was andy bird, but As i have clearly shown with screen shots you don't need to put in the computername or workgroup name to access a share with username from that box..

 

His issue was the exact same issue I had. Using the correct username and the correct password would not work.  All I know is that doing above works. So you are saying it doesn't matter what you type in before the username and that we can just type nonsense?

That being said, it did work on one of my machines, it accepted a username and the password to access the same exact network, share. So maybe it's a bug.

 

 

Edited by warwagon

not a bug its understanding how it works!!  Did you already have a session open with guest?  if a machine is member of workgroup not a member of domain then the domain name of the user account is completely meanless to that machine.. It can only look in its local database of users, does not care if the domain is whatever or something or its correct name..  It doesn't matter its just looking for username and password.

As you can see from screenshots I can send complete gibberish for domain/computer name and it still works

For all we know the use was putting in the wrong freaking password and then when saw this he typed it in correctly and WOW this works ;)  When it has NOTHING to do with it!!

edit:

So as you can see here my computer is called i5-w7, and that is what is listed as domain.  I did not put anything in username field and access it just fine

nocpudomused.thumb.png.dc299b7bb72f27f78

I then killed the session on the win10 machine who's name is win10 btw and my session on my machine and then tried again to connect and got prompted.  I then put in whatever as my domain\computer name and works just the same.

This is not part of the auth mech when authing to a machine that is not in a domain so what you send or don't send has nothing to do with the authing to the shares.

whateverworks2.thumb.png.b27884735f72264

So not sure what your issue was or is or what this new guys problem was, etc.. But you sure and the hell do not need to send the computer name workgroup or whatever to auth to a share if the machine is not part of a domain.

edit:  And just because I like to be complete in info.. That was from win7 to win10 machine.. This is from win10 to window7 machine - again.. nothing in the dialog for domain and just or can put in complete gibberish and still works..  Because it does not MATTER!!!

win10towin7.thumb.png.e2b7a05ca3375c21b8

Edited by BudMan

Budman, which build you're on win 10, and did you upgrade or install from iso?

I'm still having this issue where I could not connect to network drive,

I've tried warwagon solution, tried your's, tried AllowInsecureGuestAuth, disable PIN, use local Administrator account, use local account, use the same WORKGROUP, enable netbios, enable sharing & discovery, enable all services, reset, startup repair, map netdrive from explore, net use, powershell, and still none of them works (Access Denied, I'm dual booting this machine with windows 7 still can connect).

I'm on build 10240, seems that some people who upgrade to this build unable to use net drive, and I did upgrade from 8.1, shares we're working before upgrade.

I really wish I could find a solution without re-installing (reinstall might not work as well), I saw plenty of cummulative windows 10 update yesterday, but still downloading, hope they fix it.

I am on build 10240 which was install from iso from TP install with clean option.

While PIN stuff might be causing you issues.. So your authing to what exactly another windows 10 machine, windows 8, samba? some NAS.. What are you authing too?  Why don't you just sniff the traffic and see exactly what is going on.. What error do you get when you try and auth via cmd line?

Are you trying to just auth to IPC$  An actual share?  You sure you don't see any sessions open that are already denied with say guest?  You can not auth or have a session open to a machine that is denied or even allowed but not access to shares and then try and auth as a different account.

Simple sniff should show you exactly what is going on..

Sorry but from all the stuff you listed you have tried, sure seems like your just pointing and clicking at ###### without any basic understanding of what is actually going on or required to share files.  And the fact that it works from windows 7 is prob just pure dumb luck ;)

edit.. So for example.. Here is when I just run \\i5-w7 and get challenged to auth but machine sends current creds for that budman account.

failure.thumb.png.c9377693125c3f41c8e0c4

Then latter after I get prompted and actually send the correct password for the budman account on that machine i5-w7 I get accepted and then get share listing, etc..

auth.thumb.png.6a405badf4f8a8fbe5c9cff1d

If you post up a sniff we can take a look see to what is actually going on and why your being denied.

 

 

Edited by BudMan

The target is a windows 7 machine.

I've tried IPC$, tried browsing the target, tried connect the shared folder directly, and none of them works. I got "System error 5 has occurred. Access is denied." on the cmdline.

Yes, I just point and click that ######....:yes:, I'm not that tech savvy guys, I just knows things that most people don't have to know.

I did have high expectation on the upgrade, and I got pure dumb luck :(, perhaps I'll have to sniff it up indeed or
just hit it with a ((( BIG HAMMER ))) and shove an windows 10 iso in it to get it back on :D

thanks Budman, you show me the way to use ((( THE FORCE )))
see yaa ...

well what account are you using to auth with..  What is the exact cmd line your using?

So for example error 5 yes is a standard error you should get if your not authed and you try and browse it with net view

connectionstowin7fromwin10.thumb.png.317

so even though I am logged in with budman on the win10 machines its password is NOT the same as the budman account over on the win7 machine.. This is why fails when I try and just access it..  Now if I would set the password to match - then all the problems go away.

matchpasswords.thumb.png.221feb41b711019

 

 

 

LOL!! I'm sorry, but this isn't anything new.

For as long as I can remember, to access a share, the best practice way of doing it is domain or computer name\username.

And for the better part, yes having your machines in the correct workgroups helps. Did you ever use 3.11 for Workgroups, Budman? 

Edited by Jared-

yes I used 3.11 back in the day.. Workgroups have NOTHING to do with this issue.  Workgroups have nothing to do with auth and are only used to maintain browse list for machines in the same one.

While it might be good practice to send appropriate computer name when authing to it.  If the box is not member of a domain that your authing to it is of no use to that machine since it only has one place to look its own accounts.  Now if the box is a member of domain then yes you would want to tell it which account your authing to a local account or a domain account, etc.

I will agree users not understanding basics of file sharing and authing to a windows machine is nothing new that is for sure.. And then FUD that passes for a fix is also nothing new ;)

Fix: should be removed from this thread title that is for damn sure since what he posted is just nonsense and nothing to do with whatever his problem was.

If I had to guess he was sending the wrong password, then when he put in computername\username he sent the correct one -- oh that was the issue, when no it wasn't!!  Since it has nothing to do with the authing process.

  • 2 weeks later...

I ran into an issue that was driving me nuts after installing Windows 10 on 2 computers. I could not access any of my network drives from either of those machines. It kept telling me my password was incorrect, but it wasn't. But I would go to a Windows 8 or Windows 7 machine, enter the username and password and it would connect first try.

Normally when you connect to a network drive it prompts you for your username and your password.

On windows 10 in the username box instead of entering just the username enter the computer name plus the username.

Example.

computername\owner  (Do not put \\computername ... that will not work so leave the \\ off)

Now enter the password and you should be able to access the network share just fine.

Hope this helps anyone else that was pulling their hair put.

You, my friends, area  genius ... and I don't say that to many people.

I was trying everything in the book, and out of it, to get connection to my kids PC so I can swap files on and off with each other, (we don't talk much), and this windows OS is the only one that was annoying me. I did what you suggested, -- PCname\accountname -- and voilà, job done. 

If I could send you a bottle of red down your ethernet port I would, but I can't, so you'll have to have an imaginary drink on me.

Genius.

Specifying a logon domain for a network share has always been a feature, it's how Windows differentiates between a local logon and a network logon, this isn't a bug or unique to Windows 10.

And is NOT required if box your authing to is not a member of a domain..  As you clearly see from multiple examples sending BS as domain\computername still auths since the machine can only check its local account base.  Yes if your going to auth to a member of a AD machine, then you would have to specify which you want to use its account or domain account or you could run into problems.

Normally if your on AD, then your machines would both be members and you wouldn't have to get a popup since your domain account have been given permissions by the admin of the domain.

^ Wrong. 

No matter if you're on a AD environment or workgroup, it's ALWAYS been best practice to specify computer name\user name. 

Just like when I connect to my NAS, I have to specify <nas name>\<nas user name>.

Either way, who f'ing cares...

^ Wrong. 

No matter if you're on a AD environment or workgroup, it's ALWAYS been best practice to specify computer name\user name. 

Just like when I connect to my NAS, I have to specify <nas name>\<nas user name>.

Either way, who f'ing cares...

 

In this case it fixes people problems. People even want to send me alcohol over Ethernet.

In actuality, I think this is an issue that sometimes arises when you have the same username on two computers and don't use certain features of the networking. then it will think you're using the local users instead of the remote and it fails. 

 

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.