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]

Minor correction Richard: RFC-compliant WebDAV is not provided by JLAN. JLAN is only responsible for CIFS/SMB, FTP and NFS.

[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.

[vincent-kali]

Some remarks:

- We're using CIFS intensively on most of our alfresco deployments (in a pure collaboration context, smb is used on local lan, and share interface is used remotely).

- SMB is preferred to WebDAV for performances, reliability and conflict management (in many scenarios it seems that webdav is not locking file when editing, as said above depending on webDAV client)

- SMB can be easily integrated into a DFS architecture which brings seamless file share solution and potentially High Availability.

- Alfresco is one of the rare ECM solution that is providing SMB support, and we love it !

Finally I do confirm that we love SMB support in Alfresco, and it would be a very bad news if this support was discontinued.

Vincent

[lascaux]

I confirm that we are also using intensively CIFS successfully. Most of our users have no clue about the backend system behind the share drive... they just use it as other shares on their explorer.

it's fast, eays and meanful !

Losing CIFS would be a big issue for us !

Sylvain

[heiko_robert]

Alfresco and CIFS/SMB are in a kind of love-hate relationship. At least speaking for our customers: 20 of 30 companies have choosen for Alfresco because of the CIFS implementation. On the other hand it is one of a few root sources of trouble (beside transformer framework, search, versions, retrying transaction handler, ...).

WebDAV: One of our biggest customers (>800 concurrent active users with connected drive in windows) had to switch to WebDAV/AOS since Alfresco's CIFS implementation doesn't support terminal services / SMB block tagging on the same session. It is working somehow but not perfect. There are lot's of bugs, limitations in the Windows and/or Alfresco WebDAV implementation (limitation on path length, supported characters, locking, strange behavior on delete, ...)

To make the answer short: WebDAV may be an replacement if you can live with all the limitations but scales better with hundreds or thousands of users. You may miss the active part of CIFS which is notifying a client for updates (which would make the protocol unusable on Macs: no F5 reload)

But no big change without a big chance:

One of the biggest pitfalls users face with Alfresco is the synchronous implementation of the fileserver implementation which is NOT compatible with  the client OS concepts: client applications are used to delete and recreate files all the time, rename files before saving new versions etc. (well known from the shuffle mode concepts implemented in the fileserver / cifs implementation of Alfresco). I would vote for a new better implementation which works more like dropbox but in a manner of a connected drive: file actions are decoupled, recorded and consolidated based on some known events (e.g. on file close). In the mean time the file is saved on a local directory or on a server's temporary directory. We discussed this way internally years ago as an samba4 connector to replace Alfresco CIFS. This would be much more scalable and would additionally solve all the trouble outside of Alfresco. Alfresco should see only the real resulting new/changed document. Nothing else. Maybe we should start a fundraising now for this idea 😉

[resplin]

Thanks for sharing your experience and opinion. Internally, we have discussed whether the new (proprietary) Desktop Sync client isn't in fact a better way to go than the old-school Shared Drive concept.

It would be great to see someone implement a Samba 4 back-end for Alfresco proof-of-concept that we could use as a starting point for our efforts. Any volunteers?

[talwid]

Visuality Systems offers a commercial SMB stack that can be utilized here. The solution is portable and updated with the latests SMB3.1.1 dialect.

[afaust]

I bet as much as GPL3 is being marked as "nearly impossible to use" in the FAQ on their homepage, so could be the commercial license of NQE / NQ Storage for an open source product like Alfresco. On the other hand it would make it "easier" (argumentatively) for Alfresco to turn SMB support into an Enterprise-only, paid extension - which is what I gather so far might be the most likely of outcomes anyway...

[heiko_robert]

Besides the license discussion and which smb/cifs library to use I see a big challenge in separating alfresco jlan code from the desktop shuffle file / temp file mimic to support desktop apps behavior like ms-office or adobe apps with alfresco's node and metadata model. Today this is a huge unreadable bunch of code. With other words: where to plug in any other cifs library not to get all the problems again Alfresco had (and still has) in working on a mounted drive with desktop apps? Most dms vendors implement this kind of magic code on the client side but of course could be also implemented on server side if there's no client part.