A First Look at the New CIFS Driver

Samba is a file and print server that runs under Linux and other Unix-like operating systems. Samba is an implementation of the Server Message Block (SMB) protocol, also known as the Common Internet File System (CIFS), which is a popular file- and printer-sharing protocol on Windows.

Samba is a file and print server that runs under Linux and other Unix-like operating systems. Samba is an implementation of the Server Message Block (SMB) protocol, also known as the Common Internet File System (CIFS), which is a popular file- and printer-sharing protocol on Windows.

Linux has long provided SMB/CIFS client support via the smbmount command and the smbfs filesystem driver, but this support has had problems: you must assign ownership and permissions to all files at mount time, links aren’t supported, and special file types aren’t supported. These problems have limited the use of SMB/CIFS in Linux-to-Linux file sharing scenarios. Instead, the Network File System (NFS) or other protocols have been the preferred protocols for this function.

This situation is changing, though. Samba 3.0 adds a new feature, Unix extensions, that adds support for Unix filesystem features to the SMB/CIFS protocol, and the 2.6-series Linux kernel provides client-side support for these features in the form of a new filesystem driver known as cifs. Using these tools, you can gain access to many Unix filesystem features that would have otherwise been lost using the older smbfs mount code or the smbmount command.

To be sure, this support is not yet perfect. Some filesystem features don’t yet work quite correctly and the driver is less reliable than the older smbfs driver. Nonetheless, you may want to investigate using the cifs driver as a means of reducing the server count on your network. As time goes by, support for Unix extensions is likely to improve, and these features may become a practical replacement for NFS on mainstream servers.

SMB/CIFS Features in a Linux World

Linux clients have long been able to mount SMB/CIFS shares, using either the smbmount command or the smbfs filesystem type code along with the mount command. Such mounts have had limitations similar to those associated with mounts of VFAT filesystems, though:

* FILE OWNERSHIP. Because traditional SMB/CIFS doesn’t support file ownership as Unix and Linux systems use it, you must assign ownership of all files to a single user at mount time. Worse, ownership of files cannot be changed except by remounting the share. Similar issues apply to group ownership.

* FILE PERMISSIONS. Traditional SMB/CIFS doesn’t support file permissions. As with file ownership, you must specify a permissions mode to be assigned to all files. This feature makes it difficult to control access to files on a file-by-file basis. Also, either all files are executable or none are. SMB/CIFS does support a read-only bit that can be used as a stand-in for the write permission bit, but SMB/ CIFS provides only one such bit, so you must rely on mount options to distinguish between owner, group, and world write permissions.

* LINKS. Traditional SMB/CIFS doesn’t support either symbolic or hard links. Samba provides features that can control how symbolic links are presented to clients, but if you want to create or manipulate links using a Linux client, you’re out of luck.

* OTHER SPECIAL FILE TYPES. Traditional SMB/CIFS doesn’t support special file types, such as device files and pipes. This limitation doesn’t usually pose major problems, but on rare occasions, you might need such features.

These limitations restrict the utility of older clients: if you require any of these features, your only choice has traditionally been to use NFS or some other Unix-centric file sharing protocol.

The latest additions to Samba and the Linux kernel overcome these problems, at least in part, by implementing Unix extensions to SMB/CIFS. Samba 3.0 supports these features when you add a single global parameter, as described shortly. On the client side, you must use a new filesystem driver, cifs. This driver works with recent SMB/CIFS servers, but it won’t work with older servers, such as those provided with Windows 95, Windows 98, or Windows Me. Thus, if you need to mount shares from such a system, you’ll need to stick with smbmount or the smbfs driver. You can use the new cifs driver with Windows NT, Windows 200x, and Windows XP servers, but you won’t gain the benefits of better Unix filesystem feature support. In short, the Unix extensions support is useful primarily when connecting to a Samba server, although in theory other servers may support these extensions.

Activating Samba’s Unix Extensions

