Learn Linux, 302 (Mixed environments)

CIFS integration

Using Linux as a client to SMB/CIFS servers

Content series:

This content is part # of # in the series: Learn Linux, 302 (Mixed environments)

Stay tuned for additional content in this series.

This content is part of the series:Learn Linux, 302 (Mixed environments)

Stay tuned for additional content in this series.

In this article, learn about these concepts:

  • The Server Message Block (SMB) and Common Internet File System (CIFS) protocols
  • Features and benefits of using CIFS
  • Mounting CIFS shares on a Linux client

This article helps you prepare for Objective 314.1 in Topic 312 of the Linux Professional Institute's (LPI) Mixed Environment specialty exam (302). The objective has a weight of 3.


This article assumes that you have a working knowledge of Linux command-line functions and that you understand the basics of Samba configuration. You should be familiar with the overall structure of the smb.conf configuration file. You should also understand the basics of how Linux mounts local and remote file systems (using the mount command and /etc/fstab file). Familiarity with the standard Linux text-mode ftp command is helpful but not required.

Understanding SMB/CIFS

Before proceeding with a description of how to use Linux as a client to an SMB/CIFS server, it's helpful to review the characteristics of the protocols to see how they compare with Linux's needs for a file system. This comparison comes in two parts: an examination of the original SMB protocol and an investigation of the ways in which the newer CIFS extensions change the SMB basics. You may want to review the developerWorks article on LPI Objective 310.1, which introduces some of the basic concepts behind SMB/CIFS (see Related topics for a link).

Basic SMB features

SMB provides several unique features from a networking perspective, including its own naming system for computers (Network Basic Input/Output System [NetBIOS] names), workgroups, and user authentication protocols. For purposes of understanding how SMB and CIFS work as protocols for a Linux file-sharing client, the most important feature is the set of metadata that the protocol provides.

Metadata is data associated with, but not part of, a file. Examples include the file's timestamp, owner, permissions, and even its name. No doubt you're familiar with some of the common features of file metadata on Linux computers, and you may be familiar with some of the differences between Linux and other operating systems, such as Windows. Because SMB was designed for DOS, Windows, and IBM Operating System/2® (OS/2), it shares many of their metadata features. Most importantly, SMB lacks support for UNIX® and Linux metadata such as ownership, groups, and most permissions. SMB also lacks support for symbolic links and hard links as well as other special file types such as device nodes. SMB provides a few types of metadata that Linux doesn't normally understand, such as the hidden, archive, and system bits. You can map a Read-only bit to the Linux Write permission bit.

Another limit of SMB is its file-size limit of 2GiB. This limitation can obviously pose a problem in today's world of multi-gibibyte backup files, multimedia files, and so on.

To work around these SMB differences from Linux's file system expectations, Linux SMB clients must either ignore them or provide options to "fake" the data. These options are similar to those used when mounting NT file system (NTFS) or File Allocation Table (FAT) file systems on Linux. Fortunately, CIFS provides more and better options for handling some of these limitations.

You should be aware of the network ports that SMB uses, as well. These are User Datagram Protocol (UDP) ports 137 and 138 (for name resolution and datagram services) and TCP port 139 (for session services—in other words, most file transfers). You'll need this information if you ever have to debug SMB using low-level network diagnostic tools.

CIFS extensions to SMB

In the mid-1990s, Microsoft® decided to change SMB's name to CIFS and simultaneously added a new set of features. These features include support for symbolic and hard links and larger file sizes. CIFS also supports access to the server on port 445 in addition to the older port, 139.

At least as important as Microsoft's own extensions to SMB in CIFS are others' extensions. In particular, a set of CIFS features known as UNIX extensions provides support for file ownership, permissions, and some other UNIX-style metadata. If the client and server both support these features, you can make much more effective use of a CIFS server from Linux than you could a server that only supports SMB. As you might expect, Windows Server® operating systems don't support these extensions, so they're only useful when your Linux client connects to a Samba server. This server must also be configured with the following global option:

