Project
Requirements Specification
A CIFS Client on Solaris
Robert Thurlow
@(#)cifs_client_prd.html 1.3 06/06/15
The CIFS protocol (a.k.a. SMB) is the natural file sharing protocol on Microsoft Windows machines, and is implemented by Samba on Unix/Linux. This project will deliver a standard Solaris virtual file system which implements a CIFS client, providing access to files and directories on CIFS servers. Using the CIFS client, users can mount remote CIFS server shares (directories) on their Solaris system to get read-write access to previously inaccessible files. This project will not deliver the ability to print via CIFS or the ability to use CIFS resources other than files and directories.
Solaris is deployed in heterogeneous environments which requires it to access files on Non-Solaris servers. Users/Applications who need to access the files and directories from a CIFS server will be the primary beneficiaries of this product. Internally, Sun Ray and JDS teams are the primary requesters.
We must pass interoperability tests (to be defined during test plan development) with the following predominant CIFS-capable servers: Samba on Solaris, Sun's 5310 NAS system, Windows 2003 Server, Windows XP Pro. Samba and Sun's 5310 are chosen because we believe they will be the most prevalent CIFS servers used by customers who use Solaris, while Windows 2003 Server and Windows XP Pro are the most predominant CIFS servers in corporate networks. We should make best efforts to test at least minimally with the following servers: Windows 2000, PC Netlink, and NetApp. We believe that these are less important than the above server implementations.
The CIFS client's capabilities will be as follows:
- A standard Solaris loadable filesystem module must be provided
- A tool must be provided to list CIFS shares
- A tool must be provided to perform NetBIOS name resolution
- The standard Solaris mount utility must be able to mount CIFS shares
- It must be possible to add an entry to an automounter map to mount a CIFS share
- It must be possible to unmount a CIFS share, including by force ('umount -f')
- It must be possible to create and access a file larger than 2Gb on a server which supports the capability and the CIFS dialect
- The standard file utilities 'tar', 'cpio', 'cp' and 'mv' must be supported on CIFS files and directories, with expected failures for ACLs, extended attributes, hard links and symbolic links
- statvfs(2) must report used and free space on a CIFS share
- It must be possible to place byte-range locks on a file which are visible to other processes on the same client
- It should be possible to see correct file ownership with 'ls -l' with a correct configuration
- It must be possible to authenticate to a CIFS server with password-based authentication using NTLM style password hashing
- It should be possible to authenticate to a CIFS server without a password prompt by using credentials from a pre-existing Active Directory authentication
- Multiple CIFS sessions must be supported if more than one user is accessing the same CIFS share from the same client
System Adminstration Guide updates and man pages must be delivered with the CIFS client, and they must be sufficient for an unfamiliar user to view CIFS shares on the local network, to manually mount a CIFS share, and to add a direct automounter entry for a CIFS share. These docs should also give some background information about how CIFS works and what to expect in comparison to local file access.
A simple read-and-write throughput benchmark must show performance no worse than 50% of the performance measured on CIFS-on-Linux on the same hardware. If the performance is more than 20% worse, the team will deliver a mitigation plan to close the gap.
The following functionality will not be delivered by this project, but may be delivered by a future project.
- Browsing inside CIFS shares via Nautilus (this will be addressed by the Gnome team with our consultation)
- Full integration with the automounter (/net for CIFS)
- Oplocks (both shared and writer)
- ACL display and manipulation
- Packet signing (cryptographic integrity)
- CIFS Extensions for Unix
- Microsoft's DFS referrals
- Printing via CIFS
This project will introduce a new and foreign file access model to Solaris, and it will have the following impacts:
- Users will need new and adequate training and documentation resources
- Support and field personnel will need to become familiar with CIFS
Windows interoperability is a key strategic area of investment for Solaris and Sun, with the alliance between Sun and Microsoft. Customers are demanding this level of interoperability. Microsoft continues to develop its data technologies, and this work is one of the first steps to get in line with their efforts. This will be followed by additional investment in both Solaris client and server to interoperate with new technologies coming out of Microsoft (ex: Vista).
With the growing mixed configurations of Solaris/Windows servers and workstations in the customer environment, it is becoming more common for the users to deal with the Windows world. Other UNIX operating environments, such as Linux, HP-UX and the BSD releases, support client-side CIFS mounts. Sun is at a competitive disadvantage in a heterogeneous environment without this capability; even a limited capability to ease the pain would get us table stakes.
The Nautilus file browser in Gnome has the ability to browse CIFS shares; on Linux, it can mount the shares and continue browsing, but on Solaris it stops at the share level because of the missing kernel support.
A package called Sharity provides a crippled freeware or a more functional commercial CIFS client for Solaris implemented as a loopback NFS server, with performance and correctness issues forced by that implementation.
Sun Rays are aggressively being marketed as a PC replacement. Sun Ray servers must have client support to access Windows file shares in those environments where identity and file services are served through a Windows infrastructure. Specific and immediate Sun Ray business opportunities that exist in this market are:
Customers and potential desktop seats:
Western Australian Department of Consumer and
Employment protection 1,000
Ordnance Survey, UK 3,000
South Yorkshire Police 3,000
Toll group, Australia 5,000
NSW Roads and Traffic Authority, Australia: 6,000
TELUS 10,000
Accenture 20,000
Federal Gov't of Canada 40,000
Nortel 44,000This project has dependencies on the following projects:
- Sparks (Name Service Switch updates) - for our AD requirements
- Winchester (Active Directory interoperability) - for our AD requirements
- Kerberos Extensions for Interoperability – for our AD requirements
- Reno (Security ties for AD Integration) - for our AD requirements
We will also need to work with the Pebble Beach CIFS server team on items such as ID mapping and authentication.
The CIFS protocol is currently not licensed by Sun. Assumption is that the protocol will be reverse engineered where necessary, and that other reverse engineering efforts and licensed technologies that Sun has the IP rights to will be leveraged.
Version 1.2 – Sent for review Dec. 1, 2005
Version 1.3 – Revised and clarified May 22, 2006
Version 1.4 – Revised and clarified May 30, 2006
Version 1.4.1 – Revised and clarified June 2, 2006
Version 1.5 – Revised with comments from June 6, 2006 requirements review
CIFS Central wiki
CIFS Client page