Samba is one of the most important open-source projects in the world because it makes it possible for Linux (and other UNIX machines, such as Mac OS X) to use Server Message Block (SMB), the networking protocol used on all Microsoft Windows machines. With Samba, UNIX machines can connect to and mount shares on Windows machines, and print to shared printers connected to Windows machines. UNIX machines can also set up Samba-based printer and file shares that Windows machines can connect to and use. In fact, Samba is so useful that you don’t even need Windows machines in the equation. You might choose to implement Samba for file and printer sharing on a network of Linux machines because it works so well.

Many good books cover how to set up Samba on a server, so we’re not going to cover administrative commands such as smbd, smbcacls, or smbpasswd (which, it is true, can be run by normal users to change their own passwords, but in practice is almost always run by the Samba server admin), or how to configure smb.conf. Instead, this chapter assumes you already have SMB shares set up on a Windows, Linux, or Mac OS X machine. You’re instead going to focus on the client end of things: how to find out where those shares are, how to connect to those shares, and how to mount shares on your hard drive.

Discover the Workgroup’s Master Browsers

nmblookup -M [Master Browser]

nmblookup -S [NetBIOS name]

nmblookup -A [IP address]

A Samba server actually uses two daemons: smbd, which makes the shares available, and nmbd, which maps the NetBIOS names that identify machines using SMB to their IP addresses, thus making it possible to find and browse SMB shares. You’re going to focus for now on commands that communicate with nmbd, used to gain some overall information about the Windows workgroup you’re querying.

In a Windows workgroup, you need a machine that keeps track of the other members of the workgroup—what their SMB names and IP addresses are, for instance. That machine is known as the Master Browser. But which computer in a workgroup is the Master? The one that is elected, based on the operating system it’s running. The latest and greatest OS always wins, so XP will always beat 2000, which will always beat 98.

When setting up a Samba server, however, it’s possible to configure things so the server always stays out of any such election, letting other machines duke it out, or set things up so that the server always wins any election. You could go ahead and start connecting to Samba shares if you knew about them, but it helps to know where your Master Browsers are in case you have any issues.

To query your network for a Master Browser, run nmblookup with the -M (or --master-browser) option, followed by a - at the end, which basically means “find me a Master Browser.” The problem is that you can’t use a - on the command line, or the shell thinks it’s the start of an option. So you need to preface it with -- first, which tells the shell that the following - is in fact a -, and not part of an option.

$ nmblookup -M -- -
querying __MSBROWSE__ on 192.168.1.255
192.168.1.151 __MSBROWSE__<01>
192.168.1.104 __MSBROWSE__<01>

This isn’t good. In your case, you appear to have two Master Browsers on one network, which can be a real problem because different Masters might know about different machines at different times, causing mass confusion to users. One minute a user can get to a machine, and the next it’s gone. Why? Because one Master knows about the machine, but the other doesn’t. Try explaining that to Bob in Accounting. Yipes.

To get more information about the Master, use nmblookup with the -S (or --status) option, which returns the SMB names the host uses.

$ nmblookup -S 192.168.1.151
querying 192.168.1.151 on 192.168.1.255
name_query failed to find name 192.168.1.151

That didn’t work because -S expects a NetBIOS name instead of an IP address. Unfortunately, you don’t know the machine’s NetBIOS name, only its IP address. Actually, that’s not a problem. You simply add the -A (or --lookup-by-ip) option, which tells nmblookup that you’re giving it an IP address instead of a NetBIOS name.

$ nmblookup -SA 192.168.1.151
Looking up status of 192.168.1.151
    JANSMAC         <00> -         B 
    JANSMAC         <03> -         B 
    JANSMAC         <20> -         B 
    ..__MSBROWSE__. <01> -  B 
    MILTON          <00> -  B 
    MILTON          <1d> -         B 
    MILTON          <1e> -  B 

    MAC Address = 00-00-00-00-00-00

Now you know that the machine at 192.168.1.151 identifies itself as JANSMAC (it must be a Mac OS X box) and is the Master for the MILTON workgroup. What about the other IP address?

$ nmblookup -SA 192.168.1.104
Looking up status of 192.168.1.104
    ELIOT           <00> -         B 
    ELIOT           <03> -         B 
    ELIOT           <20> -         B 
    ..__MSBROWSE__. <01> -  B 
    TURING          <00> -  B 
    TURING          <1d> -         B 
    TURING          <1e> -  B 

    MAC Address = 00-00-00-00-00-00

The computer found at 192.168.1.104 has a NetBIOS name of ELIOT, and is the Master for the TURING workgroup. So actually you have nothing to worry about, as the two machines are each a Master for a separate Workgroup. Machines that self-identify as members of MILTON look to JANSMAC for information, while those that consider themselves part of TURING use ELIOT for the same purpose.

Query and Map NetBIOS Names and IP Addresses

nmblookup -T

