On this page…
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
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.
Some good books on setting up and administering Samba include
- Sams Samba Unleashed, ISBN: 0672318628; by Steve Litt
- Sams Teach Yourself Samba in 24 Hours, 2nd Edition, ISBN: 0672322692; by Gerald Carter
- and The Official Samba-3 HOWTO and Reference Guide at http://samba.org/samba/docs/man/Samba-HOWTO-Collection is excellent.
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.
The following examples assume you’re using a Windows workgroup, and not a domain. A workgroup is essentially a small group of machines that choose to identify themselves as belonging together by self-identifying as members of the workgroup. A domain uses a central server—or several servers in a large network—to authenticate computers and users who want to join the network. Domains are large, hairy, complicated beasts, and you’re best referred to the books referenced in this chapter’s introduction if you want to learn more about them.
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
--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
--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
--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.
For more information about what the output in these examples means, see http://support.microsoft.com/kb/q163409 in Microsoft’s Knowledge Base.
Query and Map NetBIOS Names and IP Addresses
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
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
--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
--user) option, followed by your Samba username as found on the Samba server.
Your Samba username might or might not be the same as your Linux (or Windows or Mac OS X) username on the Samba server. You need to look on the Samba server to make sure.
$ 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.
If you want to test the shares you just created on a Samba server, an excellent method is to open a shell on that box, and then enter the following:
$ smbclient -L localhost
When prompted for a password, press Enter. This way you can quickly see if the new share you added is available. Of course, if you didn’t make the share open to browsing, you’ll need to log on as a user who can view that share using the
Access Samba Resources with an FTP-Like Client
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.
If you’re writing a script and you need to log in without interaction, you still shouldn’t append the password onto the username. Instead, use the
--authentication-file=[filename]) option, which references a credentials file. Using the
scott user, that file would contain the following:
username = scott password = 123456
Make sure you use
chmod (see Chapter 7, “Ownerships and Permissions”) to set the permissions on that file so it isn’t readable by the world.
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).
||Close the connection to the Samba server|
||Copy the specified file to the local machine|
||Get help on commands|
||Change the directory on the local machine|
||List files in the working directory on the Samba server|
||Copy all files matching a pattern to the local machine|
||Create a new directory on the Samba server|
||Copy all files matching a pattern to the Samba server|
||Copy the specified file to the Samba server|
||Remove the specified file from the Samba server|
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
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:
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
suid root (you learned about suid in Chapter 7’s “Set and Then Clear
Yes, you’re giving ordinary users the ability to use
smbmnt as though they were root, but it’s not really a big problem. It’s certainly better than giving them the root password, or requiring your participation every time they want to mount a Samba share.
Here’s how to set
# 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 //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
//eliot/documents specifies the Samba server and Samba share to which you’re connecting. Then comes the path to your mount point,
-o option indicates that options are coming next.
credentials=/home/scott/credentials_eliot, you could have used any of the following:
The first and second choices are completely unsafe because the password would now show up in
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
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.
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.
Don’t recall what we’re talking about? Take a look back at “Understand the Basics of Permissions” in Chapter 7.
Remember that all usernames and group names are really references to numbers, which you can see in
/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
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/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.
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
Be very careful changing your
/etc/fstab file because mistakes can render your system unbootable. Sure, you can fix that problem (see my book Hacking Knoppix for some tips) but it’s still a pain that would be better to avoid with caution and prudence. For more on the
fstab file, see
man fstab on your system.
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
$ smbumount eliot_documents smbumount must be installed suid root
How frustrating! You need to set
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.
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.