SMB2 / SMB3 server support

[yves_noirjean]

Greetings

Microsoft is soon disabling SMB1 in Windows (Microsoft to Disable SMBv1 in Windows Starting This Fall ).

In the light of that, does the Alfresco SMB/CIFS Server support SMB2 or SMB3? I'm especially interested in the Java based implementation which runs on non-Windows systems.

Thank you

Yves Noirjean

[afaust]

For quite a while now Community members have urged Alfresco to update its SMB implementation. The issue REPO-1393 was filed by product manager Richard Esplin‌ to track the requirement. But there is no indication that this is something that will get any sort of priority from Alfresco, e.g. from the strategic vision / product roadmap presentations we had at BeeCon. Also the argument may be that even when Microsoft disabled SMBv1 by default, it will always be just a registry setting to re-enable it.

[resplin · Accepted solution]

I saw that news over the weekend, and we have been discussing it is a team.

CIFS is a specific dialect of SMBv1, and so is likely to stop working when Microsoft disables their client support for it. Our implementation of CIFS is vulnerable to many of the security problems mentioned in the Microsoft blog post, and so for some time we have recommended people use WebDAV in environments where those risks are considered unacceptable.

As Axel Faust‌ has pointed out, Alfresco has not invested in improving our SMB support since Alfresco version 4.0. That work was to improve the performance and stability of the current implementation, and we have not done the work to support newer versions of that protocol.

When we have looked at upgrading to a newer version of the SMB protocol, it is an expensive undertaking. We have instead directed our resources to other areas, such as improving WebDAV and the new SharePoint support in the AOS library.

The news from Microsoft has forced us to re-evaluate our position with SMB/CIFS. There are some new libraries we could leverage for this support, but integrating them would still be a big project. I wonder if it isn't better to end-of-life our CIFS support and recommend WebDAV for all use cases required mounting Alfresco as a shared drive.

Here is my analysis of WebDAV versus SMBv3.1.1:

• WebDAV is superior to modern versions of SMB when used for file access over a high-latency network. This is increasingly important as more deployments are in AWS or some other public cloud.
• WebDAV has worse performance than SMBv3.1.1 on a local network.
• WebDAV cannot handle transferring files larger than 4GB, so something like FTP would have to be used for those cases.

Am I missing anything?

Is anyone willing to share a use case shared drives where WebDAV would not be adequate?

[dhant]

Hello.

I apologize in advance if I am in something wrong. All statements are based on personal experience using WebDav.

At first glance, WebDav looks very attractive, but on closer inspection it turns out that this is not true.
The WebDav protocol has a number of drawbacks, compared to SMB:

1. Protocol overhead.
   WebDav is implemented over HTTP. This means that each WebDav command will be passed to the server in the form of an http request. Thus, an http header will be added to each WebDav command. As a result, there is a situation when you need to transfer 100 bytes of http-header to transfer 10 bytes of the file. Slowdown is especially noticeable when copying a large number of small files. For this reason, WebDav disks are not suitable for synchronizing a large number of files (this may be the logs of some programs). Even commercial implementations of WebDav, such as "Synology NAS", can not cope with this task. From what I conclude that this is a protocol defect that can not be circumvented or compensated.
   
2. WebDav clients have different protocol implementations.
   There is no strict compliance with the http://www.ietf.org/rfc/rfc4918.txt . Two WebDav clients can have great differences in the implementation of such things as: Preservation of cookies, sequence of execution of DAV commands, authorization method, supported encodings. Some WebDav clients may not support some of these features. I believe that support for the most common WebDav clients (built-in Windows client or davfs for Linux) is possible. For example, you can define the "dialect" of the WebDav client by the "User-Agent" line from the http-header. In this case, additional costs will be required to implement the "dialects" of the WebDav protocol for each specific client.
3. Weak support for the protocol on the part of Windows.
   The native Windows tools for connecting WebDav drives leave much to be desired:
   Restriction on the amount of data transferred - by default 50MB, through the registry can be increased to 4GB.
    
   Basic authorization is disabled by default. You can enable it through the Windows registry.
    
   The WebDav-drive is not connected directly as SMB, instead the "Webclient" service is used (based on a redirector kernel driver mrxdav.sys), which downloads the entire files to the temporary directory. Only after this, the file becomes readable/writable (The native NFS client works in a similar way). Even the cloud "OneDrive" is recommended to use through a special client, and not through WebDav.
    
   By default, only tls 1.0 is supported. (Actual for Windows 7, the state of the newer OS is not known).
   

[resplin]

Thank you for the analysis Dilan Hant‌. This is exactly the sort of information I was looking for. It will be interesting to see what others think about this topic.