Running Linux, 5th Edition (2009)
Part II. System Administration
Chapter 15. File Sharing
In this chapter we give you a quick guide to the two major ways in the Linux world to share resources between systems. First we cover Samba, which uses Microsoft Windows networking protocols to allow users on one system to read and write files on another system, and to send jobs to printers on remote systems. The advantage of using Samba is that Linux and Unix can be integrated almost seamlessly with Microsoft systems, both clients and servers. The Microsoft Windows networking protocols can be used for sharing of files between Linux systems, although the preferred protocol for that really is the NFS protocol.
We present both NFS and NIS, protocols developed by Sun Microsystems and used by Unix systems for decades. NFS, the Network File System, allows systems to share files between Linux and Unix systems in a manner similar to Samba. NIS, the Network Information System, allows user information to be stored in one place and accessed by multiple systems so you don't have to update all the systems when a user or password changes. Although NIS is not a tool for file and printer sharing, we present it in this chapter because it shares some components with its cousin NFS, and because it can make NFS easier to administer because NIS allows each user to have the same account number on all systems.
NFS and NIS are useful at sites where only Linux and variants of Unix are connected. Versions have been created for Microsoft systems, but they are not particularly robust and have never become popular.
Microsoft provides a complimentary NFS client and server implementation for Windows systems that has not been adopted into common use despite it being free of cost. The Microsoft Windows Services for Unix (SFU ) package includes an NIS server and over 300 Unix utilities for use under Windows. Even given this free availability Windows sites that wish to secure interoperability between Windows network clients and Linux systems prefer the use of Samba.
In addition to MS Windows networking protocols and NFS, there are several well known file and print sharing protocols. Linux has support for NetWare-style file and print sharing using IPX protocols , Macintosh-based file and print sharing (AppleTalk protocol), file sharing over protocols such as FISH (File Sharing over SSH), as well as WebDAV-based file services. We do not cover these protocols in this chapter.
Sharing Files with Windows Systems (Samba)
The open source software revolution is not quite over yet, so as a result there still are a huge number of Windows desktop and server systems in common use today. Even though many of us may think that the world will soon be using nothing but a Linux desktop, reality tells us something different: Windows desktops will be around for a long time. So the ability to exchange files across Windows and Linux systems is rather important. The ability to share printers is equally important.
Samba is a very flexible and scalable application suite that allows a Linux user to read and write files located on Windows workstations, and vice versa. You might want to use it just to make files on your Linux system available to a single Windows client (such as when running Windows in a virtual machine environment on a Linux laptop). But you can use Samba to implement a reliable and high-performance file and print server for a network that has thousands of Windows clients. If you use Samba on a site-wide scale, you should probably spend serious time reading the extensive Samba documentation at http://www.samba.org/samba/docs, or a book such as Using Samba (O'Reilly), which is also part of the Samba distribution.
This section documents the key facets you need to know about file and print interoperability between Windows and Linux systems. First off, we supply an overview of how Windows networking operates, to help avoid some of the anguish and frustration that newcomers often feel during their first attempts to cross the great Windows and Unix divide. Next in line is an overview of the tools available in Linux-land that will help the Linux user to gain access to files and printers that live in Windows-land. The subject of providing Windows users access to files and printers that reside on a Linux system for is covered last—not because it is less important, but because the scope of possibilities it offers is so much greater.
Protocols and Things Windows-Related
Linux users are generally aware that all they need for access to a remote Linux systems is its IP address. In essence, an IP address coupled with the Domain Name System (DNS) is the perfect vehicle for interoperating from any Linux system to a remote Linux system. We can therefore say—with perhaps a little poetic license—that the Linux namespace is the DNS. The namespace of the TCP/IP world places few restrictions on the maximum permissible length of a hostname or a name that may be placed in a DNS database. But human laziness usually limits the maximum number of characters one will tolerate in a hostname.
Life in Windows-land is not quite that easy, and there are good reasons for that too. The Windows networking world has a completely different namespace, one that originates from an attempt to solve a file sharing problem with no immediate plan to use TCP/IP . TCP/IP was an afterthought. Windows did not at first have a TCP/IP protocol stack. Its native networking protocol was NetBEUI , which stands for Network Basic Extended User Interface. For the technically minded, the name is a misnomer because the protocol actually consists of the Server Message Block (SMB) protocol via NetBIOS encapsulated over Logical Link Control (LLC ) addressing. The resulting protocol is nonroutable and rather inefficient. The old protocol name, SMB, gave rise to the name Samba for the software project created by developer Andrew Tridgell when he decided to emulate the Windows file-sharing protocol.
Some time around 1996, the Server Message Block protocol was renamed the Common Internet File System (CIFS ) protocol. The original CIFS protocol is basically SMB on steroids. The terms are used interchangeably in common use. The SMB/CIFS protocol supports particular features, such as:
§ File access
§ File and record locking
§ File caching, read-ahead, and write-behind
§ File change notification
§ Ability to negotiate the protocol version
§ Extended file and directory attributes
§ Distributed replicated virtual filesystems
§ Independent name resolution
§ Unicode file and directory names
The description of these features is beyond the scope of this book, but suffice it to say that when correctly configured, the protocols work well enough for large-scale business use.
NetBIOS is actually an application programming interface (API) that allows SMB/CIFS operations to be minimally encoded for transmission over a transport protocol of some type. NetBEUI, also known as the NetBIOS Frame (NBF ) protocol , happens to use LLC addressing. It originated some time in the 1980s and was apparently first used by IBM as part of its PC-LAN product offering. The use of NetBIOS over TCP/IP was developed later and has been documented in various standards. NetBIOS can be encapsulated over many other protocols, the best known of which is IPX/SPX—the NetWare protocol.
NetBIOS (or, more correctly, SMB) has its own namespace. Unlike the native TCP/IP namespace, all NetBIOS names are precisely 16 characters in length. The - (dash) character may be used in the name, but it is ill-advised to use anything other than alphanumeric characters. Attempts to use a numeric character for the first digit will fail because this will cause systems that implement NetBIOS over TCP/IP to interpret the name as an IP address. The 16th character of a NetBIOS name is a name-type character, which is used by servers and clients to locate specific types of services, such as the network logon service.
The NetBIOS namespace also includes an entity known as a workgroup. Machines that have the same workgroup name are said to belong to the same workgroup. IBM LAN Server and Microsoft LAN Manager (as with Windows NT4) used the term domain to indicate that some form of magic authentication technology was being used, but at the lowest level a domain is identical with a workgroup name.
Warning
In network environments based on NetBIOS, it is extremely important to configure every machine to use the same networking protocols and to configure all the protocols identically. There can be no deviation from this; every attempt to do otherwise will result in networking failures.
The NetBIOS over TCP/IP protocol (NBT or NetBT) uses two main protocols and ports for basic operation: TCP port 139 (the NetBIOS Session Service port) and UDP port 137 (the NetBIOS Name Server port). UDP port 137 is used for broadcast-based name resolution using a method known as mail-slot broadcasting. This broadcast activity can be significant on a high-traffic network.
The best way to minimize background UDP broadcast activity is to use a NetBIOS Name Server. Microsoft called this kind of server WINS, for Windows Internet Naming Service. WINS is to NetBT as DNS is to TCP/IP. Clients register their NetBIOS names with the WINS server on startup. If all machines are configured to query the WINS server, Windows networking usually proceeds without too many problems. WINS provides a practical and efficient technique to help resolve a NetBIOS name to its IP address.
With the release of Windows 2000, Microsoft introduced a technology called Active Directory (AD) that uses DNS for resolution of machine names to their TCP/IP addresses. In network environments that use only Windows 2000 (or later) clients and servers, Microsoft provides, together with AD, the ability to disable the use of NetBIOS. In its place, the new networking technology uses raw SMB over TCP/IP. This is known as NetBIOS-less TCP/IP. In the absence of UDP-based broadcast name resolution and WINS, both of which are part of the NetBT protocol suite, NetBIOS-less TCP/IP wholly depends on DNS for name resolution and on Kerberos security coupled with AD services. AD is a more-or-less compliant implementation of the Lightweight Diretory Access Protocol (LDAP) standard, which has an excellent free software implementation called OpenLDAP (mentioned in Chapter 8) and which therefore allows Linux to emulate the most important services offered by AD.
Tip
The use of Samba without NetBIOS support effectively means it must be an AD domain member server. Do not disable NetBIOS support unless you configure AD.
Samba Version 2 is capable only of using NetBT . Samba Version 3 is capable of seamless integration into a Windows AD NetBIOS-less network. When configured this way, it will use TCP port 445 , using the NetBIOS-less Windows networking protocol. Microsoft Windows networking will also use TCP port 135 , for DCE RPC communications. A discussion of these protocols is beyond the scope of this book. The focus in this book is on use of Samba with NetBT.
Samba Version 3 was released in September 2003 after more than two years' development. It implemented more complete support for Windows 200x networking protocols, introduced support for Unicode, added support for multiple password back-ends (including LDAP), and can join a Windows 200x Active Directory domain using Kerberos security protocols. It remains under active development as the current stable release, with support intentions that will keep it current well into 2007. The Samba team hoped to issue Samba Version 4 beta release towards the end of 2005, after approximately three years' development. Samba Version 4 is a complete rewrite from the ground up. It has extensive support for Active Directory, with the intent of providing Active Directory domain control. It is anticipated that by mid-2006 Samba Version 4 will mature to the point that early adopters will begin to migrate to it.
Where possible, Samba should either be its own WINS server or be used in conjunction with a Microsoft WINS server to facilitate NetBIOS name resolution. Remember that a price will be paid for not using WINS: increased UDP broadcast traffic and nonroutability of networking services.
We start this section with a simple scenario where you want to access files from a Windows server on your Linux system. This assumes that you have established a TCP/IP connection between your Linux and Windows computers, and that there is a directory on the Windows system that is being shared. Detailed instructions on how to configure networking and file sharing on Windows 95/98/Me and Windows NT/2000/XP can be found in Using Samba (O'Reilly).
To start with, both your Windows and your Linux systems should be correctly configured for TCP/IP interoperability. This means that:
§ Each system has a valid IP address.
§ The systems share a correct netmask.
§ The systems point to the same gateway (if one of your private networks has routers to multiple network segments).
§ Each system has a valid /etc/hosts and a valid DNS configuration if DNS is in use.
The Windows machine and workgroup names should consist only of alphanumeric characters. If you choose to configure a /etc/hosts file on the Windows clients, this file must be called hosts, without a file extension. On Windows 95/98/Me systems the hosts file should be placed inC:\Windows\System. On Windows NT/2000/XP systems it is located in C:\Winnt\System32\drivers\etc\hosts.
Warning
The example hosts file on Windows NT/2000/XP systems has the file extension sam. Do not name the working file with this extension because it will not work.
In the rest of this chapter, we use the term SMB name to mean the NetBIOS name of the SMB-enabled machine (also known as the machine name). The term workgroup means both the workgroup name and the domain name of an SMB-enabled machine. Please note that for all practical network operations, such as browsing domains and workgroups, and browsing machines for shares, the workgroup name and domain name are interchangeable; hence our use of the term workgroup.
The Windows machine for our examples is a Windows XP Home machine called EMACHO. The workgroup is called MIDEARTH, with IP address 192.168.1.250. Our Linux system has the hostname loudbell, with IP address 192.168.1.4; our domain is goodoil.biz.
Linux System Preparation and Installing Samba
The services discussed in this chapter require kernel modules and facilities that may not be available on your Linux system as initially installed. Many versions of commercial Linux systems (Novell SUSE Linux and Red Hat Linux ) are shipped with the necessary capabilities. If your Linux system is homegrown or one of the roll-your-own distributions, you may need to rebuild the kernel. The steps outlined here should help your preparations. Of course, a recent release of Samba Version 3.0.x will also be required.
First we need to consider the Linux kernel to ensure it is equipped with the tools needed.
The Linux kernel must have support for smbfs and cifsfs . If your Linux system has an older kernel (a version earlier than 2.6.x) the cifsfs facility may not be available. There is a back-port of the cifsfs kernel drivers that you may be able to install. For more information regardingcifsfs visit the CIFS project web site, http://linux-cifs.samba.org/. In the event that you need to install this module into your kernel source code tree, be sure to follow the instructions on that site.
Tip
The smbfs and cifsfs Linux kernel modules are not part of Samba. Each is a separate kernel driver project. Both projects depend on helper tools such as smbmount , smbumount , mount.smbfs , and mount.cifs , which are part of the Samba distribution tarball, and are required to enable its use.
The Linux kernel source file for Version 2.6.x includes the cifsfs module. To find out if your running kernel includes it, install the kernel sources under the directory /usr/src/linux. Now follow these steps:
1. Configure the kernel source code to match the capabilities of the currently executing kernel:
2. linux:~ # cd /usr/src/linux
linux:~ #make cloneconfig
As the cloning of the kernel configuration finishes, the kernel configuration file will be printed to the console. Do not be concerned, because the contents are also stored in the .config file. We examine this file in the next step.
3. To determine the status of smbfs support in the kernel, enter:
4. linux:~ # grep CONFIG_SMB_FS .config
CONFIG_SMB_FS=m
The output tells us that smbfs support is enabled in the kernel and is available as a kernel loadable module. A value of y means it is built into the kernel, which is also acceptable, but a value of n means it is not supported.
In the event that smbfs is not supported, use the kernel configuration utility outlined in "Kernel configuration: make config" in Chapter 18 to enable it.
5. Now determine the status of cifsfs support in the kernel:
6. linux:~ # grep CONFIG_CIFS .config
CONFIG_CIFS=m
This response means that cifsfs support is available in the current kernel. If the value of this option is n, enable it using the kernel configuration utility.
7. If you had to enable support for one of the preceding options, rebuild the kernel and install it.
After rebooting the system, the new kernel will be ready for the steps that follow in this chapter. The next challenge is to ensure that a recent version of Samba is available.
Binary packages of Samba are included in almost any Linux or Unix distribution. There are also some packages available at the Samba home page, http://samba.org.
Refer to the manual for your operating system for details on installing packages for your specific operating system. In the increasingly rare event that it is necessary to compile Samba, please refer to the Samba3-HOWTO document, available at http://www.samba.org/samba/docs/Samba3-HOWTO.pdf, for information that may ease the process of building and installing it appropriately.
Warning
If you decide to build and install Samba manually, be sure to remove all Samba packages that have been supplied by the vendor, or that may already have been installed. Failure to do this may cause old binary files to be executed, causing havoc, confusion, and much frustration.
Before building your own Samba binaries, make certain that the configure command is given the --with-smbmount option. The following commands complete the process of installation of the newly built Samba:
linux:~ # make all libsmbclient wins everything
linux:~ # make install
linux:~ #make install-man
When the Samba build and installation process has completed, execute the following commands to ensure that the mount.cifs binary file is built and installed:
linux:~ # export CFLAGS="-Wall -O -D_GNU_SOURCE -D_LARGEFILE64_SOURCE"
linux:~ # gcc client/mount.cifs.c -o client/mount.cifs
linux:~ #install -m755 -o root -g root client/mount.cifs /sbin/mount.cifs
The system is now ready for configuration, so let's get on with some serious exercises in sharing files with the other world.
Accessing Remote Windows Files and Printers
Soon we will connect to a file share on a Windows system. We assume that the Windows system has a static IP address, and that we are not using DNS. Name resolution is rather important in networking operations, particularly with Windows clients, so let's configure the /etc/hosts file so that it has the following entry:
192.168.1.250 emacho
There should, of course, also be an entry for the IP address of the Linux system we are on.
Now check that the /etc/hosts entries are working:
linux:~ # ping emacho
PING emacho (192.168.1.250) 56(84) bytes of data.
64 bytes from emacho (192.168.1.250): icmp_seq=1 ttl=128 time=2.41 ms
64 bytes from emacho (192.168.1.250): icmp_seq=2 ttl=128 time=2.16 ms
64 bytes from emacho (192.168.1.250): icmp_seq=3 ttl=128 time=2.16 ms
64 bytes from emacho (192.168.1.250): icmp_seq=4 ttl=128 time=2.02 ms
64 bytes from emacho (192.168.1.250): icmp_seq=5 ttl=128 time=2.01 ms
64 bytes from emacho (192.168.1.250): icmp_seq=6 ttl=128 time=3.90 ms
--- emacho ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5004ms
rtt min/avg/max/mdev = 2.015/2.447/3.905/0.667 ms
OK, it works. Now we are really ready to begin file sharing.
Using the FTP-like smbclient to access Windows
It makes a lot of sense to first establish that our Linux system can communicate with the Windows system using Samba. The simplest way to do this is to use the Samba client tool, the smbclient command, to query the Windows machine so it will tell us what shares are available.
Let's perform an anonymous lookup of the Windows machine:
linux:~ # smbclient -L emacho -U%
Domain=[MIDEARTH] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
Sharename Type Comment
--------- ---- -------
Error returning browse list: NT_STATUS_ACCESS_DENIED
Domain=[MIDEARTH] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
Server Comment
--------- -------
Workgroup Master
--------- -------
This is not very encouraging, is it? The lookup failed, as is evidenced by the reply Error returning browse list: NT_STATUS_ACCESS_DENIED. This is caused by a Windows machine configuration that excludes anonymous lookups . So let's repeat this lookup with a valid user account that has been created on the Windows XP Home machine.
An account we can use on our example system is for the user lct with the password 2bblue4u. Here we go:
linux:~ # smbclient -L emacho -Ulct%2bblue4u
Domain=[EMACHO] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
Sharename Type Comment
--------- ---- -------
IPC$ IPC Remote IPC
SharedDocs Disk
print$ Disk Printer Drivers
Kyocera Printer Kyocera Mita FS-C5016N KX
Domain=[EMACHO] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
Server Comment
--------- -------
Workgroup Master
--------- -------
Success! We now know that there is a share called SharedDocs on this machine. In the next step we will connect to that share to satisfy ourselves that we have a working Samba connection.
In this step we connect to the share itself, then obtain a files listing, and then download a file. This is an interesting example of the use of the smbclient utility:
linux:~ # smbclient //emacho/SharedDocs -Ulct%2bblue4u
Domain=[EMACHO] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
smb: \>
Success again! This is good. Now for a directory listing:
smb:\ dir
. DR 0 Thu May 19 12:04:47 2005
.. DR 0 Thu May 19 12:04:47 2005
AOL Downloads D 0 Tue Sep 30 18:55:16 2003
CanoScanCSUv571a D 0 Thu May 19 12:06:01 2005
desktop.ini AHS 129 Sun Jul 4 22:12:14 2004
My Music DR 0 Sat Apr 16 22:42:48 2005
My Pictures DR 0 Tue Sep 30 18:36:17 2003
My Videos DR 0 Thu Aug 5 23:37:56 2004
38146 blocks of size 1048576. 31522 blocks available
smb: \>
We can change directory into the CanoScanCSUv571a directory:
smb: \> cd CanoScanCSUv571a
smb: \CanoScanCSUv571a\>
But we want to see what files are in there:
smb: \CanoScanCSUv571a\> dir
. D 0 Thu May 19 12:06:01 2005
.. D 0 Thu May 19 12:06:01 2005
CanoScanCSUv571a.exe A 3398144 Thu Mar 13 22:40:40 2003
Deldrv1205.exe A 77824 Fri Apr 26 14:51:02 2002
N122U.cat A 13644 Tue May 21 02:44:30 2002
N122u.inf A 6151 Tue Apr 16 22:07:00 2002
N122UNT.cat A 15311 Tue May 21 02:44:32 2002
N122USG D 0 Thu May 19 12:10:40 2005
USBSCAN.SYS A 8944 Fri Jun 12 13:01:02 1998
38146 blocks of size 1048576. 31522 blocks available
smb: \CanoScanCSUv571a\>
Good. Everything so far is working. Let's download a file. Fetching and uploading files with smbclient works just like an FTP client:
smb: \CanoScanCSUv571a\ >get Deldrv1205.exe
getting file \CanoScanCSUv571a\Deldrv1205.exe of size 77824
as Deldrv1205.exe (275.4 kb/s) (average 275.4 kb/s)
It all worked as it should. We are done with this demonstration. Let's quit back to a shell prompt:
smb: \CanoScanCSUv571a\> quit
linux:~ #
Let's summarize what has been learned so far. We have confirmed the following about our environment:
§ There is TCP/IP connectivity between the Linux and Windows systems.
§ Anonymous browsing is disabled on the Windows XP Home system.
§ Authenticated browsing using a local Windows account and password works.
smbclient was designed to be highly versatile. It is used as part of the smbprint utility, where it pipes the print data stream through to a remote SMB/CIFS print queue in a manner analogous to the file transfer example witnessed earlier. For more information regarding the smbclient utility, refer to the manpage.
One you have basic SMB/CIFS interoperability, it should not be too difficult to mount the same share using smbfs. Let's move on and try that in the next section.
Using Linux-kernel-based smbfs
Before proceeding, let's look at what the smbfs filesystem driver does. This tool has some limitations that few people stop to recognize.
The smbfs filesystem driver behaves like the smbclient utility. It makes an authenticated connection to the target SMB/CIFS server using the credentials of a user, based on the account name and password provided. The filesystem driver then permits the SMB/CIFS connection to be attached to a Linux filesystem mount point. The Linux ownership of the mount point will reflect the user ID and group ID of the Linux user who mounts it, and the permissions will be determined by the UMASK in effect at the time of mounting.
In effect, access to all files and directories will be subject to Linux filesystem permission controls, and on the SMB/CIFS server everything will take place as a single user. Multiple concurrent Linux users who access the file share through the mount point will be making multiple concurrent accesses as a single Windows user, and will do so using a single Windows process.
There is one other, rather significant design limitation when using the smbfs filesystem driver. It does not support Unicode , and therefore creates problems when files contain characters other than the English alphabet. It should also be mentioned that this kernel module is somewhat defective and is no longer maintained. So why use it? That is easy to answer. Some Linux systems do not have support for cifsfs.
With these caveats stated and in the open, let's mount that SMB/CIFS filesystem:
linux:~ # mount -t smbfs //emacho/shareddocs /mnt \
-ousername=lct,password=2bblue4u,uid=jim,gid=users
linux:~ #
That was easy! It is time to test whether it works.
linux:~ # cd /
linux:~ # ls -ald /mnt
drwxr-xr-x 1 jim users 4096 May 20 02:50 mnt
This demonstrates that the connection is mounted as the local Unix user jim. Let's copy some files to, and from, this system:
linux:~ # cd /mnt
linux:~ # ls -al
total 25
drwxr-xr-x 1 lct users 4096 May 20 02:50 .
drwxr-xr-x 23 root root 560 May 18 15:21 ..
drwxr-xr-x 1 lct users 4096 Sep 30 2003 AOL Downloads
drwxr-xr-x 1 lct users 4096 May 19 12:06 CanoScanCSUv571a
dr-xr-xr-x 1 lct users 4096 Apr 16 22:42 My Music
dr-xr-xr-x 1 lct users 4096 Sep 30 2003 My Pictures
dr-xr-xr-x 1 lct users 4096 Aug 5 2004 My Videos
-rwxr-xr-x 1 lct users 129 Jul 4 2004 desktop.ini
linux:~ # cd CanoScanCSUv571a
linux:~ # ls -al
total 3451
drwxr-xr-x 1 lct users 4096 May 19 12:06 ./
drwxr-xr-x 1 lct users 4096 May 20 02:50 ../
-rwxr-xr-x 1 lct users 3398144 Mar 13 2003 CanoScanCSUv571a.exe*
-rwxr-xr-x 1 lct users 77824 Apr 26 2002 Deldrv1205.exe*
-rwxr-xr-x 1 lct users 13644 May 21 2002 N122U.cat*
-rwxr-xr-x 1 lct users 15311 May 21 2002 N122UNT.cat*
drwxr-xr-x 1 lct users 4096 May 19 12:10 N122USG/
-rwxr-xr-x 1 lct users 6151 Apr 16 2002 N122u.inf*
-rwxr-xr-x 1 lct users 8944 Jun 12 1998 USBSCAN.SYS*
linux:~ # cp USBSCAN.SYS /tmp
linux:~ # cp /var/log/messages .
linux:~ # ls -al messages
-rwxr-xr-x 1 lct users 240117 May 20 02:58 messages
This has been a satisfying outcome, because everything works. We were able to copy a file from the SMB/CIFS share. A file was also copied to the share from the Linux filesystem. It is possible to create, change, and delete files on an SMB/CIFS mounted filesystem. Permissions that determine the limits of these operations reflect the operations permitted by the SMB/CIFS server for the effective user at its end. Linux filesystem permissions control user access to the mounted resource.
Now let's dismount the filesystem in preparation for the use of the command-line version of the smbfs toolset:
linux:~ # cd /
linux:~ # df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
//emacho/shareddocs 39061504 6782976 32278528 18% /mnt
linux:~ #umount /mnt
The Samba source tarball includes a set of tools that are meant to be run from the command line. The smbmount program is run by the mount command when used with the -t smbfs option, the way we used it previously. The smbmount program calls smbmnt, which performs the actual mounting operation. While the shared directory is mounted, the smbmount process continues to run, and if you issue a ps ax listing, you will see one smbmount process for each mounted share.
The smbmount program reads the Samba smb.conf configuration file, although it doesn't need to gather much information from it. In fact, it is possible to get by without a configuration file, or with one that is empty! The important thing is to make sure the configuration file exists in the correct location, or you will get error messages.
You will learn more about creating and validation of the configuration file later in this chapter. Here is a minimal smb.conf file:
[global]
workgroup = NAME
Simply replace NAME with the name of your workgroup, as it is configured on the Windows systems on your network.
The last thing to do is to mount the shared directory. Using smbmount can be quite easy. The command syntax is
smbmount UNC_resource_name mount_point options
where mount_point specifies a directory just as in the mount command. UNC_resource_name follows the Windows Universal Naming Convention (UNC) format, except that it replaces the backslashes with slashes. For example, if you want to mount a SMB share from the computer called maya that is exported (made available) under the name mydocs onto the directory /windocs, you could use the following command:
linux:~ # smbmount //maya/mydocs/ /windocs
If a username or password is needed to access the share, smbmount will prompt you for them.
Now let's consider a more complex example of an smbmount command:
linux:~ # smbmount //maya/d /maya-d/ \
-o credentials=/etc/samba/pw,uid=jay,gid=jay,fmask=600,dmask=700
In this example, we are using the -o option to specify options for mounting the share. Reading from left to right through the option string, we first specify a credentials file, which contains the username and password needed to access the share. This avoids having to enter them at an interactive prompt each time. The format of the credentials file is very simple:
username=USERNAME
password=PASSWORD
where you must replace USERNAME and PASSWORD with the username and password needed for authentication with the Windows workgroup server or domain. The uid and gid options specify the owner and group to apply to the files in the share, just as we did when mounting an MS-DOS partition in the previous section. The difference is that here we are allowed to use either the username and group name or the numeric user ID and group ID. The fmask and dmask options allow permission masks to be logically ANDed with whatever permissions are allowed by the system serving the share. For further explanation of these options and how to use them, see the smbmount(8) manual page.
One problem with smbmount is that when the attempt to mount a shared directory fails, it does not really tell you what went wrong. This is where smbclient comes in handy—as we saw earlier. See the manual page for smbclient(1) for further details.
Once you have succeeded in mounting a shared directory using smbmount, you may want to add an entry in your /etc/fstab file to have the share mounted automatically during system boot. It is a simple matter to reuse the arguments from the smbmount command shown earlier to create an/etc/fstab entry such as the following (all on one line):
//maya/d /maya-d smbfs
credentials=/etc/samba/pw,uid=jay,gid=jay,fmask=600,dmask=700 0 0
Well, that was a lot of information to digest. Let's continue onto the next section, where we will work with the cifsfs kernel driver that is replacing smbfs.
Using Linux-kernel-based cifsfs
The cifsfs filesystem drive is a relatively recent replacement for the smbfs driver. Unlike its predecessor, cifsfs has support for Unicode characters in file and directory names. This new driver is fully maintained by an active development team.
If you have made sure that your kernel has support for the cifsfs module, as described previously in this chapter, try mounting a remote file share with a command like this:
linux:~ # mount -t cifs -ouser=lct,password=2bblue4u,uid=lct,gid=users \
//emacho/shareddocs /mnt
linux:~ # ls -ald /mnt
drwxrwxrwx 1 lct users 0 May 19 12:04 /mnt
If you compare the mount options with those used with the smbfs driver in the previous section, you'll see that the username parameter has changed to just user. The other parameters can be kept identical.
There is one apparent difference in a directory listing:
linux:~ # ls -al /mnt/CanoScanCSUv571a/
total 3684
drwxrwxrwx 1 lct users 0 May 20 02:58 .
drwxrwxrwx 1 lct users 0 May 19 12:04 ..
-rwxrwSrwt 1 lct users 3398144 Mar 13 2003 CanoScanCSUv571a.exe
-rwxrwSrwt 1 lct users 77824 Apr 26 2002 Deldrv1205.exe
-rwxrwSrwt 1 lct users 13644 May 21 2002 N122U.cat
-rwxrwSrwt 1 lct users 15311 May 21 2002 N122UNT.cat
drwxrwxrwx 1 lct users 0 May 19 12:10 N122USG
-rwxrwSrwt 1 lct users 6151 Apr 16 2002 N122u.inf
-rwxrwSrwt 1 lct users 8944 Jun 12 1998 USBSCAN.SYS
-rwxrwSrwt 1 lct users 240117 May 20 02:58 messages
Note that the directory node size is now reported as zero. Apart from this minor feature, the use of cifsfs to mount an SMB/CIFS resource cannot really be noticed, except when files that have multibyte (Unicode) characters in them are encountered.
The command used to mount the CIFS/SMB filesystem (mount -t cifs) actually causes the execution of the mount.cifs binary file. This file is built from the Samba sources, as we saw earlier in this chapter. There are no command-line tools, as there are with the smbfs kernel drivers and thesmbmount group of tools provided by the Samba package.
Some network administrators insist that a password should never be passed to a Unix command on the command line because it poses a security risk. The good news is that mount.cifs permits an alternative to command-line options for obtaining the username and password credentials: it reads the environment variables USER, PASSWD, and PASSWD_FILE. In the variable USER, you can put the username of the person to be used when authenticating to the server. The variable can specify both the username and the password by using the format username%password. Alternatively, the variable PASSWD may contain the password. The variable PASSWD_FILE may, instead, contain the pathname of a file from which to read the password. mount.cifs reads a single line of input from the file and uses it as the password.
Tip
If you ever put a cleartext password in a file, be sure to set highly restrictive permissions on that file. It is preferrable that only the processes that must have access to such a file be able to read it.
The username and password can also be stored in a file. The name of this file can be used on the command line as part of the -o option as credentials=filename. Many of the options accepted by the mount -t cifs command are similar to those frequently used to mount an NFS filesystem. Refer to the mount.cifs manpage for specific details.
Using Linux desktop tools with libsmbclient
Office users who make heavy use of the Windows Explorer often feel lost when they first sit down at the Linux desktop. This is not surprising, because the look and feel is a little different. Tools are called by different names, but that does not mean that the capabilities are missing. In fact, thanks to the inclusion of the libsmbclient library in all distributions, the Linux desktop file managers (as well as web browsers) have been empowered to browse the Windows network.
Red Hat Linux and Novell SUSE Linux now both include a network browsing facility on the desktop. The environment makes it possible to browse the Windows network and NFS-mounted resources. The level of integration is excellent. Just click on the Windows network browsing icon, andlibsmbclient will do all the hard work for you. Let's try this with both the KDE desktop and the GNOME desktop.
On Novell SUSE Linux Professional, the default KDE user desktop has an icon labeled Network Browsing. A single click opens the application called Konqueror, and very soon displays a separate icon for each networking technology type. The default icons are called FTP, SLP Services, SSH File Browsing, SSH Terminal, VNC Connection, Windows Network, and YOU Server, and there is an icon called Add a Network Folder. When the SMB Share icon is clicked, it reveals an icon for each workgroup and domain on the local network. To use our sample network as an illustration, clicking on the workgroup called MIDEARTH displays an icon for each server in that workgroup. An example of this screen is shown in Figure 15-1.
Figure 15-1. KDE Konqueror using the libsmbclient module
The default GNOME desktop has an icon called Network Browsing. A double-click opens the Network Browsing tool to reveal an icon called Windows Network. Click this to reveal an icon for each workgroup and domain that is visible on the network. An example is shown in Figure 15-2. Click on one of the SMB server icons to expose the shared resources that are available. Click on a shared folder to reveal the files within it. If access to any resource requires full user authentication, a login dialog will pop up. An example of the login dialog is shown in Figure 15-3.
Figure 15-2. GNOME File Manager using the libsmbclient module
Figure 15-3. GNOME libsmbclient network logon
KDE Konqueror neatly shows the URL in the Location bar. As you browse deeper in the Windows filesystem, the URL is updated to reveal the full effective URL that points to the current network location, for example, smb://alexm@MERLIN/archive/Music/Haydn/. The syntax for the URL is given in the libsmbclient manpage as:
smb://[[[domain:]user[:password@]]server[/share[/path[/file]]]][?options]
When libsmbclient is invoked by an application, it searches for a directory called .smb in the $HOME directory that is specified in the user's shell environment. It then searches for a file called smb.conf, which, if present, will fully override the system /etc/samba/smb.conf file. If insteadlibsmbclient finds a file called ~/.smb/smb. conf.append, it will read the system /etc/samba/smb.conf file and then append the contents of the ~/.smb/smb.conf.append file to it.
libsmbclient checks the user's shell environment for the USER parameter and uses its value when the user parameter is omitted from the URL.
The really nice feature of the libsmbclient library is that it authenticates access to the remote CIFS/SMB resource on a per-user basis. Each connection (SMB session) is independent, and access to folders and files is permitted just as if the user has logged onto a Windows desktop to perform this access.
Printing to printers on Windows systems
In the earlier years of Samba the sole mechanism for printing from a Unix/Linux system to a printer attached to a Windows machine involved the use of smbclient via a sample interface script called smbprint. This script is still available in the Samba tarball from the directoryexamples/printing, and remains in use even though it has been superseded by the smbspool utility.
When smbprint usage was at its prime, the two dominant printing systems in the Unix/Linux world were BSD lpr/lpd and AT&T SYSV printing. There was a new tool called LPRng that was trying to edge into the market. The LPRng package was a free open source printing solution that sought to replace the older BSD lpr/lpd technology, which was generally considered buggy and in need of replacement. There are still many Unix and Linux systems that use BSD lpr/lpd or LPRng. LPRng has a strong following in some areas. Systems that use LPRng tend to still usesmbprint as the interface script that makes it possible to send a print job from the Unix/Linux spool to a remote Windows printer.
Commencing around 2000/2001, a new technology started to gain popularity. This package was called CUPS (the Common Unix Print System). The growth of adoption of CUPS has been dramatic. Meanwhile, the development team behind CUPS has gradually expanded its functionality as well as its utility. They created a printing API and have worked with many open source projects to gain a high degree of integration into each software project that requires a printing interface. The CUPS team worked together with the Samba team and contributed a direct interface methodology so that Samba can communicate with CUPS without requiring external interface scripts and utilities. Samba can pipe a print job directly to the CUPS spool management daemon cupsd.
In addition to the improved interface between Samba and CUPS, CUPS is a whole lot smarter than older print systems when sending print jobs to a network-attached Windows printer. Samba has gained a new printing utility (smbspool) that handles all printer interfacing between CUPS and a Windows print server.
Given that CUPS is now the dominant printing technology in Linux, it is best left to the configuration tools provided with either CUPS itself or with the Linux distribution to handle Linux-to-Windows printing. On the other hand, there will always be a situation that is not satisfied by this approach. When it is necessary to send a print job to a Windows printer, it is handy to have knowledge of a suitable tool. The tool of choice in this situation is smbspool.
In brief, here are the varieties of command syntax recognized by the smbspool utility:
smb://server[:port]/printer
smb://workgroup/server[:port]/printer
smb://username:password@server[:port]/printer
smb://username:password@workgroup/server[:port]/printer
One of these modes of use will meet all known needs. Each is followed by arguments:
1. This contains the job ID number, and is not presently used by smbspool.
2. This contains the print user's name, and is not presently used by smbspool.
3. This contains the job title string, and is passed as the remote file name when sending the print job.
4. This contains the number of copies to be printed. If no filename is provided (argument 6), this argument is not used by smbspool.
5. This contains the print options in a single string, and is currently not used by smbspool.
6. This contains the name of the file to print. If the argument is not specified, the material to print is read from the standard input.
Each parameter should be in the order listed.
Sharing Linux Files and Printers with Windows Users
The previous section outlined the use of tools that make it possible for a Linux desktop user to access files located on Windows workstations and servers using native Windows networking protocols. These tools can also be used in the other direction: to access files that are on a Unix/Linux server.
In this section we explore the use of Samba to provide files that are stored on Linux to Windows clients.
Tip
The CIFS/SMB protocol is more complex than some other file-sharing protocols such as NFS. Samba has to be not only protocol-compatible with Microsoft Windows clients, but also compatible with the bugs that are present in each client. In this section, we show you a simple Samba setup, using as many of the default settings as we can.
Setting up Samba involves the following steps:
1. Compiling and installing Samba, if it is not already present on your system.
2. Writing the Samba configuration file smb.conf and validating it for correctness.
3. Starting the two Samba daemons smbd and nmbd.
When correctly configured, a Samba server and the directories shared will appear in the browse lists of the Windows clients on the local network—normally accessed by clicking on the Network Neighborhood or My Network Places icon on the Windows desktop. The users on the Windows client systems will be able to read and write files according to your security settings just as they do on their local systems or a Windows server. The Samba server will appear to them as another Windows system on the network, and act almost identically.
Installing Samba
Correctly compiling Samba can be a challenge, even for an experienced developer, so it makes sense to use prebuilt binary packages where they are available. For most administrators the choice is among the following options:
1. Install from trusted RPM or .deb pacakges.
2. Install from contributed RPM or .deb packages.
3. Compile and install from the official source tarball.
4. Hire someone else to compile and install from the source tarball.
Most Linux distributions include Samba, allowing you to install it simply by choosing an option when installing Linux. If Samba wasn't installed along with the operating system, it's usually a fairly simple matter to install the package later. Either way, the files in the Samba package will usually be installed as follows:
§ Daemons in /usr/sbin
§ Command-line utilities in /usr/bin
§ Configuration files in /etc/samba
§ Logfiles in /var/log/samba
§ Runtime control files in /var/lib/samba
There are some variations on this. For example, in older releases, you may find logfiles in /var/log, and the Samba configuration file in /etc.
If your distribution does not include Samba, you can download the source code, and compile and install it yourself. In this case, all of the files that are part of Samba are installed into subdirectories of /usr/local/samba.
Either way, you can take a quick look in the directories just mentioned to see whether Samba already exists on your system, and if so, how it was installed.
Tip
If you are not the only system administrator of your Linux system, be careful. Another administrator might have used a source code release to upgrade an earlier version that was installed from a binary package, or vice versa. In this case, you will find files in both locations, and it may take you a while to determine which installation is active.
If you need to install Samba, you can either use one of the packages created for your distribution, or install from source. Installing a binary release may be convenient, but Samba binary packages available from Linux distributors are usually significantly behind the most recent developments. Even if your Linux system already has Samba installed and running, you might want to upgrade to the latest stable source code release.
Obtaining fresh source files. You can obtain the Samba source files from the Samba web site http://www.samba.org/. To obtain a development version, you can download Samba from Subversion or using rsync.
Samba is developed in an open environment. Developers use Subversion to check in (also known as commit) new source code. Samba's various Subversion branches can be accessed via anonymous Subversion using SVNweb or using the Subversion client.
To use SVNweb, access the URL http://svnweb.samba.org.
Subversion gives you much more control over what you can do with the repository and allows you to check out whole source trees and keep them up-to-date via normal Subversion commands. This is the preferred method of access by Samba developers.
In order to download the Samba sources with Subversion, you need a Subversion client. Your distribution might include one, or you can download the sources from http://subversion.tigris.org.
To gain access via anonymous Subversion, use the following steps.
1. Install a recent copy of Subversion. All you really need is a copy of the Subversion client binary.
2. Run the command:
linux:~ # svn co svn://svnanon.samba.org/samba/trunk samba.
This will create a directory called samba containing the latest Samba source code (usually the branch that is going to be the next major release). At the time of writing, this corresponded to the 3.1 development tree.
Other Subversion branches besides the trunk can be obtained by adding branches/BRANCH_NAME to the URL you check out. A list of branch names can be found on the Development page of the Samba web site. A common request is to obtain the latest 3.0 release code, which can be done using the following command:
linux:~ # svn co svn://svnanon.samba.org/samba/branches/SAMBA_3_0_RELEASE samba_3
3. Whenever you want to merge in the latest code changes, use the following command from within the Samba directory:
linux:~ # svn update
Building Samba from source. To install from source, go to the Samba web site at http://www.samba.org and click on one of the links for a download site near you. This will take you to one of the mirror sites for FTP downloads. The most recent stable source release is contained in the filesamba-latest.tar.gz. This file will give you detailed instructions on how to compile and install Samba. Briefly, you will use the following commands:
linux:~ # tar xzvf samba-latest.tar.gz
linux:~ # cd samba-VERSION
linux:~ # su
Password:
linux:~ # ./configure
linux:~ # make
linux:~ #make install
Make sure to become superuser before running the configure script. Samba is a bit more demanding in this regard than most other open source packages you may have installed. After running the commands just shown, you will be able to find Samba files in the following locations:
§ Executables in /usr/local/samba/bin
§ Configuration file in /usr/local/samba/lib
§ Logfiles in /usr/local/samba/log
§ smbpasswd file in /usr/local/samba/private
§ Manual pages in /usr/local/samba/man
You will need to add the /usr/local/samba/bin directory to your PATH environment variable to be able to run the Samba utility commands without providing a full path. Also, you will need to add the following two lines to your /etc/man.config file to get the man command to find the Samba manpages:
MANPATH /usr/local/samba/man
MANPATH_MAP /usr/local/samba/bin /usr/local/samba/man
Configuring Samba
The next step is to create a Samba configuration file for your system. Many of the programs in the Samba distribution read the configuration file, and although some of them can get by with a file containing minimal information (even with an empty file), the daemons used for file sharing require that the configuration file be specified in full.
The name and location of the Samba configuration file depend on how Samba was compiled and installed. An easy way to find it is to use the testparm command, shown later in this section. Usually, the file is called smb.conf, and we'll use that name for it from now on.
The format of the smb.conf file is like that of the .ini files used by Windows 3.x: there are entries of the type:
key = value
When working with Samba, you will almost always see the keys referred to as parameters or options. They are combined in sections (also called stanzas) introduced by labels in square brackets. The stanza name goes by itself on a line, like this:
[stanza-name]
Each directory or printer you share is called a share or service in Windows networking terminology. You can specify each service individually using a separate section name, but we'll show you some ways to simplify the configuration file and support many services using just a few sections. One special section called [global] contains parameters that apply as defaults to all services, and parameters that apply to the server in general. Although Samba understands literally hundreds of parameters, it is very likely that you will need to use only a few of them, because most have reasonable defaults. If you are curious which parameters are available, or you are looking for a specific parameter, read the manpage for smb.conf(5). But for now, let's get started with the following smb.conf file:
[global]
workgroup = MIDEARTH
printing = BSD
wins support = yes
[homes]
browseable = no
read only = no
[printers]
printable = yes
printing = BSD
path = /var/spool/samba
[data]
path = /export/data
read only = no
map archive = no
Although this is a very simple configuration, you may find it satisfactory for most purposes. We'll now explain each stanza in the file in order of appearance, so you can understand what's going on, and make the changes necessary for it to fit your own system. The parts you most likely need to change are emphasized in boldface in the file listing just shown.
In the [global] section, we set parameters that configure Samba on the particular host system. The workgroup parameter defines the workgroup to which the server belongs. You will need to replace MIDEARTH with the name of your workgroup. If your Windows systems already have a workgroup defined, use that workgroup. If not, create a new workgroup name here and configure your Windows systems to belong to it. Use a workgroup name other than the Windows default of WORKGROUP, to avoid conflicts with misconfigured or unconfigured systems.
For our server's computer name (also called NetBIOS name), we are taking advantage of Samba's default behavior of using the system's hostname. That is, if the system's fully qualified domain name is dolphin.example.com, it will be seen from Windows as dolphin. Make sure your system's hostname is set appropriately. If you want to explicitly name your Samba server by its hostname, enter a line in the global stanza like this:
netbios name = DOLPHIN
You can provide a NetBIOS name that differs from the hostname, so it is perfectly acceptable to name the computer like this:
netbios name = WHITESHARK
Warning
The default hostname used by several Linux distributions is localhost. Please be certain to change that to a valid name, because any machine that has the NetBIOS name of LOCALHOST is completely unusable. This name will always resolve on a Windows network client as the IP address 127.0.0.1, and that is the client itself!
The encrypt passwords parameter tells Samba to expect clients to send passwords in encrypted form, rather than plain text. This parameter should be set on all versions of Samba prior to Version 3.0 because it is necessary in order for Samba to work with Windows 98, Windows NT Service Pack 3, and later versions. Samba version 3.0 and later default to using encrypted passwords, so the parameter is unnecessary, but worth including just to make sure you're doing it right.
Tip
The wins support parameter tells Samba to function as a WINS server, resolving computer names into IP addresses. This is optional, but helps to keep your network running efficiently as described earlier in this chapter in "Protocols and Things Windows-Related." A WINS server is like a DNS server for NetBIOS names, with the key difference that clients register themselves with a WINS server.
The rest of the sections in our sample smb.conf are all optional and define the resources Samba offers to the network.
The [homes] stanza defines a meta-service that tells Samba to automatically share home directories. When clients connect to the Samba server, Samba looks up the username of the client in the Linux /etc/passwd file (or whatever is defined in the name service switch backend), to see if the user has an account on the system. If the account exists and has a home directory, the home directory is offered to the client as a shared directory. The username will be used as the name of the share (which appears as a folder on a Windows client). For example, if a user diane, who has an account on the Samba host, connects to the Samba server, she will see that it offers her home directory on the Linux system as a shared folder named diane.
The parameters in the [homes] stanza define how the home directories will be shared. It is necessary to set browseable = no to keep a shared folder named homes from appearing in the browse list.
By default, Samba offers shared folders with read-only permissions. Setting read only = no causes the folder and its contents to be offered in read/write manner to the client. Setting permissions like this in a share definition does not change any permissions on the files in the Linux filesystem, but rather acts to apply additional restrictions. A file that has read-only permissions on the server will not become writable from across the network as a result of read only being set to no. Similarly, if a file has read/write permissions on the Linux system, Samba's default of sharing the file as read-only applies only to access by Samba's network clients.
Samba has the sometimes difficult job of making a Unix filesystem appear like a Windows filesystem to Windows clients. One of the differences between Windows and Unix filesystems is that Windows uses the archive attribute to tell backup software whether a file has been modified since the previous backup. If the backup software is performing an incremental backup, it backs up only files that have their archive bit set. On Unix, this information is usually inferred from the file's modification timestamp, and there is no direct analog to the archive attribute. Samba mimics the archive attribute using the Unix file's execute bit for owner. This allows Windows backup software to function correctly when used on Samba shares, but has the unfortunate side effect of making data files look like executables on your Linux system. We set the map archive parameter to nobecause we expect that you are more interested in having things work right on your Linux system than being able to perform backups using Windows applications.
The [printers] stanza tells Samba to make printers connected to the Linux system available to network clients. Each section in smb.conf, including this one, that defines a shared printer must have the parameter printable = yes. For a printer to be made available, it must have an entry in the Linux system's /etc/printcap file. This file specifies all the printers on your system and how they are accessed. The printer will be visible to users on network clients with the name it is listed by in the printcap file.
With CUPS, the printcap file is autogenerated, and should not be modified or editted by the administrator. Some Linux distributions create a symbolic link from /etc/printcap that points to the autogenerated file, which is named /etc/cups/printcap. If you want to expose a subset of printers for use by Samba, you can remove the symbolic link and then create your own /etc/printcap file that exposes only the printers you want Windows users to access. A better way to achieve this (because it does not interfere with the OS printing implementation) is to simply create a file called/etc/samba/smbprintcap, in which you list the printers that are suitable for Windows client use. This file can then be specified in the smb.conf file [global] section parameter printcap name = /etc/samba/smbprintcap.
If you have already configured a printer, it may not work properly when shared over the network. Usually, when configuring a printer on Linux, the print queue is associated with a printer driver that translates data it receives from applications into codes that make sense to the specific printer in use. However, Windows clients have their own printer drivers, and expect the printer on the remote system to accept raw data files that are intended to be used directly by the printer, without any kind of intermediate processing. The solution is to add an additional print queue for your printer (or create one, if you don't already have the printer configured) that passes data directly to the printer. In the Unix/Linux world this is sometimes called "raw mode."
The first time the printer is accessed from each Windows client, you will need to install the Windows printer driver on that client. The procedure is the same as when setting up a printer attached directly to the client system. When a document is printed on a Windows client, it is processed by the printer driver, and then sent to Samba. Samba simply adds the file to the printer's print queue, and the Linux system's printing system handles the rest. Historically, most Linux distributions have used BSD-style printing systems, and so we have set printing = BSD in the same configuration file to notify Samba that the BSD system is in use. Samba then acts accordingly, issuing the appropriate commands that tell the printing system what to do. More recently, some Linux distributions have used the LPRng printing system or CUPS. If your distribution uses LPRng, set printing = LPRNG. If it uses CUPS, set printing = CUPS, and also set printcap name = CUPS.
We have set the path parameter to /var/spool/samba to tell Samba where to temporarily put the binary files it receives from the network client, before they are added to the print system's queue. You may use another directory if you like. Make sure the directory exists. It must also be world-writable, to allow all clients to access the printer. A security-conscious administrator will object to this because it is a simple matter to hijack someone's print job and turn it into a Trojan horse through which the Linux system may be compromised. The solution to that problem is to set the sticky bit on this directory, thus permitting only the owner to change the file. The sticky bit, together with world read and write permission, can be set on the directory like this:
linux:~ # chmod a+rwxt /var/spool/samba
The [data] stanza in our example shows how to share a directory. You can follow this example to add as many shared directories as you want, by using a different section name and value for path for each share. In the official Samba documentation you will find that the shared directory is referred to as the share-point in the Linux filesystem. The stanza name is used as the name of the share, which will show up on Windows clients as a folder with that name. As in previous sections, we have used read only = no to allow read/write access to the share, and map archive = no to prevent files from having their execute bits set. The path parameter tells Samba what directory on the Linux system is to be shared. You can share any directory, but make sure it exists and has permissions that correspond to its intended use. For our [data] stanza, the directory/export/data has read, write, and execute permissions set for all of user, group, and other, because it is intended as a general-purpose shared directory for everyone to use.
After you are done creating your smb.conf file, run the testparm program, which checks your smb.conf for errors and inconsistencies. If your smb.conf file is correct, testparm should report satisfactory messages, as follows:
linux:~ # testparm
Load smb config files from /usr/local/samba/lib/smb.conf
Processing section "[homes]"
Processing section "[printers]"
Processing section "[data]"
Loaded services file OK.
Press enter to see a dump of your service definitions
If you have made any major errors in the smb.conf file, you will get error messages mixed in with the output shown. You don't need to see the dump of service definitions at this point, so just type Ctrl-C to exit testparm.
Smart administrators make a practice of documenting their Samba configuration file. This can be particularly beneficial at a later date when it may be necessary to remember why certain parameters were set. Unfortunately, the practice of documenting the smb.conf file is at variance with the way Samba works. The file is reread frequently by smbd, so the larger the file becomes because of your documentation, the greater the system impact may be. The solution to this dilemma is to always use a master file in which all parameters are documented as required, then use this command:
linux:~ # testparm -s smb.conf.master > smb.conf
The resulting smb.conf file will be stripped of all comments and contain only those parameters that are not at the default setting. It will be as small as possible while implementing the settings specified. Be warned, though, that the resulting file will be stripped of macros and you may need to edit the file to put them back. For example, include = /etc/samba/%m.conf will be rendered as include=/etc/samba/.conf.
Starting the Samba server
Samba essentially consists of three daemons , of which two are always needed:
nmbd
Handles all name registration and resolution requests. It is the primary vehicle involved in network browsing. It handles all UDP-based protocols. The nmbd daemon should be the first command started as part of the Samba startup process.
smbd
Handles all TCP/IP-based connection services for file- and print-based operations. It also manages local authentication. It should be started immediately following the startup of nmbd.
winbindd
This daemon should be started when Samba is a member of a Windows NT4 or ADS domain. It is also needed when Samba has trust relationships with another domain. The winbindd daemon checks the smb.conf file for the presence of the idmap uid and idmap gid parameters to obtain the values that can be used to map Windows SIDs. The range specified must not conflict with already used on the system. Where no idmap uid or gid ranges are specified winbindd will not perform Windows SID mapping and will be capable only of performing user authentication.
You can choose to start smbd, winbindd, and nmbd either as daemons or from inetd . Don't try to do both! You wouldn't want two sets of these daemons competing for traffic and stepping on each other.
For intermittently used services where a few users connect sporadically, it might be appropriate to run the services from inetd or xinetd, which you can do by putting them in inetd.conf. However, most administrators just start the services as daemons either from the command line or in/etc/rc.local. The main advantage of the second method, starting smbd and nmbd as standalone daemons, is that they will respond slightly more quickly to an initial connection request.
See the manpages for details on the command-line options. Take particular care to read the bit about what user you need to have to start Samba. Samba is best run as the root user. It will switch to the effective user ID of the user who is accessing Samba resources, but it also needs to be able to run with root privilege for operations that under Linux can be performed only by root, such as adding users and groups. Samba Version 3.0.11 and later permit this right and privilege to be assigned to a non-root account—however, smbd must run as root to be able to do this.
When Samba has been packaged by an operating system vendor, the startup process is typically a custom feature of its integration into the platform as a whole. Please refer to your operating system platform administration manuals for specific information pertaining to correct management of Samba startup.
Starting Samba from inetd.conf. To make sure Samba will run as a service, start by looking at your /etc/services file. What is defined at port 139/tcp? If nothing is defined, add a line such as this:
netbios-ssn 139/tcp
Similarly for port 137/udp, you should have an entry such as:
netbios-ns 137/udp
If you use NIS, NIS+, or LDAP to distribute services maps, they will be consulted instead of the /etc/services file. However, the steps just shown are worth going through, because systems sometimes fall back on /etc/services.
Next, edit your /etc/inetd.conf file and add two lines such as the following:
netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd
netbios-ns dgram udp wait root /usr/local/samba/bin/nmbd nmbd
The exact syntax of /etc/inetd.conf varies between Linux distributions. Look at the other entries in inetd.conf for a guide.
Tip
Some distributions already have entries such as netbios_ns (note the underscore) in /etc/services. You must edit /etc/services or /etc/inetd.conf to make them consistent.
Some distributions use xinetd instead of inetd. Consult the xinetd manual for configuration information.
On many systems, you need to use the interfaces option in smb.conf to specify the IP addresses and netmasks of your interfaces. Run ifconfig as root if you do not know this information. nmbd tries to determine it at runtime, but fails on some systems.
Warning
On many distributions, a maximum of five arguments are allowed on command lines in inetd.conf. One way to avoid hitting this limit is to omit the spaces between options and arguments (e.g., write -fname instead of -f name). If you absolutely can't stay within the five-option limit, create a one-line script that invokes the command and start the script from inetd.
Having enabled Samba operation in inetd, you have to restart inetd. To do this, just send it a HUP, like this:
linux:~ # killall -HUP inetd
Starting the Samba daemons with default compilations. If you installed Samba from a source code distribution, you need a script that starts and stops the daemons. You may be able to find and copy such a script from a Samba binary package for your distribution—but check the directory names to make sure they correspond to where you actually built and installed the files. Alternatively, we'll show you how to write and install your own script.
When started from a script, smbd and nmbd must be started with the -D option, so that they will detach themselves and run as daemons.
After you have tested the script and you are sure it works, create the appropriate symbolic links in your /etc/rcN.d directories to start Samba in the run level you normally run in, and stop Samba when changing to other run levels.
This information applies to systems on which Samba has been compiled locally using the Samba default arguments to the configure command. To start the server as a daemon, you should create a script something like this one, perhaps calling it startsmb:
#!/bin/sh
/usr/local/samba/bin/smbd -D
/usr/local/samba/bin/winbindd
/usr/local/samba/bin/nmbd -D
Make it executable with
linux:~ # chmod +x startsmb
You can then run startsmb by hand, and add it to a system rc script.
If your smb.conf file is error-free, it is rare for the daemons to fail to run. Still, you might want to run a ps ax command and check that they are in the list of active processes. If not, take a look at the Samba logfiles, log.smbd and log.nmbd, for error messages.
To stop Samba, send a kill signal to the nmbd and smbd processes. On Debian, you can use the killall command, sending them the SIGTERM signal:
# killall -TERM smbd nmbd
Controlling Samba execution on Debian Linux. The samba script can be used to start, stop, or restart Samba.
linux:~ # /etc/init.d/samba start
Controlling Samba execution on SUSE and Red Hat Linux. SUSE Linux implements individual control over each Samba daemon. A Samba control script that can be conveniently executed from the command line is shown in Example 15-1. This can be located in the directory /sbin in a file called samba. This type of control script should be owned by user root and group root, and set so that only root can execute it.
Example 15-1. A useful Samba control script for SUSE Linux
#!/bin/bash
#
# Script to start/stop samba
# Locate this in /sbin as a file called 'samba'
RCD=/etc/rc.d
if [ z$1 = = 'z' ]; then
echo $0 - No arguments given; must be start or stop.
exit
fi
if [ $1 = = 'start' ]; then
${RCD}/nmb start
${RCD}/smb start
${RCD}/winbind start
fi
if [ $1 = = 'stop' ]; then
${RCD}/smb stop
${RCD}/winbind stop
${RCD}/nmb stop
fi
if [ $1 = = 'restart' ]; then
${RCD}/smb stop
${RCD}/winbind stop
${RCD}/nmb stop
sleep 5
${RCD}/nmb start
${RCD}/smb start
${RCD}/winbind start
fi
exit 0
A sample startup script for a Red Hat Linux system is shown in Example 15-2. This file could be located in the directory /etc/rc.d and can be called samba or smb. A similar startup script is required to control winbind. If you want to find more information regarding startup scripts , please refer to the packaging section of the Samba source code distribution tarball. The packaging files for each platform include a startup control file.
Example 15-2. A sample Samba control script for Red Hat Linux
#!/bin/sh
#
# chkconfig: 345 81 35
# description: Starts and stops the Samba smbd and nmbd daemons \
# used to provide SMB network services.
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
CONFIG=/etc/samba/smb.conf
# Check that smb.conf exists.
[ -f $CONFIG ] || exit 0
# See how we were called.
case "$1" in
start)
echo -n "Starting SMB services: "
daemon smbd -D; daemon nmbd -D; echo;
touch /var/lock/subsys/smb
;;
stop)
echo -n "Shutting down SMB services: "
smbdpids=`ps guax | grep smbd | grep -v grep | awk '{print $2}'`
for pid in $smbdpids; do
kill -TERM $pid
done
killproc nmbd -TERM; rm -f /var/lock/subsys/smb
echo ""
;;
status)
status smbd; status nmbd;
;;
restart)
echo -n "Restarting SMB services: "
$0 stop; $0 start;
echo "done."
;;
*)
echo "Usage: smb {start|stop|restart|status}"
exit 1
esac
Validating that Samba is running. Now that you have Samba installed, configured, and running, try using the smbclient command to list shared resources (the example given here is from an office network on a day when only two people were at work):
linux:~ # smbclient -L localhost -U%
added interface ip=172.16.1.3 bcast=172.16.1.255 nmask=255.255.255.0
Domain=[MIDEARTH] OS=[Unix] Server=[Samba 3.0.20]
Sharename Type Comment
--------- ---- -------
archive Disk Full Archive Files
print$ Disk Printer Drivers
netlogon Disk Network Logon Service
profiles Disk Profile Share
IPC$ IPC IPC Service (Main Server)
ADMIN$ IPC IPC Service (Main Server)
kyocera Printer FS-C5016N
Domain=[MIDEARTH] OS=[Unix] Server=[Samba 3.0.20]
Server Comment
--------- -------
AURORA Moberg's Magic Machine
MERLIN Main Server
TINKERBELL Mel's Laptop
Workgroup Master
--------- -------
MIDEARTH MERLIN
This output demonstrates that a null-session connection could be made to the Samba server. The null session is one that uses no username and no password; it depends only on the availability of the guest account, which is usually called nobody in the /etc/passwd file.
If this validation step fails, the cause is usually either that a firewall is blocking the Samba network traffic or that the guest account could not be found in the /etc/passwd file.
Adding users
Network users must be authenticated by Samba before they can access shares. The configuration we are using in this example employs Samba's "user-level" security. This means that users are required to provide a username and password that must match those of a Samba account on the Linux host system. The first step in adding a new Samba user is to make sure that the user has a Linux system account, and, if you have a [homes] share in your smb.conf, that the account has an existing home directory.
The tool most frequently used to add user accounts to a Linux system is called useradd.
linux:~ # useradd -musername
Samba uses its own password file. It uses the Windows networking passwords and other data it stores in this file to validate the encrypted passwords that are received from clients. For each Samba user, you must run the smbpasswd command to add a Samba account for that user:
linux:~ # smbpasswd -ausername
New SMB password:
Retype new SMB password:
Make sure that the username and password you give to smbpasswd are both the same as those of the user's Linux account. We suggest you start off by adding your own account, which you can use a bit later to test your installation.
An Office File- and Print-Sharing Solution Using Samba
Now that you are familiar with what Samba is, how to create a basic file server, and how to start and stop it, let's turn our hand to a slightly more complex server configuration. The example we work with here is one that may typically be found in an office of 5 to 50 users. The server can be accessed from old Windows systems using basic workgroup-style Windows networking, but can also serve as a Samba domain controller that provides fully secure authenticated network access services. The complexity is in how it is used, not in the design, and that is the way it should be.
The first priority is to configure simple centralized file sharing and simple printer sharing.
We will consider installation of two types of printers: a network-attached printer and a USB-attached printer. Installation of a network-attached printer is very easy. An HP LaserJet that has a JetDirect network card in it is a typical example of such a printer. This type of printer may be installed using the command-line printer installation tool as follows:
linux:~ # lpadmin -p hplj -v socket://192.168.1.25:9100 -E
In this example, the HP JetDirect card has been programmed to IP address 192.168.1.25. The CUPS spooler will communicate directly with the printer via TCP port 9100, and the -E option means that the print queue called hplj will be immediately enabled.
This procedure did not install a printer driver, as one was not specified. To install a printer driver, add the -m model option. Ensure that you specify the correct model information. In our previous example, we could add -m LaserJet-laserjet to the end of the command line.
Installation of a USB-attached Canon BJC-85 printer as a raw printer (i.e., without Linux print filtering) can be achieved by executing:
linux:~ # lpadmin -p bj85 -v usb://Canon/BJC-85 -m BJC-85-bjc600 -E
Current Linux distributions autodetect the presence of a USB-attached printer or a parallel-port-attached printer, and prompt you to confirm that you want the printer to be automatically configured. In most cases, the printer driver will be autoinstalled without the need to insert a driver disk.
There are two main methods by which a Linux system printer can be made available for use by Windows client users. The first is known as raw mode , and the second method is known as smart mode .
Raw-mode printing treats the Linux printing system as simply a means of passing a print job directly to the printer without any attempt to intelligently filter the job. This is the most common way that the Berkeley print systems (lpr/lpd) and LPRng function in their simplest configurations. CUPS is capable of raw-mode processing also. The Samba cups options = raw parameter permits CUPS to operate as a raw-mode print spooler.
If this parameter is omitted from the smb.conf file, and the CUPS print spooler receives a print job containing a character sequence that is not known to the CUPS filters, the print job may be deleted and never reach the printer. Another way to get the job through CUPS (if you fail to specify the cups options = raw parameter) is to edit the /etc/cups/mime.types and /etc/cups/mime.convs files to uncomment the line specifying the application/octet-stream MIME type. This permits CUPS to send the print job with the unknown characters directly to the printer.
Raw-mode printing requires the installation of the correct printer driver on every Windows client. The Windows client must fully process all print jobs and render them so they are ready to go directly to the printer.
The smart-mode printing method involves installation of a local print filtering system on the CUPS server. The CUPS server will attempt to interpret the nature of the file that is sent to the printer, and will then filter it with appropriate automatic conversion to suit the printer.
When CUPS printers are used in smart mode, it is possible to use a CUPS PostScript driver (available from the CUPS web site) on all Windows clients, even if the printer is not a PostScript-capable printer. CUPS will convert the print job to the necessary format. It is, however, necessary to install a printer driver that produces an output format known to the CUPS filtering system.
The Samba smb.conf file is shown in Example 15-3. This example enables use of raw-mode printing. If the CUPS printer driver is correct, any one of a large number of Windows printer drivers can be used on the Windows clients. For example, it is possible to use a Color LaserJet driver even though the printer may be an Epson Bubblejet printer.
Example 15-3. Samba smb.conf file for an office network
# Global parameters
[global]
workgroup = GOODOIL
netbios name = LOUDBELL
passwd chat = *New*Password* %n\n *Re-enter*new*password* %n\n *Password*changed*
username map = /etc/samba/smbusers
syslog = 0
name resolve order = wins bcast hosts
printcap name = CUPS
cups options = raw
show add printer wizard = No
add machine script = /usr/sbin/useradd -s /bin/false -d /dev/null '%u'
logon script = scripts\logon.bat
logon path =
logon home = \\%L\%U
logon drive = H:
domain logons = Yes
preferred master = Yes
wins support = Yes
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[printers]
comment = SMB Print Spool
path = /var/spool/samba
guest ok = Yes
printable = Yes
use client driver = Yes
default devmode = Yes
browseable = No
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
guest ok = Yes
[officedata]
comment = Office Files
path = /data/office
read only = No
Please refer to Chapter 14 for information regarding Linux printer configuration. Samba is capable of communicating directly with CUPS via the libcups.so library. To configure Samba to use LPRNG-based printing, simply replace the printcap name = CUPS directive with printcap name = LPRNG. All printers will be automatically exported for use by Samba.
Install the smb.conf file in the correct location. Then start Samba following the guidelines shown in "Starting the Samba server," earlier in this chapter.
Create the Linux filesystem directory /data/office and set the Linux permissions so that the Linux and Windows (Samba) users who need to access it have appropriate access privilege. For example, if all users should be able to read the directory, and the user jamesb needs write capability, execute the following:
linux:~ # chown -R jamesb:users /data/office
linux:~ #chmod -R u=rwx,g=rx,o-rwx /data/office
After Samba has started, add a user account as shown in "Adding users." When you have created a user account, try out the smbclient command described earlier in "Using the FTP-like smbclient to access Windows":
linux:~ # smbclient //localhost/officedata -U'username'
password:XXXXXXXXXX
Here, username is the user account you created, and XXXXXXXXXX is the password you entered when adding the Samba account through the smbpasswd command.
At the smb: > prompt, you can enter any smbclient command. Try the ls command, to list the contents of the directory. Then try the help command, which will show you all of the commands that are available. The smbclient program works very much like ftp, so if you are used to ftp, you will feel right at home. Now exit smbclient (using the quit or exit command) and try some variations. First, use your server's hostname loudbell instead of localhost to check that name resolution is functioning properly. Then try accessing your home directory by using your username in place of officedata.
And now for the really fun part: go to a Windows system, and log on using your Samba account username and password. (On Windows NT/2000/XP, you will need to add a new user account, using the Samba account's username and password.) Double-click on the Network Neighborhood or My Network Places icon on the desktop. Browse through the network to find your workgroup, and double-click on its icon. You should see an icon for your Samba server in the window that opens. By double-clicking on that icon, you will open a window that shows your home directory, printer, and officedata shares. Now you can drag and drop files to and from your home directory and data shares, and, after installing a printer driver for the shared printer, send Windows print jobs to your Linux printer!
We have only touched the surface of what Samba can do, but this should already give you an impression of why Samba—despite not being developed just for Linux—is one of the software packages that have made Linux famous.
Automatic Printer Driver Download
Windows network administrators understand the benefits of easy and reliable printer installations on Windows workstations. Consider, if you will, an example from the daily grind of network administration where printer drivers have not been uploaded to print servers. The network administrator arrives at the desk of a user who requires access to a new printer; he begins to install the printer and discovers that he left the driver disk on his desk. Now he has to walk back to his desk, and in some large businesses that can be a long walk. Alternately, he discovers that the driver does not work and a later driver release is needed. It is so much more convenient to have all printer drivers already installed on the print server!
The trouble with this is that what to some is just part of the holy grail of network administration is to others a great frustration. The following steps will relieve that pain. Follow these steps and you too can enjoy automatic printer driver installation from your print servers. Do follow along carefully, though, because one misstep can cause the process to fail.
First, update your smb.conf file as shown in Example 15-4. The changes from the previous example have been highlighted.
Example 15-4. Samba smb.conf file for an office network
# Global parameters
[global]
workgroup = TOPCAT
netbios name = LOUDBELL
passwd chat = *New*Password* %n\n *Re-enter*new*password* %n\n *Password*changed*
username map = /etc/samba/smbusers
syslog = 0
name resolve order = wins bcast hosts
printcap name = CUPS
cups options = raw
show add printer wizard = Yes
add machine script = /usr/sbin/useradd -s /bin/false -d /dev/null '%u'
logon script = scripts\logon.bat
logon path =
logon home = \\%L\%U
logon drive = H:
domain logons = Yes
printer admin = jbloggs
preferred master = Yes
wins support = Yes
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[printers]
comment = SMB Print Spool
path = /var/spool/samba
guest ok = Yes
use client driver = No
printable = Yes
default devmode = Yes
browseable = No
[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
guest ok = Yes
[officedata]
comment = Office Files
path = /data/office
read only = No
When the smb.conf file has been edited as shown, verify that Samba is running.
In our example smb.conf file, we have specified that the Windows user jbloggs will have the rights to manage printers.
The next step is to create the /var/lib/samba/drivers directory, as well as the sub-directories beneath it. This is where the Windows printer driver files will be stored. These steps will suffice:
linux:~ # mkdir -p /var/lib/samba/drivers
linux:~ # cd /var/lib/samba
linux:~ # mkdir -p drivers/{W32ALPHA,W32MIPS,W32PPC}
linux:~ # mkdir -p drivers/{W32X86/{2,3},WIN40,COLOR,IA64,x64}
linux:~ # chown -R jbloggs:root drivers
linux:~ #chmod -R u+rwx,g+rwx,o+rx-w drivers
Install the Linux system printers that you wish to make available for use by MS Windows clients. It does not matter which print spooling and management system you use. LPRng is good, but CUPS has more bells and whistles. In any case, it is a good idea to enable raw-mode printing, even where you do not intend to use it. By enabling raw-mode printing, you may save yourself frustration in the event that some printer driver installed later on a Windows client creates print-job output that can not be handled by a CUPS print filter.
Now you are ready to install the printer drivers onto your Samba server. Keep the printer drivers available within easy reach during the following procedure.
1. Log on to your Windows XP workstation as the Windows user account jbloggs.
2. Launch the My Network Places icon by right-clicking it, and select the Explore option.
3. Browse to the Entire Network, and then to the Microsoft Windows Network. Select the domain or workgroup containing your Samba server. Click on the entry for your Samba server (in our case this is the machine TOPCAT).
4. Click the icon for Printers and Faxes. In the right panel of the Windows Explorer you should now see the printers that have been made available through the Linux printing system.
5. Right-click the icon for the printer that you wish to install drivers for. This will bring up a dialog panel that announces "Device settings cannot be displayed. The driver for the specified printer is not installed, only spooler properties will be displayed. Do you want to install the driver now?" Two choices are displayed: Yes (or Continue, on some systems) and No. Click the No button. Do not click the Yes or the Continue button.
6. Click the Advanced tab of the Windows printer properties panel that is displayed.
7. Click the New Driver button. This will open a printer driver selection panel. Select the printer manufacturer and type, as is appropriate. If you need to install a driver from a CD-ROM or a network share, click the Have Disk button.
8. Follow the prompts in the following dialog boxes. Take careful note as the drivers are being installed; they should be sent to the Samba server (in our case, the network path is \\TOPCAT\print$\W32X86). At the conclusion of the last drive installation action, the panel can be closed. Congratulate yourself.
As a side effect of the network server printer driver installation process, the printer will also be installed on the workstation that was used to install the network printer drivers. When you visit the next Windows XP workstation, simply click on the printer in the My Network Placesenvironment and it should be installed without prompting for driver installation.
Using smbsh for Direct File Manipulation on Remote Systems
The smbsh utility lets you manipulate files on a remote system using standard Unix or Linux commands. To use this command wrapper, execute smbsh from the prompt and enter the username and password that authenticates you to the machine running the Windows NT operating system. Startup looks like this:
system$ smbsh
Username: user
Password:XXXXXXX
You can now enter commmands on the remote system as if it were local. For example, the command ls /smb shows a list of workgroups, and the command ls /smb/MYGROUP shows all the machines in the workgroup MYGROUP. The command ls /smb/MYGROUP/machine-name shows the share names for that machine. You could also use the cd command to change directories, vi to edit files, and rcp to copy files.
smbsh depends on a facility of dynamic library linking known as pre-loading, and uses a pre-loaded library called smbwrapper.so. This library intercepts filesystem function calls and routes them through a CIFS/SMB library if the files being operated on lie within the /smb directory. (If a file lies outside the /smb directory, the wrapper passes the filesystem function calls on to the standard system library as if the wrapper had not been in place.) Thus, any dynamically linked command you execute from the smbsh shell accesses the /smb directory using the SMB protocol.
There are two distinct implementations of smbsh in the Samba Version 3 tarball. One of them is built from the Samba source directory. The other is located in the examples directory. The version located in the source directory is the original standalone implementation, which no longer works on Linux systems but continues to be in use on such traditional platforms as Sun Solaris, HP-UX, and AIX. It no longer works on Linux because of a decision made by the glibc maintainers to change its behavior some time around glibc Version 2.1.
The implementation of smbsh that is found in the examples directory of the Samba tarball does work, although it has a bug. This version uses the libsmbclient library. As a result of the bug in this implementation of smbsh, it is only possible to list files by performing the ls operation from outside the /smb virtual directory that the utility creates. It is not certain at this time when this bug may be fixed by the Samba Team.
Despite the niggling challenges of the smbsh facility, it continues to be used by a number of applications that do not natively support CIFS/SMB and yet need it. This tool may be the only method of supporting CIFS/SMB if the application cannot be updated to use the libsmbclient library directly.
NFS Configuration and NIS
When TCP/IP is configured, most Linux distributions support the Network File System (NFS) and the Network Information Service (NIS). NFS allows your system to share files directly with a network of machines. File access across NFS is transparent; you simply access the files as if they were stored on your local disk. In system administration terms, one system mounts another's filesystem on a local directory, just as a local filesystem can be mounted. NFS also allows you to export filesystems, allowing other systems on the network to mount your disks directly.
NIS is a system that allows your host to obtain information automatically on user accounts, groups, filesystem mount points, and other system databases from servers on the network. For example, let's say you have a large collection of machines that should have the same user accounts and groups (information usually found in /etc/passwd and /etc/group). Users should be able to log in to any of these machines and access their files directly (say, by mounting their home filesystem from a central location using NFS). Obviously, maintaining user accounts across many machines would be problematic; in order to add a new user, you would need to log in to each machine and create the user account on each. When you use NIS, however, the system automatically consults centrally maintained databases across the network for such information, in addition to local files such as /etc/passwd. NIS+ is an enhanced NIS service that is coming into use at some sites.
There are two sides to NFS. It is possible to export parts of the filesystem on your server or workstation so that other users can access its files and directories, and it is possible to mount remote resources on your workstation, or server, so they are available locally in like manner to local physical disk resources. NFS resources are exported by an NFS server. Locally mounted NFS resources are available on an NFS client.
You should be aware that NFS provides absolutely no encryption. If you mount your filesystems over the Internet, the transferred files can be interfered and even tampered with at any time (some people joke that NFS is short for "No File Security"). On the other hand, NFS mounts beyond your local network are probably too slow to be useful anyway, unless you are on a really big pipe.
If your Linux system is to interact with other systems on a LAN, it's quite possible that NFS and NIS are in wide use on your LAN. In this section, we show you how to configure your system as an NFS and NIS client—that is, to mount remote filesystems and to participate in an existing NISdomain. It is possible to configure your system as an NFS and NIS server, but many subtle issues are involved in configuring a system as an NFS or NIS server. Instead of providing a dangerously incomplete account of server configuration here, we refer you to O'Reilly's Managing NFS and NIS by Hal Stern. If you are already familiar with NFS/NIS configuration on other Unix systems, Linux is really no different; the manual pages and Linux HOWTO documents provide all the specifics.
Configuring Your System as an NFS Client
A few words of warning about NFS. First of all, the client is not very happy when the servers for remote filesystems go down or the network connection fails. When the NFS server is unreachable for any reason, your system prints warning messages to the console (or system logs) periodically. If this is a problem, use the standard umount command (introduced in Chapter 10) to unmount any remote filesystems offered by the affected servers.
Another detail to watch out for when mounting NFS filesystems is the user IDs (uids) and group IDs (gids) of the files on the remote filesystem. In order to access your own files via NFS, the user and group IDs for your own account must match those on the NFS server. One easy way to check this is with an ls -l listing: if the uid or gid does not match any local user, ls displays the uid/gid of files as numbers; otherwise, the user or group name is printed.
If IDs do not match, you have a few ways to remedy this problem. One is to simply change the uid of your user account (and the gid of your primary group) to match those on the NFS server (say, by editing your local /etc/passwd file). This approach requires you to chown and chgrp all your local files after making the change. Another solution is to create a separate account with matching uid/gid. However, the best approach may be to use NIS to manage your user and group databases. With this solution, you do not create your user and group accounts locally; instead, they are provided to you by an NIS server. More on this later.
Another NFS caveat is the restriction of root permissions on NFS-mounted filesystems. Unless the NFS server explicitly grants your system root access on NFS-mounted filesystems, you will not have total access to files when logged in as root on your local system. The reason for this is security: allowing unlimited root access to files on a remote-mounted NFS filesystem opens itself up to abuse, especially when the NFS server and the NFS client are maintained or owned by different people.
NFS clients can make use of exported NFS resources in a number of ways:
§ Automatic boot-time mounting through the /etc/fstab file
§ Manual mounting from a shell command line
§ Automated mount via the automount daemon
Discussion of the automount daemon is beyond the scope of this chapter; refer to Chapter 10 for further information. The next sections contain a simplified overview of the two other methods.
Using /etc/fstab NFS client entries
Configuring your system to mount remote filesystems over NFS is a breeze. Assuming that you have TCP/IP configured and that hostname lookup works correctly, you can simply add a line to your /etc/fstab file such as the following:
# device directory type options dump fsckorder
allison:/usr /fsys/allison/usr nfs defaults 0 0
This line is similar to fstab for partitions on a local system, but the name of the remote system appears in the first column, and the mount type is nfs. This line will cause the remote /usr on the machine allison to be mounted at boot time at the directory mount point /fsys/allison/usr.
As with regular filesystem mounts, be sure to create the mount-point directory (in this case, /fsys/allison/usr) before letting the system mount the remote directory. The line in the /etc/fstab example allows your system to mount the directory /usr from the machine allison on the network.
The mount can be specified with various options. Two commonly used options are soft and hard. The soft mounting option means that when a file access request fails, the NFS client will report an error to the process that makes the request. Some application handle that error report gracefully, and some do not. The hard mounting option means that the NFS client will hang when the NFS server ceases to respond to file access requests. You should read the manpage for the mount on your Linux system to explore the finer points of each of the possible options.
Don't forget to check the ro and rw options as well. When exporting a directory, the administrator may choose to make the directory available for read-only access, in which case you will not be able to write to the filesystem when mounted on your system. In this case, you should set theoptions field of the /etc/fstab line in the previous example to ro instead of defaults.
Make sure the administrator of the remote system has exported the desired directory (see "Adding a directory to the NFS server's exports," later in this chapter) and test your configuration by issuing a mount as root:
# mount allison:/usr
Finding NFS exported resources and diagnosing problems
Sometimes you know that there should be an NFS filesystem resource (a share) on a particular server, but you do not know whether the NFS server is running, or perhaps you do not know the correct name of the shared resource. Here is an example to show how you can find out what is available. In this example there are three NFS servers: merlin, frodo, and sunsol. Let's see what NFS resources are available on each.
The utility that can be used to examine the availabilty of NFS services is called showmount. This tool is normally only available to the root user. We will examine all three machines as shown here:
linux:~ # showmount -e merlin
Export list for merlin:
/srv *.myworld.org,192.168.1.0/24
/data *.myworld.org,192.168.1.0/24
The machine merlin has two NFS exports. They may be used only by NFS clients in the myworld.org domain, as well as from any IP address in the 192.168.1.0 network. Let's see what surprises the machine sunsol has for you:
linux:~ # showmount -e sunsol
Export list for sunsol:
/export (everyone)
The /export directory has been exported to the whole world. It is just as well that this resource is inside a private network and not on a machine that is exposed to the Internet. Just for the record, anyone can mount an export that is world-readable. If it is also capable of being written, that does not make for a particularly secure system!
Finally, let's see what happens when we request NFS export information from a server on which the NFS server service is not running. Let's ask the machine frodo, on which the NFS has apparently failed or has been stopped for some reason:
linux:~ # showmount -e frodo
mount clntudp_create: RPC: Program not registered
You can see that the Remote Procedure Call (RPC) process over which NFS resources are shared is not running. RPC is a protocol for client-server communication. It is possible to check what RPC services are running using the rpcinfo utility. In this case, we will check the difference in services available from the machines merlin and frodo, as shown here:
linux:~ # rpcinfo -p merlin
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100227 3 udp 2049 nfs_acl
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100227 3 tcp 2049 nfs_acl
100024 1 udp 1254 status
100021 1 udp 1254 nlockmgr
100021 3 udp 1254 nlockmgr
100021 4 udp 1254 nlockmgr
100024 1 tcp 4777 status
100021 1 tcp 4777 nlockmgr
100021 3 tcp 4777 nlockmgr
100021 4 tcp 4777 nlockmgr
100005 1 udp 645 mountd
100005 1 tcp 648 mountd
100005 2 udp 645 mountd
100005 2 tcp 648 mountd
100005 3 udp 645 mountd
100005 3 tcp 648 mountd
The nlockmgr RPC service provides file-locking capabilities over NFS-mounted connections, and the nfs_acl RPC service provides POSIX Access Control List (ACL) file security controls. Here is the result of asking the same question of the machine frodo:
linux:~ # rpcinfo -p frodo
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32768 status
100021 1 udp 32768 nlockmgr
100021 3 udp 32768 nlockmgr
100021 4 udp 32768 nlockmgr
100024 1 tcp 32768 status
100021 1 tcp 32768 nlockmgr
100021 3 tcp 32768 nlockmgr
100021 4 tcp 32768 nlockmgr
The nfs RPC service is not available. Moments later we executed the command again to obtain this result:
linux:~ # rpcinfo -p frodo
rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused
This means that the portmapper service that provides the RPC capabilities has been shut down. This may have been done to permit some maintenance procedures to be performed, or the server may be in the process of being shut down.
By now, you should be getting some clues for finding and diagnosing NFS availability as well as potential causes of NFS problems.
Manual mounting of NFS filesystems
It is possible to determine what NFS filesystems are currently mounted on your Linux system by using the mount utility:
linux:~ # mount -t nfs
merlin:/data on /data type nfs (rw,addr=192.168.1.4)
merlin:/srv on /msrv type nfs (rw,addr=192.168.1.4)
sunsol:/export on /mnt type nfs (ro,addr=192.168.1.6)
The NFS filesystem resources from the machine merlin have been mounted so that they are capable of read/write access. The resource on the machine sunsol has been mounted with read-only access capability.
Assuming you want to mount the /export/work resource from the machine sunsol on your Linux workstation at the directory mount point /home/work, here is the command to use:
linux:~ # mkdir /home/work
linux:~ #mount sunsol:/export/work /home/work
The df command will help to show that it is mounted, as well as the disk space available:
linux:~ # df /home/work
Filesystem 1K-blocks Used Available Use% Mounted on
sunsol:/export/work 17645600 3668352 13800800 21% /home/work
When it is necessary to unmount an NFS mounted resource, simply do this:
linux:~ # umount /home/work
With a little practice, you will soon be an expert at using the NFS client facilities.
Adding a directory to the NFS server's exports
As we said earlier, we will not try to tell you how to configure an NFS server, but we'll briefly explain how to export a directory once the server is running. In our example, the system administrator for the allison server must configure it to export the given directory (here, /usr) to your system. On most Unix systems, this is simply a matter of editing a file, such as /etc/exports, or running a command that edits the file. It is not necessary for the exported directory to be the root of a filesystem itself; that is, a server can export /usr even if /usr does not have its own separate filesystem.
Let's take the role of an administrator on an NFS server now and export the /data/accounts directory for use by all NFS clients in the myworld.org DNS domain. These simple steps will achieve this:
1. Create the /data/accounts directory:
2. linux:~ # mkdir -p /data/accounts
3. linux:~ # chmod 770 /data/accounts
linux:~ #chown bill:accounting /data/accounts
These commands created the exported directory (it did not exist previously), set the permissions so that group members can access the directory, and then set permissions so that the accounting group can read and write to the directory. Of course, they can also list any files that may be placed within it.
4. Create the /etc/exports file with the following contents:
/data/accounts *.myworld.org(rw,no_root_squash,sync)
Set the ownership and permissions on this file:
linux:~ # chown root:root /etc/exports
linux:~ #chmod 644 /etc/exports
Configuring Your System as an NIS Client
NIS is not a tool for file and printer sharing, but we present it in this chapter because it shares some components with its cousin NFS, and because it can make NFS easier to administer because NIS allows each user to have the same account number on all systems.
NIS is a complex system, simply because it is so flexible. It is a general-purpose network database system that allows your machine to transparently access information on user accounts, groups, filesystems, and so forth, from databases stored across the network.
One goal of NIS is to ease network management. Allowing user account information (such as that stored in /etc/passwd) to be maintained on a single server, for example, makes it easy for many machines to share the same user accounts. In the previous section on NFS, we showed how user and group IDs on the NFS server and client should match in order to effectively access your files remotely. Using NIS allows your uid and gid to be defined from a remote site, not locally.
If your machine is connected at a site where NIS is used, chances are you can add your machine as an NIS client, thus allowing it to obtain user, group, and other databases directly from the network. To some extent this makes it unnecessary to create local user accounts or groups at all; apart from the locally defined users such as root, bin, and so forth, all other users will be created from the NIS server. If you couple the use of NIS with mounting user home directories from an NFS server, it's also unnecessary to set aside local storage for users. NIS can greatly lessen the amount of work you need to do as a system administrator.
In an NIS configuration, there may be NIS servers, slaves, and clients. As you can guess, servers are the systems where NIS databases originate and are maintained. NIS slaves are systems to which the server copies its databases. The slaves can provide the information to other systems, but changes to the databases must be made from the server. Slaves are simply used as a way to ease the load on the NIS server; otherwise, all NIS requests would have to be serviced by a single machine. NIS clients are systems that request database information from servers or slaves.
To completely discuss how NIS works and how to maintain an NIS server requires enough material for a whole book (again, see Managing NFS and NIS). However, when reading about NIS you are likely to come across various terms. NIS was originally named Yellow Pages. This usage has been discontinued because Yellow Pages is trademarked in the United Kingdom (it's the phone book, after all), but its legacy can still be seen in commands containing the letters yp.
There are at least two implementations of NIS for Linux: the "traditional" NIS implementation and a separate implementation known as NYS (standing for NIS+, YP, and Switch). The NIS client code for the "traditional" implementation is contained within the standard C library and is already installed on most Linux systems. (This is necessary to allow programs such as login to transparently access NIS databases as well as local system files.) The glibc2 standard C library that most distributions use these days comes with support for NIS+. The NYS client code is contained within the Network Services Library, libnsl. Linux systems using NYS should have compiled programs such as login against this library.
Different Linux distributions use different versions of the NIS or NYS client code, and some use a mixture of the two. To be safe, we'll describe how to configure a system for both traditional NIS and NYS implementations, meaning that no matter which is installed on your system, it should be able to act as a client.
To make matters even more complex, some distributions employ the PAM (Pluggable Authentication Modules) system, mentioned in "PAM and Other Authentication Methods" in Chapter 11. In this case, programs such as login are linked against the PAM library, which in turn loads a PAMlibrary module that implements the authentication system in use on the system, or delegates the task to other libraries.
We assume here that an administrator on your local network has installed and started all the necessary NIS daemon processes (such as ypbind) used by traditional NIS to talk to the NIS server. If your Linux system does not appear to have any NIS support, consult documents such as the LinuxNIS HOWTO to configure it from scratch. Nearly all current Linux distributions come prepackaged with NIS client (and server) support, and all that's required of you is to edit a few configuration files.
The first step is to set the NIS domain in which your system will be operating. Your network administrator can provide this information to you. Note that the NIS domain name is not necessarily identical to the DNS domain name, which can be set with the hostname command. For example, if the full hostname of your system is loomer.vpizza.com, your DNS domain name is vpizza.com. However, your NIS domain name could be entirely different—for example, vpizzas. The NIS domain name is selected by the NIS server administrators and is not related to the DNS domain name described earlier.
Setting the domain name is usually a matter of running the domainname command at boot time, perhaps in one of your system rc files (such as /etc/rc.d/rc.inet1, described earlier). You should first check that domainname is not being executed in one of the existing rc files. The command takes the format.
linux:~ # domainnamedomain-name
An example is domainname vpizzas. The command is usually found in /sbin/domainname and may have a slightly different name, such as domainname-yp.
A slightly different method sets the domain name under NYS. You should create (or edit) the file /etc/yp.conf. This file should contain two lines: one specifying the name of your NIS domain, and another specifying the hostname of the NIS server. As an example:
linux:~ # domain vpizzas
linux:~ #ypserver allison.vpizza.com
sets the NIS domain name to vpizzas and specifies that allison.vpizza.com should be used as the NIS server. If no ypserver line is included in this file, the system broadcasts a message on the network at boot time to determine the name of the NIS server. Your network administrator can provide you with the hostname of your preferred NIS server.
Once these two steps are complete, your system should be able to transparently access NIS databases. One way to test this is to query the system for a password database entry from the NIS server. The ypwhich command queries specific NIS databases. For example:
linux:~ # ypwhichusername passwd
If this returns the line from the NIS passwd database for the given user, you have successfully queried the NIS database. (One way to verify that the information returned is correct is to run this same command on another system in your NIS domain whose NIS configuration is known to be working.) The NIS passwd database is not identical to the /etc/passwd file on your system, although it is in the same format. The Linux HOWTO documents contain additional information on troubleshooting your NIS configuration.