Section 15.1. Sharing Files with Windows Systems (Samba)
15.1. 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 lastnot because it is less important, but because the scope of possibilities it offers is so much greater. 15.1.1. Protocols and Things Windows-RelatedLinux 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 saywith perhaps a little poetic licensethat 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:
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/SPXthe 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.
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.
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:
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 in C:\Windows\System. On Windows NT/2000/XP systems it is located in C:\Winnt\System32\drivers\etc\hosts.
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. 15.1.2. Linux System Preparation and Installing SambaThe 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 regarding cifsfs 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.
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:
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.
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. 15.1.3. Accessing Remote Windows Files and PrintersSoon 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. 15.1.3.1. Using the FTP-like smbclient to access WindowsIt 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:
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. 15.1.3.2. Using Linux-kernel-based smbfsBefore 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 handyas 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. 15.1.3.3. Using Linux-kernel-based cifsfsThe 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 the smbmount 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.
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. 15.1.3.4. Using Linux desktop tools with libsmbclientOffice 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, and libsmbclient 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 instead libsmbclient 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. 15.1.3.5. Printing to printers on Windows systemsIn 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 directory examples/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 use smbprint 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:
Each parameter should be in the order listed. 15.1.4. Sharing Linux Files and Printers with Windows UsersThe 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.
Setting up Samba involves the following steps:
When correctly configured, a Samba server and the directories shared will appear in the browse lists of the Windows clients on the local networknormally 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. 15.1.4.1. Installing SambaCorrectly 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:
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:
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.
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.
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 file samba-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:
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 15.1.4.2. Configuring SambaThe 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
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.
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 no because 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. 15.1.4.3. Starting the Samba serverSamba essentially consists of three daemons , of which two are always needed:
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 accounthowever, 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.
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.
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 distributionbut 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 0A 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 esacValidating 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. 15.1.4.4. Adding usersNetwork 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 -m username 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 -a username 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. 15.1.5. An Office File- and Print-Sharing Solution Using SambaNow 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 Sambadespite not being developed just for Linuxis one of the software packages that have made Linux famous. 15.1.6. Automatic Printer Driver DownloadWindows 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 driversInstall 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.
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 Places environment and it should be installed without prompting for driver installation. 15.1.7. Using smbsh for Direct File Manipulation on Remote SystemsThe 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. |
EAN: 2147483647
Pages: 220