+Warwagon MVC Posted June 30, 2015 MVC Share Posted June 30, 2015 (edited) 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 August 27, 2015 by warwagon Ant C, Andy Bird, +Elі and 4 others 7 Share Link to comment Share on other sites More sharing options...
nekrosoft13 Posted June 30, 2015 Share Posted June 30, 2015 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. Link to comment Share on other sites More sharing options...
xendrome Posted June 30, 2015 Share Posted June 30, 2015 This has always been this way, like on a domain for instance. DOMAINNAME\USERNAME for authentication and \\COMPUTERNAME\SHARE for UNC. T3X4S and Aergan 2 Share Link to comment Share on other sites More sharing options...
+Warwagon MVC Posted June 30, 2015 Author MVC Share Posted June 30, 2015 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. WarnerL 1 Share Link to comment Share on other sites More sharing options...
Aergan Posted June 30, 2015 Share Posted June 30, 2015 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. Link to comment Share on other sites More sharing options...
Mando Posted July 1, 2015 Share Posted July 1, 2015 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. Link to comment Share on other sites More sharing options...
+BudMan MVC Posted July 20, 2015 MVC Share Posted July 20, 2015 "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. 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 Nor do you even have to put in a domain portion 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.. Link to comment Share on other sites More sharing options...
Andy Bird Posted August 26, 2015 Share Posted August 26, 2015 @+warwagon thank you! this was driving me mad. The username has all I have ever used before. +Warwagon 1 Share Link to comment Share on other sites More sharing options...
+BudMan MVC Posted August 27, 2015 MVC Share Posted August 27, 2015 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.. Link to comment Share on other sites More sharing options...
+Warwagon MVC Posted August 27, 2015 Author MVC Share Posted August 27, 2015 (edited) 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 August 27, 2015 by warwagon Link to comment Share on other sites More sharing options...
+BudMan MVC Posted August 27, 2015 MVC Share Posted August 27, 2015 (edited) 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 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. 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!!! Edited August 29, 2015 by BudMan Link to comment Share on other sites More sharing options...
darkcell Posted August 30, 2015 Share Posted August 30, 2015 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. Link to comment Share on other sites More sharing options...
+BudMan MVC Posted August 30, 2015 MVC Share Posted August 30, 2015 (edited) 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. 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.. If you post up a sniff we can take a look see to what is actually going on and why your being denied. Edited August 30, 2015 by BudMan Link to comment Share on other sites More sharing options...
darkcell Posted August 31, 2015 Share Posted August 31, 2015 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 ######...., 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 orjust hit it with a ((( BIG HAMMER ))) and shove an windows 10 iso in it to get it back on thanks Budman, you show me the way to use ((( THE FORCE )))see yaa ... Link to comment Share on other sites More sharing options...
+BudMan MVC Posted September 2, 2015 MVC Share Posted September 2, 2015 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 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. Link to comment Share on other sites More sharing options...
binaryzero Posted September 3, 2015 Share Posted September 3, 2015 (edited) 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 September 3, 2015 by Jared- Link to comment Share on other sites More sharing options...
+BudMan MVC Posted September 3, 2015 MVC Share Posted September 3, 2015 (edited) 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. Link to comment Share on other sites More sharing options...
Ant C Posted September 15, 2015 Share Posted September 15, 2015 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. Link to comment Share on other sites More sharing options...
+BudMan MVC Posted September 15, 2015 MVC Share Posted September 15, 2015 JFC -- see how the FUD spreads!!! Mando 1 Share Link to comment Share on other sites More sharing options...
HawkMan Posted September 15, 2015 Share Posted September 15, 2015 The difference between "this isn't supposed to have any effect, it doesn't work like that! and "it fixed the problem" Link to comment Share on other sites More sharing options...
Noir Angel Posted September 20, 2015 Share Posted September 20, 2015 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. Link to comment Share on other sites More sharing options...
+BudMan MVC Posted September 20, 2015 MVC Share Posted September 20, 2015 (edited) 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. +Thayios 1 Share Link to comment Share on other sites More sharing options...
binaryzero Posted September 21, 2015 Share Posted September 21, 2015 ^ 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... Link to comment Share on other sites More sharing options...
+Warwagon MVC Posted September 21, 2015 Author MVC Share Posted September 21, 2015 (edited) ^ 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. Link to comment Share on other sites More sharing options...
HawkMan Posted September 21, 2015 Share Posted September 21, 2015 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. Link to comment Share on other sites More sharing options...
Recommended Posts