Can't write to share / not asking for credentials: Win10 (Going crazy!)


Recommended Posts

I have to leave my shares set to Public. If I set them to Secure then I can not write to them. When I try I get this pop-up.

 

denied.PNG.a8e7317284f6bbd11e3bb564ecc40ba1.PNG

 

This used to work. It used to ask me for a username and password but no longer does.

 

I've cleared out all credentials in Windows Credentials Manager. I've ran the "New Permissions" tool. 

 

Is it because my unRAID trial is expired? 

 

This is one of the most basic features in any NAS and it's not working. Very frustrating. I've read the nearly 20 posts just like this but can't find a solution. 

Why would this just start after a month of working properly? 

 

Here is how I have my media share set up:

 

smb.PNG.d53f1f47053e44d8ca1e8a02b26b88ae.PNG

Link to comment

Start by reading this post and the following posts:

 

    https://forums.unraid.net/topic/25064-user-share-problem/?tab=comments#comment-228392

 

Note particularly that only one user is allowed to log into a server at time from each computer via SMB.  (Although, there is a 'sneaky' way to add a second login with an IP address...)

 

If you need to see who has logged into your server, you should be able to find out by reading this article:

 

    https://www.networkworld.com/article/3263752/reviewing-logins-on-linux.html

  • Thanks 1
Link to comment

Ok so I figured out the issue.  Here is what I did:

 

1. created a user in unRAID with the same user name as my Windows10 PC. (different password)

2. in unRAID changed the SMB Security Settings/SMB User Access for the Media share to give my new user read/write access and security type to "Private" (this is very important, you must use PRIVATE not SECURE)

3. rebooted my pc.

4. opened command prompt and typed "net use * /delete" just to make sure credentials were cleared out. 

5. opened the network drive share (\\tower\Media in my case) in Windows Explorer by clicking on the location field at the top and typing in "\\tower" (what I named my unRAID box) 

 

tower.png.fb818c91eab89b5fb31937db72eb4e89.png

 

Then the Media folder will show up. When opened the contents will show up but when you try to make an edit (add a New Folder) it then prompts me for username and password.

 

The important thing here is to set the share's security to "Private" in order to initially establish the connection. If you use "Secure" you will not get a prompt to enter a Username and Password. You will just get a denied pop-up and have no way to authenticate:

802653570_densat.PNG.a3fb6cb924e72211546bca55080c8292.PNG

 

You must establish the connection by using security: "Private."  Then, once connected you can change it to "Secure"

 

I'm not sure why you would use Secure over Private as there seems to be no actual difference. 

 

I feel like unRAID should add a note next to the Security type selection field saying you must choose Private if you are connecting unRAID as a network share for the first time. Will save hours of headache for what should be the most basic feature of a NAS solution. 

 

Hope this helps someone else struggling with this. 

 

 

Edited by adminmat
Link to comment

Something is going on here.  I just tested it on my WIN10 (1809) setup using two computers and it working properly here.  If you get this screen when you are trying to access either a Secure or Private share, you have a 'user' logged on to SMB from that computer you are using:

 image.png.b648e6d7ed52361301c59ba46204b296.png

You should get a screen to 'Enter Windows Credentials' screen if there is no login to the server from that computer.  Make sure that you set the permissions for each user when setting up a share to use Secure or Private.  (There is a 'no access' permission for the Private option--- and it is probably the default!  The default for Secure appears to 'read-only'. )  

 

The difference between Secure and Private is explained by the 'HELP' on the 'Share -->  SMB Security Settings tab' which is turned on with the Help (?) icon on the toolbar. 

 

Be sure to make liberal use the "net use * /delete" command on the PC when testing. 

 

Remember not to setup two users for any person who will be using the server.  Create only one 'user' per person and set the permissions for that user for every Private (or Secure) share that want that user to have on that share.  (Most of the time, a person will be assigned to a single PC so the PC and the person are one in the same.  If someone moves around between computers on a network, this can cause problems if they click the box to remember credentials...)

 

One more minor point.  If you are using only Public or Secure access to shares, you do not have force a login if the access is read-only.  With read-only, you can still copy a file off the server!

Edited by Frank1940
Link to comment
22 minutes ago, Frank1940 said:

Something is going on here.  I just tested it on my WIN10 (1809) setup using two computers and it working properly here.  If you get this screen when you are trying to access either a Secure or Private share, you have a 'user' logged on to SMB from that computer you are using:

 image.png.b648e6d7ed52361301c59ba46204b296.png

 

When you say "you have a 'user' logged on to SMB from that computer you are using" do you mean I'm logged on in unRAID or in Windows? Prior to each attempt I cleared out all credentials both in Credentials Manager and using the "net use * /delete" command. Rebooted, etc. So how would I still have a user logged in? Also, I do get the prompt to 'Enter Windows Credentials' but like i said, only when I have the Security set to 'Private'. When it's set to 'Secure' I get this:

 

