So,

 

My kids have come of age where they are a threat to everything on my network

 

I need to be able to lock down the permissions to my existing unRaid server, but I can't seem to get my main windows box to authenticate properly, and I'm starting to pull my hair out.

 

I've tried almost everything I could find on the forums to get this working, and it's still not there.

 

So, here's where I'm at...

 

I've created a new share (SecurityTest), and several users (one matching my Windows User Account name, one completely different, one matching the "left of the @" on my Windows Online Account, one for Kids, one for Kodi, ...).

 

I set "SecurityTest" to share Secure through NFS, and Private through SMB, giving read/write access to a subset of the users that's appropriate.

 

So, when I try to access the SecurityTest share, I get the windows login prompt, and can't get anywhere.

 

I've rebooted both systems, tried the "net use */delete" command, removed some credentials from "Generic Credentials", tried to hit the private share first, ...

 

And, nothing seems to be working to enable me to login to the restricted drive from my Windows 10 machine...

 

Help!!!

Here

Thanks Trurl.

 

I read through that post earlier (before posting my plea) and understand what's going on in his description, but I still can't get this thing working.

 

In particular, I closed all of my open windows, used "net use */delete", went directly to the test folder (typing \\servername\SecurityTest into a file explorer), then used one of the authorized accounts - and it won't let me in.

 

I've tried all of the authorized accounts...

Went through and tried everything in the link again, and still don't have anything working...

So, I kept hammering on this, trying different things, redoing all of the work in the order specified in Trurl's note, etc and eventually found something interesting.

 

If use the IP address to access the share, it asks for my username and password, and then grants appropriate access.

 

So, I believe, on the windows side, there's something other than "net use * /delete" that needs to be done to clear out the old credentials...

 

Any ideas?

For me, i had top set my shares up using the server ip to get the logins to work properly on windows 10.

 

I have around 6 windows 10 machines at home and the same happens for them all. One thing i did notice was that my router did not always pick up my unraid using its name. It was always listed via the IP but sometimes used to show a name of "unknown" which makes me believe some of the naming issue may have been from that.

 

I have seen mention of people having to disable certain SMB protocols to get the the logins working properly. Would network drives work for this instance or do you need the username and password entered each time?

I've had 8 network drives set up on different machines to my unraid server and have yet to have any issues since switching to the IP based network address.

 

Another thing i had to do to get things working properly was to actually create all my users using the exact same username and password as the windows logins to get this to work properly as windows often changes the login details being used.

As an example, i had a network drive mapped before using the user "server123" as a test. This logged in for a while but then stopped. Going into the windows credentials view the username had changed to "windows-ap494/server123" without notice.

 

I have also had instances where the username has remained the same and simply editing the credentials to have the password again allowed me into the system almost as if windows forgot the password.

 

I'm not sure if this will help at all but that is all the issues i had to get my SMB shares working.

 

Regards,

Jamie

For me, i had top set my shares up using the server ip to get the logins to work properly on windows 10.

 

Ugh.  I could go this route, but prefer to understand what's going on.

 

Another thing i had to do to get things working properly was to actually create all my users using the exact same username and password as the windows logins to get this to work properly as windows often changes the login details being used.

 

I have the "unified login account", so it's got [email protected] as the user name with a "firstname lastname" attached.  Previously, I could just use the "firstname" as the username, and that seemed to work last time I tried all of this.

 

Looking back, I think all of this worked fine on Windows 8.1, and then fell apart when I upgraded to Windows 10 (I had to disable all the user account settings to get in properly...)

If use the IP address to access the share, it asks for my username and password, and then grants appropriate access.

 

So, I believe, on the windows side, there's something other than "net use * /delete" that needs to be done to clear out the old credentials...

Use the Windows Credentials Manager to remove any stored credentials.

There were no stored credentials in the Credential Manager

 

I did finally get this to work (for now).  No idea what did it, but here's what happened.

 

1) I had a mapping setup from the ip to the hostname in the windows hosts file.  I removed it, and rebooted into safe mode.

2) I used the net use * /delete in Safe Mode (despite there being nothing there).

