SMB v1 doesn't seem to work after upgrading to U2

[ravensorb]

I know this has been discussed over and over :) That said, I am not able to get it working. In U1, I was able to set the system tunable and everything worked. When I upgraded to U2, this no longer worked.

Here is my tunables

I also tried setting the min protocol in the SMB service

Is there some other magic setting I am missing? :)

Note: The reason I need this to work is that I have several embedded systems running Windows CE and XP Embedded (so upgrading is not possible)

 

[jlpellet]

Tunables should not be needed. As shown in the attached, from the GUI, Services > SMB > Edit, check the box, save, then restart SMB service (may not be needed but I always do after a change). Hope this helps.
John

 

[ravensorb]

Thanks! That said, my bad for not including that screenshot too in the original post.

Even with that - still no luck.

 

[ravensorb]

Wonder if this might be a bug?

 

[anodos]

What's a bug?

 

[ravensorb]

That SMB1 support no longer is working after U1

 

[anodos]

You can check current running configuration by running the following command

Code:

root@freenas[/mnt/dozer/freenas/src/middlewared]# midclt call smb.getparm "min protocol" global 

NT1

I have "enable_smb1" set:

Code:

root@freenas[/mnt/dozer/freenas/src/middlewared]# midclt call smb.config
{"id": 1, "netbiosname": "freenas", "netbiosname_b": "truenas-b", "netbiosalias": [], "workgroup": "HOMEDOM", "description": "FreeNAS Server", "enable_smb1": true, "unixcharset": "UTF-8", "loglevel": "MINIMUM", "syslog": false, "localmaster": true, "guest": "nobody", "admin_group": null, "filemask": "", "dirmask": "", "smb_options": "", "zeroconf": false, "ntlmv1_auth": false, "bindip": [], "cifs_SID": "S-1-5-21-1651232507-1463021771-3103063853", "netbiosname_local": "freenas"}

 

[ravensorb]

Thanks for the suggestion -- it does show the NT1 is the min protocol. This issue is all clients that are expecting SMB1 are failing as of the upgrade which is what seems odd

Code:

# midclt call smb.getparm "min protocol" global
NT1

# midclt call smb.config

{"id": 1, "netbiosname": "FREENAS1", "netbiosname_b": null, "netbiosalias": [], "workgroup": "MYHOME", "description": "FreeNAS Server", "enable_smb1": true, "unixcharset": "UTF-8", "log
level": "FULL", "syslog": false, "localmaster": false, "guest": "media", "admin_group": "MYHOME\\domain admins", "filemask": "", "dirmask": "", "smb_options": "", "zeroconf": true,
 "ntlmv1_auth": true, "bindip": [], "cifs_SID": "S-1-6-21-1691157895-2129824241-3496991655", "netbiosname_local": "FREENAS1"}

 

[ravensorb]

I think I am getting somewhere -- I installed a stand alone Windows 10 AND Windows XP client computer and both of them are experiencing the issue.

Current Setup

• Freenas Server is connected to a home domain (Active Directory on a Windows Server 2016 machine)
• Freenas is setup with 1 zvol with 1 dataset configure as an SMB share type
• SMB share called "home" is setup with ACL set to "HOME' and "group" set to "HOMEDOMAIN\domain users" and is setup
  "home share"
• Client Computer A: is in a workgroup
• Client Computer B: is on the domain "HOMEDOMAIN"
• AD has an account for "testUser1" and "testUser2"

Test 1:

• Log in to Client Computer A with a local (non domain account)
• Map a drive to \\freenas\HOMEDOMAIN\testUser1 to drive U: (this completed successfully)
• Attempt to browse to U: drive -- this FAILS

Test 2:

• Log in to Client Computer B with a DOMAIN Account "testUser1"
• Map a drive to \\freenas\HOMEDOMAIN\testUser1 to drive U: (this completed successfully)
• Attempt to browse to U: drive -- this succeeds

Test 3:

• Log in to Client Computer B with a DOMAIN Account "testUser2"
• Map a drive to \\freenas\HOMEDOMAIN\testUser1 to drive U: (this completed successfully)
• Attempt to browse to U: drive -- this FAILS

Prior to U2 - test 1 and 3 worked without issue (and it should as it is a valid use case for non domain computers)

Note: test 1 and 3 work without issue if I connect to a share on windows computer that is on the domain (a windows based file server)

At this point this may not be a SMB v1 issue -- could it be caused by something else? Or are we looking at a bug here?

 

[ravensorb]

Any thoughts on this? Am I looking at it wrong?

Note: This is causing all non domain joined computers to no longer be able to access shares and if I roll back freenas versions it does start working.

 

[Samuel Tai]

I think you have a domain trust issue. Your domain needs to trust the standalone workgroup, and should also have SMBv1 enabled.

 

[ravensorb]

A "trust" issue with a workgroup? Thats a new one to me -- can you point me to anything that talks about this?

Note: I am wondering if i need to open a new issue as I don't think this is an SMB1 issue -- this is an SMB issue in general. I can confirm that if I go back to U1 everything works normally. I can also say with 100% confidence that this is not an issue with ubuntu servers that are accessed by windows clients and is not an issue with non-domain windows clients accessing domain servers.

 

[Samuel Tai]

What happens if you add Aux parameter map to guest = Bad User to the SMB service? (BTW, the default is now map to guest = Never.)

 

[Apollo]

I believe the issue is having Guest enabled on the share when Windows doesn't recognize the connection without a signed sertificate.
I think enabling the share to be user specific without group access will work. Otherwise there is a settings in Windows so it ignores untrusted shares.

 

[anodos]

SMB homes shares are a special type of share. The share path is dynamically generate ex: /mnt/tank/homes/%D/%U where %D is domain name and %U is username. The share name is also dynamically generated as both "HOMES" or "USERNAME" of currently authenticated user. It's impossible for "user1" to access the home share of "user2".