1013534074_densat.PNG.52045b3af5b30d40ae435aa27977903d.PNG

As soon as I change it back to 'Private' I get the prompt to 'Enter Windows Credentials'. 

22 minutes ago, Frank1940 said:

You should get a screen to 'Enter Windows Credentials' screen if there is no login to the server from that computer.  Make sure that you set the permissions for each user when setting up a share to use Secure or Private.  (There is a 'no access' permission for the Private option--- and it is probably the default!  The default for Secure appears to 'read-only'. )  

Yes I set the SMB permissions to

Export: Yes

Security: Secure

(SMB User Access)

"my user name" : Read/Write

 

The difference between Secure and Private is explained by the 'HELP' on the 'Share -->  SMB Security Settings tab' which is turned on with the Help (?) icon on the toolbar. 

I will take a look 

Be sure to make liberal use the "net use * /delete" command on the PC when testing. 

This is the instructions from Limetech 

Remember not to setup two users for any person who will be using the server.  Create only one 'user' per person and set the permissions for that user for every Private (or Secure) share that want that user to have on that share.  (Most of the time, a person will be assigned to a single PC so the PC and the person are one in the same.  If someone moves around between computers on a network, this can cause problems if they click the box to remember credentials...)

 

One more minor point.  If you are using only Public or Secure access to shares, you do not have force a login if the access is read-only.  With read-only, you can still copy a file off the server!

As for now it's working even as I have the Security set to 'Secure'.  I just have to set it to 'Private' in order to be prompted for my username and password. 

Maybe because I'm still on V 6.6.7 ?   Fortunately I don't have a need for more than one user for this unRAID server. But i'm surprised it would be this difficult to connect to unRAID from Windows 10 even just if you use it as a NAS.  

 

Link to comment
2 hours ago, adminmat said:

"my user name" : Read/Write

I almost hate to ask this but you did click on the 'Apply' button for this selection.  I will assume that you have done this.  (I will tell you that rechecking checking my earlier work, I am seeing basically the same thing.)

 

I think we are being bitten by a variation of this bug/feature in this post:    https://forums.unraid.net/topic/25064-user-share-problem/?tab=comments#comment-228392

Quote

"my user name" : Read/Write

 

 

 