The easy part of the process is to activate the Unix extensions on your Samba server. First, you must ensure that you’re running a Samba 3.0-series or later server. (At press time, the latest version is 3.0.2a.) If you’re still running an older server, look for a new version for your distribution or download a new version from the main Samba site at http://www.samba.org.

Once a Samba 3.0-series server is running, add the following parameter to the [global] section of the smb.conf file on the server:

unix extensions = Yes

The default for this parameter is No, so you must change the default to use the extra features. The Unix extensions are implemented in such a way that they should cause no problems for Windows or other non-Linux clients, so enabling them is safe.

After making these changes, wait a minute or so for Samba to re-read its configuration file, or reload or restart the server, if you’re impatient. You should then be able to use a Linux client to access the Unix extensions on the server. However, configuring the client is a bit more involved than configuring the server.

Preparing a Linux Client

The Linux cifs driver is headquartered at http://us1.samba.org/samba/Linux_CIFS_client.html, but it’s been incorporated into 2.6-series kernels. If you’re using such a kernel, the cifs driver may already be compiled as a module or in the kernel proper. If you’re using a 2.4-series kernel, you can patch it to support the cifs module, but some of the details of mounting shares differs in this case. Consult the cifs documentation for details.

If you need to recompile your kernel to add cifs support, you can find the relevant option in the Network File Systems area. The option is called CIFS Support, and it’s marked as being experimental. Thus, you’ll also need to set the Prompt for Development and/or Incomplete Code/Drivers option in the Code Maturity Level area to select the cifs option. You can compile the support either as a module or directly into the kernel.

Because the cifs driver is so new, you may want to consider downloading the code from the cifs web site, even if you’re using the latest 2.6-series kernel. For instance, as Linux Magazine goes to press, the latest Linux kernel is 2.6.2. It ships with cifs version 0.94; however, version 1.02 is available from the cifs web site. For this article, the 1.02 cifs driver was used, installed in a 2.6.2 kernel source tree. (To integrate the code releases, delete or move the fs/cifs directory and replace it with the like-named directory obtained from the cifs Web site.)

In addition to installing the kernel or cifs module, you may also want to install a helper application known as mount.cifs. You can obtain precompiled binaries from the cifs web site, or you can compile it from the Samba source code. Type gcc -o mount.cifs mount.cifs.c in the source/client subdirectory of your Samba tree to do the job. In either case, you should copy the mount.cifs file to the /sbin directory (or copy the file elsewhere and create a symbolic link in /sbin). If you don’t install the helper program, you must use the server’s IP address rather than its hostname when mounting the share.

Mounting Filesystems with cifs

Under the 2.6-series kernels, the cifs driver uses syntax and options similar to the smbfs driver. Specifically, a minimal mount can be accomplished using a command such as this:

# mount -t cifs //server/share
/mnt/theshare -o username=fred

This command mounts the share called share from the server called server, using the mount point /mnt/theshare and the username fred. After you type this command as root, the system should prompt you for a password. If you enter it correctly, the share should become available at /mnt/theshare.

Unlike smbmount and the smbfs driver, the cifs driver requires a DNS hostname or IP address as its server identifier; you can’t use a NetBIOS name. Like smbfs, the cifs driver accepts several options after the -o parameter. In addition to the username option, you may want to set some others:

* password=pw. You can specify a password on the command line or as an option in the /etc/passwd file. However, a better option from a security perspective is to use the credentials option described next.

* credentials=file. In theory, you can pass a username and password in a file and give the filename to mount. The file contains a line reading username = user and another line reading password = pass. (This option doesn’t appear to work correctly as of the 1.02 version of the cifs code, though.)

* uid=value. This option sets the UID that’s to own files. This option is most useful for Windows NT/200x/XP or other servers that don’t support the Unix extensions.

* gid=value. This option works like the uid option, but it sets the GID.

* fmask=mode. You can set the default permissions mode for files on the remote server using this option. As with uid and gid, this option is most useful for servers that don’t support the Unix extensions.