You can use nmblookup as a quick way to find any machines that are sharing files and printers via Samba. Append the -T option to the command, followed by "*" (and yes, you must include the quotation marks to tell the shell that you’re not using the * as a wildcard representing the files in your current working directory).

$ nmblookup -T "*"
querying * on 192.168.1.255
192.168.1.151 *<00>
192.168.1.104 *<00>
192.168.1.10 *<00>

Three machines are on this LAN with Samba shares. To find out which of those are Master Browsers, see the previous section; to produce a list of the shares offered by each computer, proceed to the next section.

List a Machine’s Samba Shares

smbclient

So you know that a machine has Samba shares on it, thanks to the commands outlined in the previous section, but you don’t know what those shares are. The smbclient command is a versatile tool that can be used to connect to shares and work with them; at a more simple level, however, it can also list the shares available on a computer. Just use the -L (or --list) option, followed by the NetBIOS name or IP address. When prompted for a password, simply press Enter.

$ smbclient -L ELIOT
Password:
Anonymous login successful
Domain=[TURING] OS=[Unix] Server=[Samba 3.0.14a-Ubuntu]

Sharename Type Comment
--------- ---- -------
print$    Disk Printer Drivers
documents Disk Shared presentations and other files
IPC$      IPC  IPC Service (eliot server (Samba,Ubuntu))
ADMIN$    IPC  IPC Service (eliot server (Samba,Ubuntu))
Anonymous login successful
Domain=[TURING] OS=[Unix] Server=[Samba 3.0.14a-Ubuntu]
[Results truncated for length]

In this case, you can see all of the shares that are available either to an anonymous logon or have been marked as being able to be browsed in the server’s smb.conf file. To see the shares available to you if you were to log on, add the -U (or --user) option, followed by your Samba username as found on the Samba server.

$ smbclient -L ELIOT -U scott
Password:
Domain=[ELIOT] OS=[Unix] Server=[Samba 3.0.14a-Ubuntu]

Sharename Type Comment
--------- ---- -------
print$    Disk Printer Drivers
documents Disk Shared presentations and other files
IPC$      IPC  IPC Service (eliot server (Samba,Ubuntu))
ADMIN$    IPC  IPC Service (eliot server (Samba,Ubuntu))
scott     Disk Home Directories
Domain=[ELIOT] OS=[Unix] Server=[Samba 3.0.14a-Ubuntu]
[Results truncated for length]

When you log in, you now see a new share, scott—the home directory of this user. This also tells you that you can log in, which brings you to the next section, in which you log in and actually use the stuff you find on the share.

$ smbclient -L localhost

Access Samba Resources with an FTP-Like Client

smbclient

After you know the shares available on a Samba server, you can log in and start using them. Use the smbclient command, but in this format:

smbclient //server/share -U username

You can’t just log in to a server; instead, you need to log in to a share on that server. To access password-protected items (and it’s certainly advisable to password-protect your shares), you need to specify a user. To access the documents share on the server ELIOT, you’d use the following:

$ smbclient //eliot/documents -U scott
Password:
Domain=[ELIOT] OS=[Unix] Server=[Samba 3.0.14a-Ubuntu]
smb: \>

You’ll know you were successful because you’ll be at the Samba prompt, which looks like smb: \>. Notice that you’re prompted for a password. Assuming that the password for the scott user was 123456 (a very bad password, but this is just hypothetical), you could have entered this command instead, and you wouldn’t be prompted for a password:

$ smbclient //eliot/documents -U scott%123456

This is a terrible idea, however, because anyone looking at either your .bash_history file (discussed in the “View Your Command-Line History” section in Chapter 11, “Your Shell”) or the list of running processes with ps (see “View All Currently Running Processes” in Chapter 12, “Monitoring System Resources”) could see your password. Never append your password onto your username. It’s just good security practice to enter it when prompted.

username = scott
password = 123456

After you’re connected to a Samba share, you can use many of the commands familiar to those who have ever used FTP on the command line (see Table 16.1).

You can view other commands by simply typing help after you’ve logged in to the Samba server, but Table 16.1 contains the basics. When you’re finished, simply type exit, and you log out of the server and are back on your own machine.

Mount a Samba Filesystem

smbmount

It’s cool that you can use smbclient to access Samba shares, but it’s also a pain if you want to use a GUI, or if you want to do a lot of work on the share. In those cases, you should use smbmount, which mounts the Samba share to your local filesystem as though it was part of your hard drive. After it’s mounted, you can open your favorite file manager and access files on the share easily, and you can even open programs such as word processors and open the files directly with a minimum of fuss.

To mount a Samba share on your filesystem, you must create a mount point onto which Linux will graft the share. For instance, if you were going to mount the documents share from ELIOT, you might create a directory like this:

$ mkdir /home/scott/eliot_documents

Now you run the smbmount command, along with a whole host of options.

$ smbmount //eliot/documents /home/scott/eliot_documents -o credentials=/home/scott/bin/credentials_eliot,fmask=644,dmask=755,uid=1001,gid=1001,workgroup=TURING
smbmnt must be installed suid root for direct user mounts (1000,1000)
smbmnt failed: 1

