The Common Internet File System (CIFS) also known as Server Message Block (SMB) is a network protocol whose most common use is sharing files on a LAN. The protocol allows a client to access servers, files and printers on the LAN as though they were on the local machine.
Microsoft uses CIFS in all flavours of Windows to provide its networking capabilities (i.e.: Shares, Network Neighbourhood). Unix/Linux also use CIFS via Samba, and Apple has several clients and servers available. Thus, it's a fairly interoperable protocol.
Side Note: (DEPRECATED ARTICLE)
JLAN and it's author have joined Alfresco. The full JLAN technology is available for OEM; a customised part is available as Open Source within Alfresco.
The rest of the article was written before this event (2005), so has the perspective of trying to implement CIFS in Alfresco with less knowledge.
CIFS has a client and a server part. The server is probably more applicable to us as we could expose the repository as a CIFS server. This would theoretically mean that the repository would show up in the Network Neighbourhood and users would be able to map the repository as a normal Windows drive letter.
The client capabilities may also be useful as we could import content from an existing network share, for example.
There is an open source implementation of a CIFS client called jCIFS.
The client library provides programmatic access to CIFS servers allowing the following:
- Domains and workgroups
- Servers within a domain/workgroup
- Shares available on a server i.e. folders, printers
- Files and folders within a share
- File/Folder Manipulation (with appropriate authentication)
- Create files/folders
- Read/Write files
- Delete files/folders
- Test for existence
- Retrieve properties
In order to access network resources you obviously need to supply login credentials.
These are provided in the URL you use to access the resource, for example:
The credentials can also be provided via the "jcifs.smb.client.username" and "jcifs.smb.client.password" properties. In turn there are several ways these can be provided to the client i.e. from command line, properties file etc.
However, it doesn't appear that these can be transparently picked up from the local machine i.e. single sign-on. In order to do that we would need to run from within a browser. We could then make use of the NTLM authentication filter jCIFS provides to source the credentials via the browsers challenge/response mechanism (although this would probably be IE only).
As mentioned above it makes more sense for us to try and provide a CIFS server interface to the repository. This means the repository can become accessible via Windows Network Neighbourhood and as a shared network drive.
JLAN Server is a commercial product that provides a Java based CIFS/SMB server. It fronts a virtual file system that can be mapped to a physical file system, a database or any other type of content repository. The easiest route for us to take would be to provide a JLAN virtual file system implementation of our repository API, however, as mentioned above it is a commercial product and therefore not distributable in an open source project.
An attempt to decompile the downloadable demo was unsuccessful. It appears they have obfuscated the code supplied in the JAR files, so most of the classes and their contained methods are reduced to a, b, c, d etc. Furthermore, most those classes with meaningful names fail to decompile!
Using the downloaded demo I was able to setup a CIFS server that was accessible across our ALFRESCO domain. I used the JavaFileDiskDriver virtual file system to point to a local folder on my machine. I was then able to browse the share via Network Neighbourhood and as you would expect to map a drive letter to the share. Derek was also able to browse the network and read the contents of my fake repository via Network Neighbourhood. Although I was using a JLAN class to provide the file system it would be fairly easy to replace this with an implementation that used our sevice APIs.
Setting up the server however revealed how much of a mammoth task it will be to provide our own CIFS server. I know we wouldn't need quite as much support as JLAN has but the installation guide has 30+ pages of configuration options! It's also evident seeing the debugging statements coming from the server that a great deal of networking knowledge (NETBIOS) is going to be required to implement anything useful, something I certainly don't have!!
1. On windows server, make sure that the machine name is not longer than 15 characters.
2. Before starting the alfresco server, run this command netstat -an
3. Check for an entry of 0.0.0.0:445. If port 445 is in use then disable the local SMB service
4. Disable Native SMB collisions Native SMB can be disabled by adding the following registry key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters] "SMBDeviceEnabled"=dword:00000000
A reboot is required after creating this key. Setting the value to one or deleting the registry key will restore native SMB support.
In Windows 2000,2003,2008 - Port 445 is bound by default to \device\ - all devices. Use the following registry key to unbind port 445 and allow for binding by Alfresco: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters]
5. Run nbtstat -a ALFRESCO_SERVER_IP
6. Now map the drive net use X: \\SERVER_NAMEa\Alfresco\SPACE_NAME /user:USERNAME //persistent:yes USERNAME is Alfresco user name
JLAN Server has 2 built-in authentication approaches, one is handled by JLAN itself and the other is a pass through authenticator allowing a domain controller to be used to authenticate clients.
I excercised both these approaches above. The local authentication specified users in the config file. Using this scheme I was presented with a login dialog to gain access to the test share I created. Once I switched to using the pass through authentication my network credentials were used to give me access to the share with no logon required.
JLAN Server's code was not available so I can't comment on it's quality or complexity but if the jCIFS code is anything to go by it will be horrendous in terms of complexity. It's obvious that to implement this stuff you will have to have intimate knowledge of the contents of each packet (to the byte level) that makes up a request to make anything useful happen!
I've had to learn a fair bit just to get this far in the investigation and I've only scraped the surface. Given that and how much code there is to produce (CIFS has over 100 commands detailed in a 155 page spec), to implement this ourselves will take way more than the 2 and a half months we have left!