unix extensions = Yes

This option was set to No by default in Samba prior to version 3.0, but Samba 3.0 switched the default to Yes, so you may not need to explicitly set the option.

Using smbclient

In some respects, the simplest way to access an SMB/CIFS server from Linux is to use a text-mode utility known as smbclient. This program is similar to the classic ftp client program, so if you're familiar with ftp, you should have few problems with smbclient. If you're not familiar with ftp, the idea behind the program is to initiate a connection to the server that does not involve mounting shares in a traditional manner. Instead, you type commands to view, delete, download, or upload files.

To use smbclient, you type its name followed by a service name, which takes the form //SERVER/SERVICE, such as //TANGO/GORDON to access the GORDON share on the TANGO server. Depending on the server's configuration, you will probably be prompted for a password. If you enter it correctly, you are able to type various commands to access files on the server. Table 1 summarizes some of the more important smbclient commands; consult the utility's main page for information on more exotic commands.

Table 1: Important smbclient commands
? or helpDisplays a summary of commands
cdChanges to a new directory on the server
delDeletes a file
dir or lsShows the files in the current directory (or one you specify)
exit or quitTerminates the session
getTransfers a file from the server to the client
lcdChanges the working directory on the local computer
md or mkdirCreates a directory on the server
mgetTransfers multiple files from the server to the client
moreDisplays a remote file using your local pager
mputTransfers multiple files from the client to the server
putTransfers a file from the client to the server
rd or rmdirDeletes a directory
renameRenames a file on the server
rmDeletes one or more files on the server

By default, smbclient uses your current user name to connect to the server; however, you can change your user name with the -U option. In fact, several other command-line options are available, including options that make it possible to transfer files without entering smbclient's interactive mode. Therefore, you can use smbclient in scripts to perform automated file transfers. Consult the program's main page for details on this topic.

In use, an smbclient session is likely to resemble Listing 1.

Listing 1. Example smbclient session
$ smbclient //TANGO/GORDON/
Enter gordon's password: 
Domain=[RINGWORLD] OS=[Unix] Server=[Samba 3.4.12]
smb: \> cd mystuff
smb: \mystuff\> ls
  .                                   D        0  Mon May 16 19:20:08 2011
  ..                                  D        0  Mon May 16 19:18:12 2011
  xv-3.10a-1228.1.src.rpm                3441259  Tue May 18 19:09:26 2010
  License.txt                              27898  Mon May 16 19:17:15 2011
  xorg.conf                                 1210  Fri Jan 21 04:18:13 2011

		51198 blocks of size 2097152. 2666 blocks available
smb: \mystuff\> get xorg.conf
getting file \mystuff\xorg.conf of size 1210 as xorg.conf (9.4 KiloBytes/sec)
(average 9.4 KiloBytes/sec)
smb: \mystuff\> exit

Tip:smbclient makes an excellent debugging tool. It's simple and gives you the ability to access your network in a way other than mounting a share, which can be helpful if you're trying to debug a problem.

Mounting SMB/CIFS shares

Although smbclient is a useful tool, it doesn't give you the same sort of seamless access to the server that you're used to from Windows clients. If you need such access, you must use other tools to mount the SMB/CIFS shares. You can do this with the standard Linux mount command; or you can edit your /etc/fstab file to automatically mount SMB/CIFS shares when the computer boots.

Temporarily mounting shares

You can mount an SMB/CIFS share using the same mount command you use to mount local volumes or Network File System (NFS) exports. You can specify the file system type as cifs; or, in most cases, mount figures out to use this driver based on the syntax of the command. Alternatively, you can call the helper program mount.cifs directly. In principle, only the device specification is different from that for mounting a local file system; thus, to mount the GORDON share from the TANGO server, you could type, as root:

# mount //TANGO/GORDON /mnt