3) I was unable to connect using the server hostname in safe mode (\\servername\share), so I used the IP address (\\ipaddress\share) and it worked.

4) I rebooted into normal, and suddenly mapping was working using the hostname (\\servername\share).

 

Again, I have no idea why what I did would affect anything too much, but wanted to provide this for those that can only get things to work by IP.

There were no stored credentials in the Credential Manager

 

I did finally get this to work (for now).  No idea what did it, but here's what happened.

 

1) I had a mapping setup from the ip to the hostname in the windows hosts file.  I removed it, and rebooted into safe mode.

2) I used the net use * /delete in Safe Mode (despite there being nothing there).

3) I was unable to connect using the server hostname in safe mode (\\servername\share), so I used the IP address (\\ipaddress\share) and it worked.

4) I rebooted into normal, and suddenly mapping was working using the hostname (\\servername\share).

 

Again, I have no idea why what I did would affect anything too much, but wanted to provide this for those that can only get things to work by IP.

Probably it was the rebooting that did it. It seems like when a Windows machine is the SMB local master it often has trouble finding non-Windows machines by name. When you rebooted possibly something else took over as the SMB local master. If your server will always be on you can make it have this function in SMB Settings. Some have gotten their router to perform this function for them as well.

Probably it was the rebooting that did it. It seems like when a Windows machine is the SMB local master it often has trouble finding non-Windows machines by name. When you rebooted possibly something else took over as the SMB local master. If your server will always be on you can make it have this function in SMB Settings. Some have gotten their router to perform this function for them as well.

 

I have unRAID marked as the SMB Master in the settings...  Do I need to do something in windows to tell it that it's not?

 

Also, I may have spoken too soon on the fix...

 

I can get into the SecurityTest share, but it can't resolve the server name for \\servername\Media (which is the bulk of my share).

Probably it was the rebooting that did it. It seems like when a Windows machine is the SMB local master it often has trouble finding non-Windows machines by name. When you rebooted possibly something else took over as the SMB local master. If your server will always be on you can make it have this function in SMB Settings. Some have gotten their router to perform this function for them as well.

 

I have unRAID marked as the SMB Master in the settings...  Do I need to do something in windows to tell it that it's not?

 

Also, I may have spoken too soon on the fix...

 

I can get into the SecurityTest share, but it can't resolve the server name for \\servername\Media (which is the bulk of my share).

If Windows already has grabbed SMB master then the unRAID setting won't matter until Windows gives it up. One of the Dynamix plugins will let unRAID test and indicate whether it is the SMB master. Don't know of any way to make Windows give it up. When it boots if it doesn't find one on the network it grabs it. This is a "feature" to insure one computer on the network is providing this function.

 

Are you saying \\servername\SecurityTest works but \\servername\Media doesn't? Is Media set to SMB Public access?

See the last couple of pages of the Dynamix plugins thread for an ongoing discussion of SMB Local Master.

Probably it was the rebooting that did it. It seems like when a Windows machine is the SMB local master it often has trouble finding non-Windows machines by name. When you rebooted possibly something else took over as the SMB local master. If your server will always be on you can make it have this function in SMB Settings. Some have gotten their router to perform this function for them as well.

 

I have unRAID marked as the SMB Master in the settings...  Do I need to do something in windows to tell it that it's not?

 

Also, I may have spoken too soon on the fix...

 

I can get into the SecurityTest share, but it can't resolve the server name for \\servername\Media (which is the bulk of my share).

If Windows already has grabbed SMB master then the unRAID setting won't matter until Windows gives it up. One of the Dynamix plugins will let unRAID test and indicate whether it is the SMB master. Don't know of any way to make Windows give it up. When it boots if it doesn't find one on the network it grabs it. This is a "feature" to insure one computer on the network is providing this function.

 

Are you saying \\servername\SecurityTest works but \\servername\Media doesn't? Is Media set to SMB Public access?

 

Yeah, that's what was happening.  But now, mysteriously it's working again.  Let me give it some burn in time and see if it stays happy...

Issue solved.

 

I think the combination of making all of the listed changes, followed by numerous (2-3) reboots of unRAID and Windows finally got it to a point that worked....