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

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

[shomeier]

Hey Heiko,

I totally agree with you about the advantages of an Adobe Drive like CMIS connector. It's a pitty Adobe does no more support it. From a technical perspective it looked awesome: Java side was OSGi based if I remember right and it was extensible with own menus and even a complete new connector.

Though they do no more support it I hope Adobe someday and somehow provides their solution.

Anyway maybe with the available frameworks today it might no more be that difficult to implement an own Adobe Drive like solution:

- The most advancing task in my eyes is the native layer. With Java Native Runtime and some open source libraries it looks like there is no need to do anything native by ourself: One could implement a CMIS FUSE Filesystem this way.

- The next important thing would be the context menus in Mac Finder/Windows Explorer:

   Liferay has build an awesome library which makes it possible to access the new FinderSync API via Java (called "liferay-nativity"). It provides implementations for Windows/Linux/Mac

Though there are for sure many other obstacles to overcome I think these two were the hardest. I could build a first runnable quick-and-dirty solution on Mac which mounts the Alfresco CMIS repository into a folder (lists folders, reads/opens files, lists versions in a context menu) in just some days (and I am a very slow programmer  ).

And I saw another (experimental) implementation for Windows (leveraging Dokan) on Github.

Maybe this could be done in a community effort together with Alfresco?

[heiko_robert]

Hi Sascha (I suppose you're shomeier@github),

your project sounds very cool and you should join with Alfresco Global Hackathon 😉

Unfotunately the dokan support in Windows is very limited and if you manage to setup a team you should take an eye on capsulate the required services and layers to get your work reusable and flexible. A colleague already created a proof of concept on linux 4 years ago (with no CMIS in mind): GitHub - LotharMaerkle/alffs: A FUSE filesystem for the Alfresco DMS repository server. Maybe you can get some insides from this code?

Personally I would prefer not to use CMIS if your intention is not really to have a connector for CMIS since it is more expensive (server load and implementation efforts) and unflexible. Instead I would prefer a custom REST-API focused on this use case.

Another point is that a DMS paradigm will never be fully compatible with a filesystem connector since any temporary files, deletes and recreates shouln't be seen on the Alfresco side. A separate project and/or Alfresco should take care about this with a separate layer which translates real, local OS operations into alfresco repo requests. Learned from the Alfresco CIFS shuffle code nightmare I think this should be moved on the client side but if you want to get more control over events like "when file is closed" fuse may be the wrong layer for that.

Good luck and keep us informed!

[afaust]

You can also find details about the Global, Virtual Hack-a-thon in this platform, e.g. projects and teams, as well as general information. (The page linked by Heiko also provides a link back to this platform)

[shomeier]

Hey Heiko, Axel,

yes it is that github repo. Sry I forgot to include a link (or maybe I just thought it is not worth to mention because actually the tough work is already done by the libraries "javafs" and "liferay-nativity". I just wired these libs together  ).

The Hackathon sounds great but it is already next Friday. With my current projects I'm afraid it is too tight for me to get some free time.

I never tried on Windows myself. I just noticed that Dokan seems to have somehow revived in 2016.

I actually hoped I never have to dig into these deep layers with C but if so the code from Lothar Maerkle seems for sure helpful.

To be honest the idea actually was to implement a CMIS Connector but the topmost layer allows to mount any type of Filesystem: Any implementation of the interface java.nio.file.FileSystem can be mounted (as a reference I always use the Google InMemory Filesystem implementation for testing/developing). I really loved this concept in Adobe Drive.

So an implementation which triggers an own proprietary REST-API might also be possible (though, even on Java-Side it is still not a piece of cake imho).

With CMIS also many other parties could benefit. I am trying to reduce the server load by requesting only minimal information (filter attributes, not including relationships if not needed etc). Also I am experimenting with some client side caching.

I am not yet sure about what kind of problems might arise when implementing a writing capability (currently I mount a ReadOnly FS). Are you talking about some kind of "staging" layer like in git clients: "Pushing" to the server should only happen on manual user action? Hmmm...this actually might make sense if a user is working on a file/object which has references to other files/objects. A user might want to push all these edits in a single transaction.

[vincent-kali]

Hi all,

We're working on an AOS drive for Windows (based on WinFSP, much like Dokany) thats is supposed to be an alternative to SMB for Windows clients. As AOS is NOT based on JLAN server, we expect much better performances.

Suggestion or contribution are welcome:

https://github.com/FrKaram/KS2.Drive

[resplin]

I wrote a blog post describing the additional analysis and research we did, and our current roadmap for this feature:

https://community.alfresco.com/community/ecm/blog/2017/11/03/moving-from-smb-to-webdav?sr=search&sea...‌

I'm interested to get your feedback.

[tommygonk]

For a solution see the fileServersNG replacement file servers subsystem for Alfresco that includes SMB2/SMB3 support with the Enterprise version - http://www.filesys.org

[lascaux]

interesting but not available with the community edition ?