SMB2 / SMB3 server support

[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

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

The AOS endpoint is the recommended WebDAV endpoint on Windows systems, and should be more reliable on Windows than the generic WebDAV endpoint. It is a distinct implementation of WebDAV than the generic WebDAV that is provided by JLAN. But as Axel mentioned, it isn't standards compliant and so we are hesitant to recommend it for use on other systems. See:

Troubleshooting WebDAV | Alfresco Documentation 

[afaust]

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

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

[heiko_robert]

For my personal opinion the new or old Desktop Sync does only address the road warrior requirements but not the office or remote power user: You always want to see all files without the need to replicate the whole enterprise on your desktop. Not to mention the requirement that you want to see edit metadata, call actions, etc.

What about referenced files like images embedded in a page or machine parts in a CAD file? This will never be handled by pure sync concept.

The closest solution / proof-of-concept I've seen was from a company located in Australia (I need to search in my brain to remember the name Edit: found it but unfortunatly the company seems to be dead: eoss-edrive | SourceForge.net ): They implemented an asynchronous, multicast capable alfresco file protocol service to be installed in two flavors: client runs on a client and/or on a (local) fileserver. The smart stuff was that they mixed dropbox and fileserver concepts:

• In case someone "opens" the file for edit a lock token will send to the network (multicast) and/or to the server
• If node is in the local cache the file will be openend from there otherwise from the server
• every change on the file will be saved in the local cache only
• in case the file change is final (e.g. the OS lock has been releases) the changes will be put on the network using broadcast in a secure way (similar to dropbox) and send asynchronously to the server
• every client supporting the protocol will receive the change notifications and may get the updated bytes from the broadcast in the internal network - maybe without any interaction with Alfresco (I have seen this only from dropbox before)

Another also good approach: The CMIS-OS network drive connector (Adobe Drive) Thomas DeMeo and his team developed for the creative suite when he was product manager at Adobe:

• locally seen as drive (OS part in C and SDK in Java)
• content is only catched from the server when it is required so the drive acts similar to a browser (I'm unsure how the directory structure, metadata is saved/cached)
• any temporary / not final IO (temp files , file shuffling new, locked files) will not be send to CMIS server
• content will be cached locally and will be kept. This makes the implementation very fast for the user perspective because the OS works on a local file.
• drive has concept / java API for context actions, sync, properties, extendable document property sheets, previews, ...

Adobe may not have the Marketing / customers / use cases to put this solution into the mass market. Maybe there is a chance you can get / acquire / license this solution before it is dying?

The samba4 binding would be a very scalable solution to be implemented in C and would be limited to linux platform (btw much better platform for Alfresco ...)

[bgewehr]

We tried a lot of solutions for enterprise content creation management. The need is not sufficiently fulfilled by oneDrive, box, dropbox or any other desktop sync tool. The need is to work together on thousands of files, not to take some of them with me. That's why the promising Alfresco approach of a single federated repository in a multisite enterprise scenario that delivers a simple network drive experience with a modern and social network styled web UI for search, collaborating and sharing was such a brilliant idea for our daily business. CIFS/SMB is key to that use case.

[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

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