SMB shares inaccessible on Windows 7 and 10

1st Official Post

    I love OMV, but I have consistently run in to an issue while using SMB shares with Windows 7 and 10. The issue is that the username and password prompt just constantly comes back despite proper credentials, and there is no way to access the shares. There are many many versions of windows 10 and 7 that default to Send LM & NTLM - NTLMv2 session if security is negotiated under local security policy > Network security: LAN Manager authentication level. When this is the case it does not negotiate the higher revision of the protocol. I find this issue is random on new installs and random old installations of windows.


    When this is set, there is no way to get to any shares. To make the shares work you have to set it to Send NTLMv2 response only. Initially I nearly got rid of OMV altogether, until I found a post on a different forum about this issue. Why is it that OMV requires NTLMv2 authentication. Is there anyway this could be changed to just work, or is there a setting I am missing?


    For anyone experiencing this issue, the fix is as follows


    Run local security policy

    click Local Policies

    Click Security Options

    FInd Network Security LAN Manager authentication level

    Change the option to Send NTLMv2 only.


    This has to be done per PC that experiences the issue


    Thanks

    So it looks like ntlm auth = ntlmv1-permitted can be added to extra options under SMB - CIFS settings. I am not certain that it is formatted correctly, but I am not getting an error in the log. I haven't tested to see if this will work either. I don't think this should need to be added for SMB shares to work consistently, or should at the very least be the default setting. Looks like I solved my own problem, hopefully this will be helpful to others experiencing similar issues.

    Quote from geaves

    Try adding ntlm auth = yes to extra options

    Thanks, looks like I got close. Again I would like to put forth that this is a large issue that is very difficult to diagnose. I fail to see what benefit this is to OMV. I am sure it hurts the adoption of the platform as a lot of people would never figure out the issue unless they liked digging through logs. It also appears to be extremely random on my end. Different releases of windows 10 alone are causing the issue. Why not allow most traffic, and allow admins to increase the security level?

    • Official Post

    It could be something like Win10 and 7 network settings where share access should be set for username and password. Unfortunately, you're probably dealing with OEM Windows installs, where the OEM tries to "help" end users with what they think are the best settings for security. That varies considerably.


    Maybe something in this Doc will help -> Win10

    • New

    Microsoft sunset NTLMv1 in Windows 11 (must use at least NTLMv2) for the workgroup authentication handshake. Microsoft as deprecated all development on NTLMv2 and strongly encourages using Kerberos for authentication (although I do not know how it works in a workgroup since it requires a Kerberos ticket-granting server). Microsoft's advice indicates NTLMv2 will also be dropped at a future date (Windows 12?). The Samba open source supports NTLMv1, NTLMv2, and Kerberos.


    Windows workgroup clients will need guidance to check the NEGOTIATE registry settings. These may be set incorrectly by OEMs or end-users causing puzzling OMV share authentication failures. I don't see this anywhere in the wiki.omv-extras.org, and this problem will only get worse as more Windows 11 and Windows 12 computers with secure default settings attempt to connect to OMV.


    Also, it would seem in order to stay relevant, OMV will need to pursue Kerberos development, perhaps incorporate a Kerberos server (Docker?) in the build, and meanwhile document the settings currently used to negotiate NTLM versions (for very old clients) or Kerberos. Kerberos was introduced in Windows with the 2000 server and client (that's also when Active Directory was released). I do not know what authentication fallback old Linux clients or old MacOS clients use or are able to support.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login