CIFS (Common Internet File System) is a protocol that gained popularity around the year 2000, as vendors worked to establish an Internet Protocol-based file-sharing protocol.
At its peak, CIFS was supported by operating systems (OSes) such as Windows, Linux and Unix. CIFS used the client-server programming model in which a client program makes a request of a server program -- usually in another computer -- to access a file or pass a message to a program that runs in the server computer. The server takes the requested action and returns a response.
CIFS is now considered obsolete, because most modern data storage systems use the more robust Server Message Block (SMB) 2.0 and 3.0 file-sharing protocols, which were major upgrades to CIFS.
CIFS vs. NFS
Developed by Sun Microsystems in the 1980s, NFS is now managed by the Internet Engineering Task Force (IETF). NFS was originally used more in Unix and Linux OSes, while CIFS and SMB were used for Windows, but most major NAS vendors now support both protocols.
NFS is a client-server application that permits transparent file sharing between servers, desktops, laptops and other devices. Using NFS, users can store, view and update files remotely as though they were on their own computer. With CIFS/SMB, a client program requests a file from a server program located on another computer, and the server responds. This makes CIFS a chattier protocol than NFS.
CIFS vs. SMB 2.0, 3.0
The SMB application-layer network protocol has been around since the 1980s. Developed at IBM, SMB allowed computers to read and write files over a local area network. Although CIFS and SMB are often used interchangeably, the CIFS protocol was introduced by Microsoft in early Windows OSes as an updated version of SMB.
CIFS used the internet's TCP/IP protocol and was viewed as a complement to existing internet application protocols, such as the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP). However, CIFS was considered a chatty protocol that was buggy and had issues with network latency. The protocol was also hard to maintain and not very secure because of the large number of commands and subcommands it processed. It was replaced when Microsoft introduced SMB in Windows 2000, Windows XP, Windows Server 2003 and Windows Server 2003 R2. Updated versions of the protocol were subsequently used in Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008.
SMB 2.0, introduced in the Windows OS in 2006, provided performance improvements over SMB 1.0 by reducing the number of commands and subcommands from more than 100 to 19. The 2.0 specification packs multiple actions into a single request -- to reduce the number of round-trip requests made between the client and server -- since the client may now cache all changes to the file before committing it to the server.
SMB 3.0 was introduced in Windows 8 and Windows Server 2012, and launched SMB Direct, SMB Multichannel and SMB Transport Failover. It also introduced better security mechanisms, such as end-to-end encryption and the Advanced Encryption Standard (AES) algorithm.
SMB 3.1.1, which became available in Windows 10 and Windows Server 2016, supports military-grade AES 128 GCM and AES 128 CCM encryption. It also uses the SHA-512 hash for preauthentication integrity checks.
The Samba project played a major role in making SMB compatible with Unix. Samba is a free software implementation of the CIFS/SMB networking protocols that supports Microsoft Windows Server Domain, Active Directory and Microsoft Windows NT domains. With Samba, Unix-like OSes can interoperate with Windows and provided file and print services to Windows clients.
CIFS Protocol Features
The CIFS protocol includes a number of features as documented by Microsoft. These features include:
- Transport Intelligence: Although the CIFS protocol is normally used over top of a connection-oriented protocol, it can also make use of a connectionless protocol.
- Flexible Connectivity: The CIFS protocol is extremely flexible with regard to client/server connectivity. A single client can connect to multiple servers, and can even make multiple connections to a single server if necessary.
- Feature Negotiation: The protocol's dialect and supported features are negotiated on a connection-by-connection basis.
- Resource Access: The CIFS protocol does not limit the types of resources that clients are able to connect to. CIFS clients are able to concurrently connect to shared files, named pipes, print queues and other resources.
- Security Context: The CIFS protocol does not limit the client to the use of a single security context. Multiple security contexts can be used over a connection if necessary.
- File Access: A CIFS client is able to interact with multiple files simultaneously. Additionally, file sharing is a function of the server operating system and CIFS does not impose file locks. This means that multiple clients can access a file simultaneously.
- Extended Sub Protocols: The CIFS protocol allows the use of sub protocols, which can be used to extend functionality.
- Named Pipe Interprocess Communication: CIFS allows named pipes to be used as a communication path between the client and the server.
- File and Record Locking and Safe Caching: Although the CIFS protocol allows multiple clients to simultaneously access a file, the protocol does support file and record locking, as well as file caching.
- File, Directory and Volume Attributes: The CIFS protocol is designed to recognize and respect attributes that have been assigned at the file, folder and volume levels. The protocol is also compatible with Windows Access Control Lists (ACL).
- File and Directory Change Notifications: The CIFS protocol includes a mechanism that allows clients to be notified when a change has been made to a shared resource. A Windows client that is accessing a shared folder through File Explorer for example, will generally display a current view of the shared folder's contents because of this feature.
- Batched Commands: The CIFS protocol allows messages to be linked together and processed in sequence.
- Support for the Distributed File System: The Windows Server operating system supports the use of a Distributed File System (DFS) which creates a global namespace that can include resources on multiple servers. The CIFS protocol fully supports the DFS feature.
- Remote Procedure Call Transport: The CIFS protocol supports the use of RPC protocols such as MS-RPCE and MS-RAP.
- Message Verification: Message signing can be used in conjunction with the CIFS protocol as a way of guaranteeing that messages have not been modified in transit.
- Unicode File Name Support: The CIFS protocol supports the ASCII character set and Unicode Legacy 8.3 filenames are supported, as are long file names.
Uses of CIFS
The CIFS protocol was the genesis for the current generation SMB protocol that is used for file sharing in Windows systems. SMB is widely used for accessing files and folders on Windows networks.
Although the CIFS protocol is probably most often associated with Microsoft, there are open source versions of the protocol available. CIFSD for example, is an open source CIFS/SMB protocol for Linux. Similarly, Samba -- the Windows interoperability suite for Linux and Unix -- includes an SMB/CIFS client. The CIFS/SMB protocol is also sometimes used to provide containers with connectivity to shared resources.
How Does CIFS Work?
When a CIFS client needs to communicate with a CIFS server, the action is almost always initiated at the application level. A user might, for example, open Windows File Explorer and attempt to access a shared folder.
The first step in accessing a shared resource is that the client establishes a NetBIOS session with the server (using a full duplex TCP session over port 139). CIFS messages can then be transmitted across this session.
With the NetBIOS session in place, the client and server perform a negotiation process in which they determine which dialect will be used. This negotiation process is initiated by the client by way of the SMB_COM_Negotiate command. This command effectively transmits to the server a list of the dialects that the client understands. The server responds with the dialect that it will be using. This dialect must be one that is supported by both the client and the server.
Once the client and server agree on a dialect, the client transmits authentication credentials (usually a username and password) to the server, and is furnished with a Unique Identifier (UID). When the client transmits its authentication credentials, it also sends a list of its capabilities. As such, this step is necessary even if the server does not require authentication.
On modern systems, the authentication process is generally handled by Active Directory. However, authentication is not a direct function of the CIFS protocol. As such, other authentication mechanisms, such as RADIUS, could also be used. It is worth noting that CIFS can also be used for file sharing in a workgroup environment. Since a workgroup lacks a centralized authentication mechanism, the authentication process would utilize local user accounts on the workgroup computers.
If the authentication is successful, the server returns the assigned UID to the client. Now, the client transmits the Universal Naming Convention (UNC) name of the share that it wishes to attach to. The server checks to make sure that the share name is valid and that the client has the required permissions. If these checks are successful, the client is granted access to the share, and can then begin requesting access to resources within the share, such as files and folders.
Downfalls of CIFS
Early on, Microsoft's CIFS proposal held great potential. With CIFS, Microsoft sought to create a standard version of SMB. Among its benefits was support for direct communications over TCP port 445, completely bypassing NetBIOS. In spite of this capability however, most CIFS clients and servers continued to be based on NetBIOS and LAN Manager (LanMan) authentication.
LAN Manager 1.0 was originally created to support various file system features and operating system functions within IBM's OS/2. Subsequent versions of LAN Manager supported DOS and Windows. The CIFS specification was based around the use of NT LAN Manager -- otherwise known as NTLM or NT LanMan 0.12.
Over time, CIFS became obsolete as Microsoft released newer versions of its SMB protocol, with SMB 3.0 being the current version.
How to Configure CIFS for Windows
The CIFS protocol is fully supported by Windows 10, but CIFS sharing is disabled by default (although Windows 10 is configured by default to act as a CIFS client). SMB is Microsoft's preferred file sharing protocol, and supersedes CIFS, so it is unlikely that most admins will need to fully enable the CIFS protocol. Even so, the protocol is available for use if needed. Here is how the configuration process works.
To enable the CIFS protocol, enter the Control command at the Windows Run prompt. This will cause Windows to open the Control Panel. Next, click on Programs, and then click on the Turn Windows Features On or Off link. This will cause Windows to display a dialog box within which features can be enabled or disabled by selecting the corresponding checkbox.
Scroll through the list of features until you locate SMB 1.0/CIFS File Sharing Support. By default, Windows 10 is configured to act as a CIFS client, but not as a CIFS server. Hence, some CIFS components are enabled by default. To fully enable CIFS, expand the SMB 1.0/CIFS File Sharing Support container and then select the SMB 1.0/CIFS Server checkbox. The other SMB 1.0/CIFS checkboxes (Automatic Removal and Client) should be selected by default. Click OK to install the feature.
In Windows 10, no additional CIFS configuration is necessary. Sharing a folder across a network works the same way, regardless if SMB or CIFS is being used. Right click on the folder that is to be shared and select the Properties command from the shortcut menu. This will cause Windows to display the folder's properties dialog box. Select the dialog box's Sharing tab and click the Share button. Select the users with whom you wish to share the folder and adjust their permissions as necessary. If the folder needs to be shared among additional users, click the Add button and then enter the name of the user or group with whom the folder should be shared. When you are done configuring the folder's users and permissions, click the Share button, followed by the Close button.