Chapter 16: Windows Networking

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 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.

    Some good books on setting up and administering Samba include

    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 -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 __MSBROWSE__<01> __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
    querying on
    name_query failed to find name

    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
    Looking up status of
        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 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
    Looking up status of
        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 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 in Microsoft’s Knowledge Base.

    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 *<00> *<00> *<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 -L (or --list) option, followed by the NetBIOS name or IP address. When prompted for a password, simply press Enter.

    $ smbclient -L ELIOT
    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.


    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
    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 -U option.

    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
    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 -A (or --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).

    Table 6.1: Important smbclient Commands
    cd Change directory
    exit Close the connection to the Samba server
    get Copy the specified file to the local machine
    help Get help on commands
    lcd Change the directory on the local machine
    ls List files in the working directory on the Samba server
    mget Copy all files matching a pattern to the local machine
    mkdir Create a new directory on the Samba server
    mput Copy all files matching a pattern to the Samba server
    put Copy the specified file to the Samba server
    rm 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: 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”).


    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 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:

    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.


    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/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 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 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.


    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.

    WebSanity Top Secret