In practice, though, this usage has a problem: It passes root as the user name to the server. If the server doesn't permit root to log in, the mount attempt will fail. You can correct this problem by using the -o user=name option to pass a user name to the server:

# mount -o user=gordon //TANGO/GORDON /mnt

Several other mount options, passed with the -o option to mount, are available. Table 2 summaries the most useful of these options. Consult the mount.cifs main page for information on additional options.

Table 2: Important mount.cifs options
user=name or username=nameSpecifies the user name to send to the server.
password=passSpecifies the password to send to the server. If the password is not specified, mount.cifs uses the value of the PASSWD environment variable; if that's not set, the program prompts for the password.
credentials=filenameSpecifies a file that contains the user name, password, and, optionally, the workgroup name. Each value appears on its own line, preceded by the strings username=, password=, and workgroup=, respectively.
uid=UIDSets the user ID (UID) of the user who is to own the files mounted from the share.
gid=GIDSimilar to the uid=UID option, but affects the group ID (GID) rather than the UID.
file_mode=modeSets the file mode (permissions), in numeric form, to be assigned to files from the server.
dir_mode=modeSimilar to file_mode=mode, but affects directories rather than files.
guestPrevents prompting for a password. This option typically works only if the share supports guest access.
hardIf the server becomes inaccessible, processes that attempt to access files on the server will hang until the server returns.
softIf the server becomes inaccessible, processes that attempt to access files on the server will receive error messages. This is the default behavior.

The uid, gid, file_mode, and dir_mode options are usually unnecessary if you connect to a server that supports the CIFS UNIX extensions. You can use these features to override the values that the server provides in these cases, though. Note also that these options all affect the way the files appear on the client; permissions and ownership on the server are unaffected by these options.

With the SMB/CIFS share mounted, you can access it just as you would a local volume or an NFS volume. You can copy files with cp, delete files with rm, edit files directly with text editors or other programs, and so on. Keep in mind, though, that if the server doesn't support a feature, you might not be able to use it. For instance, you can't use chmod to change the mode of a file unless the server supports the UNIX extensions. (A partial exception in the case of chmod is that you can change Write permissions; these are mapped, in inverse fashion, to the SMB Read-only bit.)

When you're finished using a share, you can unmount it with the umount command, just as if it were a local file system:

# umount /mnt

Permanently mounting shares

If you want a computer to mount an SMB/CIFS share permanently, you can do so by adding an entry to /etc/fstab. This process works much like any other translation of a mount command to an /etc/fstab entry. However, one option from Table 2 deserves special mention in this context: credentials. Because most SMB/CIFS servers use passwords for authentication, you must permanently store the password if you expect a share to be mounted using /etc/fstab. Storing the password directly in /etc/fstab using the password option is possible, but inadvisable; because /etc/fstab must be readable by all the computer's users, a password stored in this way will also be readable by everyone. Using credentials enables you to store the password in a file that's readable only by root, thus improving password security.

A working /etc/password entry for an SMB/CIFS share might resemble the following:

//TANGO/BACKUPS  /saveit  cifs  credentials=/etc/samba/creds.txt  0 0

The associated credentials file might look like this:


Caution: Be sure to give the credentials file suitable permissions—normally 0600 or 0400 with ownership by root or by the user whose credentials are stored in the file.

With this configuration in place, the //TANGO/BACKUPS share should be mounted automatically whenever you reboot the computer or type mount -a. If this feature doesn't work, verify that the user name and password are correct, test with the mount command, and perform other routine troubleshooting procedures.

Moving forward

The next article in this series, "Learn Linux, 302 (Mixed environments): NetBIOS and WINS", covers name resolution using the Windows Internet Name Service (WINS) and browsing, which enables computers to locate network shares in a tree-like hierarchy of computers and shares.

Downloadable resources

Related topics

ArticleTitle=Learn Linux, 302 (Mixed environments): CIFS integration