* dmask=mode. This option works just like fmask, but it sets permissions for directories rather than ordinary files.

The cifs driver supports a few additional options. Consult the mount.cifs man page for more details.

Many of these options are useful only for non-Samba servers (or for Samba servers on which unix extensions is set to No).

You may encounter some quirks when mounting filesystems using the cifs driver. Most importantly and as already noted, this driver doesn’t support older servers, such as those that ship with Windows 9x/Me. You may also encounter authentication problems.

For instance, the security = Server option has problems on the server, although security = User works fine. The credentials option, although documented, doesn’t work. If you receive a message to the effect that the block device //server/share can’t be mounted, check the location of your mount.cifs helper program, or substitute the server’s IP address for the server name. This error is caused by a missing helper program.

Some of these problems should be fixed in the future, but others (such as the lack of support for older servers) may never change. If you need to mount shares from both Samba servers and older servers, you can use the cifs driver for the Samba servers and the smbfs driver for the older servers. Happily, the two can coexist on a single client.

Using cifs Features

As a first approximation, using a cifs mount from a Samba server with unix extensions = Yes should work much like using an NFS mount. A few features don’t yet work quite as you might expect, but the situation is improving with each new release.

The cifs driver and Unix extensions support UIDs and GIDs much as NFS does. The server identifies files as being owned by particular UIDs and GIDs, and these numbers are translated back to usernames and group names by the client’s own /etc/ passwd and /etc/group files (or equivalent).

Users can change the group of their files, but file creation is peculiar: users may be able to create files in directories they don’t own, and ownership of all new files is granted to the user whose account was used to log into the server. Read access to files depends upon a mixture of the Unix extensions permissions and the normal Samba access control mechanisms.

Overall, you probably shouldn’t try to use cifs and the Unix extensions to provide multiple users on a single server with full read/write access to a share and expect to preserve the client’s Unix ownership in the way NFS would. You can still share a directory to multiple clients with individual users mounting it, though.

Permissions modes work as you’d expect. Existing modes are passed to the client, and users can change the modes of their files with chmod or similar tools. There is one caveat: the Samba create mode and directory mode parameters can block creation of certain modes. For instance, if you’ve set create mode = 0644, you won’t be able to set group-or world-write access to the file, nor will you be able to set any execute permissions.

Links work, at least partially. You can follow existing symbolic or hard links within the share. If a symbolic link points outside of a share, it links to a file on the client. (This behavior is identical to Linux’s NFS implementation.) You can create hard or symbolic links within a single directory or to files in subdirectories within the share.

For instance, typing ln -s subdir/file.txt ./ will create the expected symbolic link. You can also create hard links from within a subdirectory to files in its parent directory. However, you cannot do the same with symbolic links, that is ln -s ../file.txt ./ won’t work.

Special files, such as device files and pipes, are presented to the client as they are. Creating such files doesn’t always work, though.

Samba + cifs = Good

Overall, the current Samba Unix extensions and 2.6-series kernel cifs implementation represent a good start on the way to providing Unix-style filesystem features via Samba. For some purposes, the current support may even be enough to ditch an NFS server.

However, the current system has some serious limitations. The most important of these is that SMB/CIFS was designed to enable users to mount and access file shares, whereas NFS was designed to enable client computers to do so. This distinction is important in handling ownership and permissions. It means that you may not get satisfactory results when mounting a shared-file directory via cifs if you want the file ownership and permissions on such a share to take precedence over Samba’s usual security features. The cifs support for changing permissions may be helpful, though, and the support for links (particularly hard links) may provide real benefits in some environments.

The current implementation is still quite new, and improvements are likely to arrive in the future. Thus, the cifs implementation is well worth watching if you need Unix-style filesystem features, but prefer using Samba to NFS on the server.

Roderick W. Smith is the author or co-author of twelve books, including Linux Power Tools and the upcoming Definitive Guide to Samba 3. He can be reached at rodsmith@rodsbooks.com.

Comments are closed.