Windows Networking (non server) refuses to accept verified password, even after reset
Windows networking refuses to accept password - even when copied and pasted after reset!
No server involved. Just one machine sharing a bunch of its files with two others. The share is set up and working for one of the other two.
Set up the local user account for the second machine, using the same password on the host as on the client. From the client, the password was refused. So once I confirmed that it was definitely identical at both ends, I changed the password to SIMPLE, sent a copy back to the client using a "Turbonote" and copied and pasted that into the password field. Even that was rejected. Tried simple stuff like rebooting both ends but cannot get the "Server" to accept any password from the second client. And yes, it is clearly the password failing, not the connection. The turbonote helps prove you're on the same network but windows login is reasonably specific and distinguishes between failure to find a target and failure to authenticate. In this case, it clearly recognises the target, the share and the username. It's only the password it's refusing to accept and I haven't a clue how to bully it into submission.
Suggestions?
No server involved. Just one machine sharing a bunch of its files with two others. The share is set up and working for one of the other two.
Set up the local user account for the second machine, using the same password on the host as on the client. From the client, the password was refused. So once I confirmed that it was definitely identical at both ends, I changed the password to SIMPLE, sent a copy back to the client using a "Turbonote" and copied and pasted that into the password field. Even that was rejected. Tried simple stuff like rebooting both ends but cannot get the "Server" to accept any password from the second client. And yes, it is clearly the password failing, not the connection. The turbonote helps prove you're on the same network but windows login is reasonably specific and distinguishes between failure to find a target and failure to authenticate. In this case, it clearly recognises the target, the share and the username. It's only the password it's refusing to accept and I haven't a clue how to bully it into submission.
Suggestions?
You didn't actually say that not only the password but also the username were matched between client and server.
In this regard, please confirm that the same username/password *is* a User established on both client and server and not some other mechanism.
I suppose that all this is on the same subnet? Otherwise there are Windows firewall adjustments necessary.
Might there be a reason that the one client is working that's not obvious? Otherwise we'd be focused on the client that doesn't work.
Things that cause this include:
- mismatch of the User username/password .. BOTH.
- Advanced sharing settings - e.g. Network discovery is turned on. Fiile and printer sharing is turned on. Password protected sharing is turned on.
- Existence of (old?) Windows Credentials that aren't needed using the "username/password matching method".
In this regard, please confirm that the same username/password *is* a User established on both client and server and not some other mechanism.
I suppose that all this is on the same subnet? Otherwise there are Windows firewall adjustments necessary.
Might there be a reason that the one client is working that's not obvious? Otherwise we'd be focused on the client that doesn't work.
Things that cause this include:
- mismatch of the User username/password .. BOTH.
- Advanced sharing settings - e.g. Network discovery is turned on. Fiile and printer sharing is turned on. Password protected sharing is turned on.
- Existence of (old?) Windows Credentials that aren't needed using the "username/password matching method".
Both machines are Dell refurbs which the client has received in the past 36 hours, So virgin territory. Both W10-64-1903.
All settings identical and confirmed.
and its not just the credentials that I needed which failed. I couldn't logon to the host using any of the 3 creds I'd set up.
ALL the standard settings were checked and normal.
I've actually brought the errant machine home with me today and will be testing it on my own network tomorrow. If I get the same problem, I'll know it is a problem on the machine an re-image it. If I don't, then I'll know it's a problem on their network and start troubleshooting that. Will report back after those tests...
All settings identical and confirmed.
and its not just the credentials that I needed which failed. I couldn't logon to the host using any of the 3 creds I'd set up.
ALL the standard settings were checked and normal.
I've actually brought the errant machine home with me today and will be testing it on my own network tomorrow. If I get the same problem, I'll know it is a problem on the machine an re-image it. If I don't, then I'll know it's a problem on their network and start troubleshooting that. Will report back after those tests...
Should have posted this weeks ago. The errant machine wasn't. When I got it onto my own network I was able to connect to anything I wanted. Which put the focus back on the server.
Acting on a blind hunch, I simply moved the share. The object was to share the server's Documents folder with the other workstations as they all need access to some common tools. The Server was set up to save the output of the tools into its documents folder so I shared that. That folder started life as the default Windoze doc folder on the system drive. I moved it to a different drive, repointed the system to use the new location as the default doc folder and shared that instead. The problem evaporated.
Which tells us that it was a rights issue on the system drive; one of the more frustrating and opaque of the windows system "features"
Acting on a blind hunch, I simply moved the share. The object was to share the server's Documents folder with the other workstations as they all need access to some common tools. The Server was set up to save the output of the tools into its documents folder so I shared that. That folder started life as the default Windoze doc folder on the system drive. I moved it to a different drive, repointed the system to use the new location as the default doc folder and shared that instead. The problem evaporated.
Which tells us that it was a rights issue on the system drive; one of the more frustrating and opaque of the windows system "features"