Connecting to SMB Share Causes Windows to Hang

[kyle_poe]

Hi all. I am a relative newcomer to TrueNAS, so pleased to make the community's acquaintance.

I am attempting to set up a few shares for lab data management. I've had great luck setting up NFS shares and mounting them on linux clients. I have even been able to mount them on windows, using the hacky -o:nolock solution. However I am less than satisfied with the requirements to have Windows Pro to mount NFS, and even then I have heard (but not yet tested for myself) that NFS performance tanks on windows.

For these reasons, I have been attempting to create SMB shares to test. I followed this tutorial with no luck: the windows client couldn't connect to the share, but evidently it could tell something was there, because the file explorer/network wizard/anything else would hang when I attempted to interact with the share.

I have thus far been unable to find any other resources documenting this mode of failure. It seems like maybe its a permissions related issue, but I haven't been able to figure out what specifically if it is. I will also mention that the volume the shared dataset is on was set up to be case-sensitive, but the datasets that I am attempting to share are case-insensitive, so I don't suspect this to be the culprit.

My system is running TrueNAS-12.0-U4.1. Happy to provide any other information if it is relevant. Thanks in advance.

 

[JohnDigital]

That guide doesnt say to check Windows account and Samba Authentication are fairly new options in the TrueNAS user GUI (very bottom). Also instead of creating a user called homeuser, just make a user account that is the exact same as your actual Windows user account(s). Same names, pass, email, and join all to the same group, then you set up the group for access. It really does cut down on alot of headaches.

 

[kyle_poe]

Thanks for the reply. Let me make sure I understand your comment:

1. I should check Microsoft Account AND Samba Authentication when making the user
2. When making the user account, I should make the username, password, and email the same as the corresponding Microsoft account
3. I should add all users which I want to access the SMB share to the same group
4. I should go to Sharing > Windows Shares (SMB) > (Samba Share) > Edit Filesystem ACL > Add ACL Item and grant permissions to the group to which I added the user.

I have a few questions:

1. In (1), why is it necessary to indicate that the user has a Microsoft account? Doesn't this exclude access by Linux users without such an account? It is the case that my organization gives every user a Microsoft account, however this would cause headaches for shared Windows workstations (which, we unfortunately do have).
2. For (2), requesting the Microsoft account passwords from individuals when creating would seem to represent a security issue. Is this necessary, or just a recommendation for personal use?
3. These recommendations seem to be at the level of permission management; however, my computer cannot even see that the share exists. I have guest access enabled, so my understanding is that if I can't connect to it now, then changing user/group permissions won't matter. If this a correct understanding?

To reiterate:

• I can ping the server
• I can connect to an NFS share (no server-side issues)
• I have created an SMB share [windowshare] for dataset [windowset] configured for SMB sharing with guest access and full permissions, have the share enabled, and the SMB service turned on.
• I cannot connect either through drive mapping, adding a network location, or through file explorer.

 

[kyle_poe]

I'll mention that I have no luck when SMB1 is enabled either.

 

[JohnDigital]

So first restart Samba service if you havent done so. Then if you do \\192.168.1.11 (or whatever yours may be) in a Windows Explorer address bar you arent even prompted to authenticate? Have a look at pdbedit -L from a shell and make sure the homeuser is listed. You could also try to use the "net use" command from a Windows Command Prompt. i.e. net use z: \\192.168.1.11\windowshare user:homeuser PASSWORD

1. Because Microsoft ties accounts to an email address by trickery. Checking the Microsoft box does not prevent a different client connecting. Per the Help tip in the GUI "Set to allow additional username authentication methods when the user is connecting from a Windows 8 or newer operating system." Which you are. I know from experience that this box does not always need checked.

2. No this would be optional for your home user only since you are the admin. This is just how i have done it and I dont ever have permission issues. You can tackle users in accordance with your security policy.

3. From the sound of it you have everything correct. If Windows plain cant connect for whatever reason, then the permissions dont matter.

4. I think groups are the easiest way to manage multiple permissions. Add each user to a group then allow ACL per group. Feel free to do it per user, especially if you might only have a few.

5. Id also allow this group that you choose, to own the dataset outright as well as the share. As root can always access. If this is homeuser's share then let him own it.

 

[kyle_poe]

I've determined that this behavior actually has something to do with my work's VPN. I can only connect to shares when I am on the VPN, even when I am on-site. The situation seems to have evolved and I suppose is now beyond the scope of this question, though if you have ideas of why this might be the case I would love to hear them!!

 

[JohnDigital]

Yes this widens the scope of the problem. Not sure where to go.

 

[kyle_poe]

Thanks for your help. I'll look into this and will make another thread if it comes down to it.