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.

[julian_cervino]

In my experience CIFS is not a reliable protocol to use with Alfresco. Beside the complexity to clusterize that kind of access, we have found a lot of unexpected errors and performance overhead.

We have configured and recommended a solution for enterprise customers using a Linux box as a proxy. The Linux Box exposes folders using SMB to clients and mounts, using webdav, a shared folder in Alfresco. I know this pattern is not always applicable (because permission/user concerns) but it seems to work fine in our most common case (scaner devices linked to Alfresco).

We are studying right now with one of our customers the possibility of replacing the Linux box with a Windows Storage Server. This way we would have high-availability from end to end (right now the Linux box is a single point of failure).

My two cents.

[afaust]

I would assume a "dummy" proxy like you have described for your canner device use case would be unacceptable in almost all but the rarest use cases.

SMB 3.0 has a feature called transparent failover which would make SMB usable for clusterised Alfresco systems. The availability of such features in more modern version of the protocol is why some people in the community had already urged Alfresco to consider an update.

One option that was discussed in the IRC #alfresco channel was the potential option of using Samba and a Virtual File System backend to expose Alfresco without Alfresco having to deal with the intricacies of SMB themself and relying on a proven, continuously maintained industry solution.

[iblanco]

Although I quite agree with Julián I do even agree more with Dilan Hant.

Not being a fan of SMB protocol at all when I started working with Alfresco around 10 years ago I was very enthusiastic about the option of using webdav and forgetting about SMB.

But reality did bite me. As Dilan said each webdav client had a completely different behaviour. What worked right with davfs did not work on MacOS or with any other Linux implementation and viceversa. In the Windows scenario it was even worse, not only did the version of windows change the Webdav client that internally was used but installing Office might change the client.

In that sense the CIFS client in the windows machines was much less problematic. So usually my recomendation is:

- Use Share for your day to day work

- Use CIFS if you want to acces the files in a "file system" way.

- Use FTP for uploading batches of files (or the Bulk Import Tool if we are talking about really big loads)

The situation with the Webdav protocol might have improved during this years but it should be thoroughly rechecked before assuming that it is a good alternative to CIFS.

Richard, what about AOS? If I'm not getting it wrong I think that the "Sharepoint protocol" that AOS implements is really a derivative/modification/implementation of Webdav. Am I right ?

If so maybe this has the advantage of being more specific, is an specific implementation that works with an specific client so there is less variability and it might just work. Does this implementation somehow improve any of Dilan Hant's worries?

Anyone with better knowledge about AOS can comment on this?

[iblanco]

By the way, are Linux webdav clients able to connect to the AOS's "webdav"-ish endpoint?

[afaust]

The AOS "webdav" is providing a Microsoft-corrupted variant of WebDAV and is not fully RFC-compliant. It will likely work with clients other than WIndows / Office, but there is no guarantee that weird stuff won't happen if you use it on non-Windows systems.