Windows 10: Connecting to my SMB share, Windows says my credentials are incorrect, even thought they’re...

I can use the same share with same credentials fine no problem. The account password is extremely simple, and I’ve tried resetting it twice now. Is this just some weird bug, and how can I get around it?

submitted by /u/Piipperi800
[link] [comments]

:)

 

Safety of Login credentials for SMB...

Ok so similar but slightly different question:

Background:

• Storage hosted by my Linksys WR32X Router (see screenshot) with authentication credentials
• SMB v1, v2, and v3 are all enabled on my Win10 PC via the "Enable Features" window (and I've restarted my PC)
• My Windows 10 account uses my MS Live email address as a username and I have 2-step authentication set up as well

A Timeline:

• The NAS successfully shows up and is accessible from the Network page in Win Explorer
• I've successfully mapped the storage to a Network Drive in Windows using the authentication credentials I set in my router's settings page (again see screenshot)
• When I try to access the SMB share via a separate device on my network (my FireTV device running Kodi 17--which supports up to SMB v3), I get caught in an endless loop of it asking for a username and password.
  • I've tried using the credentials I set in my router settings, which worked when I mapped the share to a network drive in windows, and it didn't work in Kodi
  • I've tried un-mapping and re-mapping the share to a network drive using my windows 10 account username and password instead of the credentials set in my router settings, which did not work for either mapping the drive in windows or for accessing it in Kodi
  • I also tried generating an app-specific password via my Microsoft account settings in case the 2-step authentication set on my account was causing the issue (much like you have to do to add your account to Outlook Desktop App when 2-step is set up)

I just want to access my SMB share from my FireTV device (or any network device for that matter) without having to create a new local user. I saw some responses saying that I need to set up a new local account and use it's credentials to map the drive and
then it should work, but is this REALLY necessary? It seems like a redundant workaround...

So, what if I don't want to create a new local user? I like having jut one account on my Win10 PC and that uses my
MS email address as the Win10 Account username.

Any suggestions? What am I missing here? Thanks in advance MS community!

 

SMB share credentials

Hi,

I have a synology unit that is added to the microsoft AD as are all the PCs that access that unit. all the users are members of an AD group that has read/write permissions on a particular folder. When a user tries to access that folder, they get a message "windows
cannot access..... you do not have permission....."

When i add that user's local synology account to the folder, they can access the folder. could it be that the user's computer is trying to access the folder using their local synology account credentials and not the AD credentials? is there a way to check
what credentials windows is sending to access the synology SMB share?

that server doesn't appear in Windows Credentials, but it's not asking for credentials at all, so something is going on

Thanks,

Albert

 

Safety of Login credentials for SMB...

I have found a way to stop using my Microsoft account credentials for connecting to SMB shares. For this, I created a new local user account on my laptop, and gave that account the required permissions for shared folders. I can now use the login credentials
for that account for connecting to SMB shares on my laptop using any device, and is a much safer thing to do. I can now keep my Microsoft account credentials safe by not having to provide it to any app.

Another useful thing about is this is that you don't even have to login using the new account credentials (which means Windows doesn't have to create a separate user folder for that account, and therefore this account won't take any disk space either).