Except when you click on a Secure share, you will automatically have gained read access so you gain access as a guest and windows see that you have access to this share using this guest login and SMB reject you because you are already connected to this share as an invalid user to do what you wanted to do.  (I don't know what would appear if you were to 'map' this share as a drive but that might work...)   

 

By the way, I do use the Secure setting on virtually all of my shares but none of my users have anything but read-only access. That is what I want as it provides protection against Ransomware.   (I could easily delete my users but I do want to be able to help others with these types of problems.)   I handle all other file operations using the Krusader Docker. 

Link to comment

Ok something is way broken here. After I finished moving some files I changed my 'Media' share to 'Export: No' and changed the user permission to 'Read-only', applied the changes and I can still access it from my Windwos 10 PC on the network and can even write to the Media share. With the settings below I can still add files! 

 

wtf.PNG.c4477f1c4d2554dae2d3daae1ab0a354.PNG

 

This is scary. I have no idea now what has access to my shares if I can't even block it in the unRAID WebUI. 

 

Edited by adminmat
Link to comment

Ok i figured out the issue. If you change the share to 'Export: No' and hit Apply FIRST, and then you change the permission field to 'Read-Only', the change does not take effect and it leaves the share open and unsecured.  So you have to FIRST change the User Access value THEN change the SMB setting. Wow. 

 

Is this a known issue? I think Limetech should be made aware of this. 

 

 

Link to comment

If this is true, I would suggest that you post up a bug report. (there is a Forum sub-section for this called Bug Reports in the unRAID OS 6 Support section)  But before you do that, close Windows Explorer, restart it  and see if you still have the same access and permissions.  It still might be considered a bug but if closing and restarting Window Explorer fixes it, the potential for damage is considerably reduced.

Link to comment
3 minutes ago, adminmat said:

Ok i figured out the issue. If you change the share to 'Export: No' and hit Apply FIRST, and then you change the permission field to 'Read-Only', the change does not take effect and it leaves the share open and unsecured.  So you have to FIRST change the User Access value THEN change the SMB setting. Wow. 

 

Is this a known issue? I think Limetech should be made aware of this. 

 

 

If the Export value is set to No then the permissions field should not even be relevant.     It sounds like there might be a bug in that you even can change the permissions field with it in that state.

Link to comment

Yes, I just submitted a bug report directly to Limetech via the WebUI describing the issue. It may have been resolved in later versions as I'm still on 6.6.7. 

 

Curious if you guys try this what result you get? Try changing the Export setting to No first, click apply. then change the User access to read-only, click apply and test to write to the share. 

 

@Frank1940 can confirm that I closed windows explorer, reopened it and can reproduce results. 

 

Another strange thing: I added another share to test this on my laptop. I realized to reproduce the results above you have to grant Read/Write permissions to both my desktop and laptop. Then change the Export to 'No'. Then both clients to 'Read-only'

 

If I just grant access to one client then change the Export to 'No' it wont reproduce. 

Link to comment

I had a couple of wild thoughts after sleeping on this.  Try setting up a credential for your 'server user name' in Credential Manager and see what the results are.  I am thinking that might work since the first time you 'touch' the server, your PC should be using the stored credentials. 

 

Second wild thought.    Setup a share and make it Private.  Map that share as a drive on the client.  First time, you logon to the mapped drive have Windows save the credentials.

 

Why I think this will work is because it is the way that most corporate networks would be deployed.  The user would first log onto the computer and then connect to the server.  That is your security-- that first login as the user may never realize that he is really using a server.  You would probably not want to require a second login at this point  as that would require a second password.  In fact,  I would suspect that much of the time, the same user name and password would be used for both. (Not the best security practice, I know, but a case could be made that the only one login should be required for an employee to do his job!) 

 

I think our problem is that we want to use SMB in two different modes.  Most of the time, we want to have read-only access to the files (which Secure with its guest access provides)  but occasionally we want that same user/computer (with a different login) to have full access (read-write) for file management reasons.  It could well be that SMB is (deliberately or otherwise) will not accommodate this in a logical manner.  SMB does not really provide the means for a 'client computer' to logout off a server.

Link to comment
  • 3 weeks later...
On 11/3/2019 at 8:57 AM, Frank1940 said:

I had a couple of wild thoughts after sleeping on this.  Try setting up a credential for your 'server user name' in Credential Manager and see what the results are.  I am thinking that might work since the first time you 'touch' the server, your PC should be using the stored credentials. 

 

Second wild thought.    Setup a share and make it Private.  Map that share as a drive on the client.  First time, you logon to the mapped drive have Windows save the credentials.

 

Why I think this will work is because it is the way that most corporate networks would be deployed.  The user would first log onto the computer and then connect to the server.  That is your security-- that first login as the user may never realize that he is really using a server.  You would probably not want to require a second login at this point  as that would require a second password.  In fact,  I would suspect that much of the time, the same user name and password would be used for both. (Not the best security practice, I know, but a case could be made that the only one login should be required for an employee to do his job!) 

 

I think our problem is that we want to use SMB in two different modes.  Most of the time, we want to have read-only access to the files (which Secure with its guest access provides)  but occasionally we want that same user/computer (with a different login) to have full access (read-write) for file management reasons.  It could well be that SMB is (deliberately or otherwise) will not accommodate this in a logical manner.  SMB does not really provide the means for a 'client computer' to logout off a server.

Hey Frank sorry to leave you hanging on this. I haven't had any issues since I've been changing the security (read/write) setting first. I also started something new that makes my server much more secure. Before I was opening my entire media share to read/write from my main PC when transferring files to unRAID. But now I created a "Temp Media" share and only open that up when needed to transfer files to unRAID from another client. Then I use Krusader to transfer the files to the main media share. So if something like ransomware gets compromised my Desktop PC it will only harm the few files I have in the Temp share. Not my 6TB of media. 

 

I think this should be recommended to all new unRAID users. 

Link to comment
2 hours ago, adminmat said:

Hey Frank sorry to leave you hanging on this. I haven't had any issues since I've been changing the security (read/write) setting first. I also started something new that makes my server much more secure. Before I was opening my entire media share to read/write from my main PC when transferring files to unRAID. But now I created a "Temp Media" share and only open that up when needed to transfer files to unRAID from another client. Then I use Krusader to transfer the files to the main media share. So if something like ransomware gets compromised my Desktop PC it will only harm the few files I have in the Temp share. Not my 6TB of media. 

 

I think this should be recommended to all new unRAID users. 

Here is another scheme that does the same thing:

 

   https://forums.unraid.net/topic/58374-secure-writing-strategy-for-unraid-server-using-write-once-read-many-mode/#comment-572532

 

Link to comment
  • 4 years later...

I know this isn't the exact issue I was having (very close) but I solved this by navigating to the folder in question that I couldn't write to and checking and then changing the permissions for that folder. For some reason I didn't have read/write access to that particular folder (one of the only folders on the share, making me think it was a share issue) so after changing it, it all worked fine. So hard to diagnose though... ugh. Thank you.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.