Before looking at the option, let’s talk about why smbmount failed. The second line tells you why: smbmnt, which smbmount calls, can only be run by root. This can be a problem if you want your non-root users to be able to mount Samba shares. The way around that is to set smbmnt as suid root (you learned about suid in Chapter 7’s “Set and Then Clear suid”).

Here’s how to set smbmnt as suid root.

# ls /usr/bin/smbmnt
-rwxr-xr-x  1 root root 8.3K 2005-07-21 13:31 /usr/bin/smbmnt
# chmod u+s /usr/bin/smbmnt
# ls -l /usr/bin/smbmnt
-rwsr-xr-x  1 root root 8416 2005-07-21 13:31 /usr/bin/smbmnt

Now let’s try smbmount again.

$ smbmount //eliot/documents /home/scott/eliot_documents -o redentials=/home/scott/ credentials_eliot,fmask=644,dmask=755,uid=1001,gid=1001,workgroup=TURING
$ ls -F /home/scott/eliot_documents
presentations/  to_print/

Let’s walk through the command you used. After smbmount, //eliot/documents specifies the Samba server and Samba share to which you’re connecting. Then comes the path to your mount point, /home/scott/eliot_documents. The -o option indicates that options are coming next.

Instead of credentials=/home/scott/credentials_eliot, you could have used any of the following:

• username=scott,password=123456
• username=scott%123456
• username=scott

The first and second choices are completely unsafe because the password would now show up in .bash_history and ps. Don’t do that! The final choice prompts you for a password, which would be safe because the password wouldn’t appear in either .bash_history or ps. But you’re trying to automate the process of mounting the Samba share, so the last choice wouldn’t work, either.

That leaves you with credentials=/home/scott/credentials_eliot. This tells smbmount that the username and password are stored in a file, in this format:

username = scott
password = 123456

This is just like the credentials file discussed previously in “Access Samba Resources with an FTP-Like Client,” and as in that example, use chmod after you create a credentials file to tightly limit who can view that file. If you don’t care about automating the logon process, by all means, use username=scott and get prompted to enter the password, which is certainly the safest option.

The fmask and dmask options respectively control the default permissions for any new files and directories that you create in the mounted Samba share. 644 would produce rw-r--r-- for files, while 755 would end up with rwxr-xr-x for directories.

Remember that all usernames and group names are really references to numbers, which you can see in /etc/passwd and /etc/group, respectively. Your user ID number on your current machine might be 1000, but on the Samba server, 1000 could be a completely different user, with the same problem for your group ID. With uid=1001 and gid=1001, you tell the Samba server who you are on the Samba server. In other words, you need to look those numbers up in /etc/passwd and /etc/group on the Samba server, not on your local machine. If you don’t, you may create files and directories, only to find that you don’t really own them and can’t use them the way you want.

Finally, workgroup=TURING specifies the workgroup, which is obvious enough.

After the share is mounted, you can open your file manager and start browsing the contents of eliot_documents, start OpenOffice.org and directly open a file inside eliot_documents/presentations/, or open a PDF in eliot_documents/to_print and send it to the printer. If you place the following lines in your machine’s /etc/fstab file, the share is mounted automatically.

//eliot/documents /home/scott/eliot_documents smbfs credentials=/home/scott/credentials_eliot,fmask=644,dmask=755,uid=1001,gid=1001,workgroup=TURING 0 0

If you decide that you don’t want to access the Samba share at eliot_documents any longer, you can unmount it with smbumount (notice that’s umount, not unmount).

$ smbumount eliot_documents
smbumount must be installed suid root

How frustrating! You need to set smbumount as suid root, too.

$ ls -l /usr/bin/smbumount
-rwxr-xr-x  1 root root 6332 2005-07-21 13:31 /usr/bin/smbumount
$ sudo chmod u+s /usr/bin/smbumount
$ ls -l /usr/bin/smbumount
-rwsr-xr-x  1 root root 6332 2005-07-21 13:31 /usr/bin/smbumount

Now the user that mounted eliot_documents—and only that user—can unmount eliot_documents. Root can unmount it, too, because root can do whatever it wants.

$ smbumount eliot_documents

And that’s it. If you want to verify that smbumount worked, try ls eliot_documents, and there shouldn’t be anything in there. You’re disconnected from that Samba share.

Conclusion

Much as many Linux users would like to pretend that Microsoft doesn’t exist, you have to realize that (for now) you live in a Windows world. Samba makes coexistence that much easier because it allows Linux users to access resources on Windows machines, and even makes resources available on a Linux box to users of other operating systems. Microsoft might not like it very much, but Samba is a mature, stable, powerful technology, and thanks to its open-source nature, it has helped bring the entire world of computing more closely together. Samba helps you reduce the need for Windows servers in homes and businesses, and that, as a certain doyenne might say, is a good thing.