![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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.
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 Resources for a link).
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.
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.
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
| Command | Effect |
|---|---|
? or
help | Displays a summary of commands |
cd | Changes to a new directory on the server |
del | Deletes a file |
dir or
ls | Shows the files in the current directory (or one you specify) |
exit or
quit | Terminates the session |
get | Transfers a file from the server to the client |
lcd | Changes the working directory on the local computer |
md or
mkdir | Creates a directory on the server |
mget | Transfers multiple files from the server to the client |
more | Displays a remote file using your local pager |
mput | Transfers multiple files from the client to the server |
put | Transfers a file from the client to the server |
rd or
rmdir | Deletes a directory |
rename | Renames a file on the server |
rm | Deletes 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.
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.
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 Password: |
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
| Option | Effect |
|---|---|
user=name or
username=name
| Specifies the user name to send to the server. |
password=pass | Specifies 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=filename | Specifies 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=UID | Sets the user ID (UID) of the user who is to own the files mounted from the share. |
gid=GID | Similar to the uid=UID option,
but affects the group ID (GID) rather than the UID. |
file_mode=mode | Sets the file mode (permissions), in numeric form, to be assigned to files from the server. |
dir_mode=mode | Similar to file_mode=mode, but
affects directories rather than files. |
guest | Prevents prompting for a password. This option typically works only if the share supports guest access. |
hard | If the server becomes inaccessible, processes that attempt to access files on the server will hang until the server returns. |
soft | If 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 |
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:
username=buuser password=Iw2bUmS[t |
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.
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.
Learn
- "Learn Linux, 302 (Mixed environment): Concepts" (developerWorks
February 2011) describes the basic principles of SMB and of CIFS.
- The Samba Wiki includes a page on the
CIFS UNIX extensions that provides technical details about these
features.
- At the LPIC
Program site, find detailed objectives, task lists, and sample
questions for the three levels of the LPI's Linux systems administration
certification. In particular, look at the LPI-302 detailed objectives and the tasks and sample questions.
- Review the entire LPI exam
prep series on developerWorks to learn Linux fundamentals and
prepare for systems administrator certification based on LPI exam
objectives prior to April 2009.
-
Exam Preparation Resources for Revised LPIC Exams provides a list
of other certification training resources maintained by LPI.
- In the developerWorks Linux zone, find hundreds of how-to articles and tutorials as well as downloads, discussion
forums, and a wealth of other resources for Linux developers and
administrators.
- Follow developerWorks on
Twitter, or subscribe to a feed of Linux tweets on developerWorks.
- Stay current with developerWorks technical events and webcasts focused on a variety
of IBM products and IT industry topics.
- Attend a free
developerWorks Live! briefing to get up to speed quickly on IBM
products and tools as well as IT industry trends.
- Watch developerWorks on-demand demos ranging from product installation
and setup demos for beginners to advanced functionality for experienced
developers.
Discuss
- Get involved in the My developerWorks
community. Connect with other developerWorks users while exploring
the developer-driven blogs, forums, groups, and wikis.
Roderick W. Smith is a consultant and author of over a dozen books on UNIX and Linux, including The Definitive Guide to Samba 3, Linux in a Windows World, and Linux Professional Institute Certification Study Guide. He is also the author of the GPT fdisk partitioning software. He currently resides in Woonsocket, Rhode Island.
