Using smbclient
smbclient is samba client with an "ftp like" interface. It is a useful tool to test connectivity to a Windows share. It can be used to transfer files, or to look at share names. In addition, it has a nifty ability to 'tar' (backup) and restore files from a server to a client and visa versa. Let's begin by starting a session to the Windows server:
smbclient "serviceName" [options]
In the case of the service name, this would be the conventional means of "mapping" a service in the Windows environment using the "net" command:
c:\net use P: \\some--Windows-server\some-share-name
The major difference here though is this: In the shell, the '\' has special meaning. Thus, there are three means of "getting around this". Firstly, we could quote the service name:
smbclient '\\Billy-the-machine\some-share'
secondly, we could escape each '\' like:
smbclient /\/\Billy-the-machine/\some-share
or finally, we could just use double the number of '\' as in:
smbclient \\\\Billy-the-machine\\some-share
Any which way will do. Using too few '\' will result in an error. Options that can be used are usernames, connection to a printer service, Etc.
smbclient \\\\Billy-the-machine\\some-share -U jwhittal
This will connect me to the share named "some-share" on Billy-the-machine with the username jwhittal. You will be prompted for a password. We'll return to this in a moment.
One means of finding out what the shares on the host machine are is by using the -L switch. Assuming the Windows server is 172.16.1.3, a command such as:
smbclient -L 172.16.1.3
will yield:
Domain=[WORKGROUP] OS=[Windows 5.0] Server= \
[Windows 2000 LAN Manager]
Sharename Type Comment
--------- ---- -------
IPC$ IPC Remote IPC
ADMIN$ Disk Remote Admin
C$ Disk Default share
Server Comment
--------- -------
006097EFC730
Workgroup Master
--------- -------
QEDUX IPENGUINI
WORKGROUP 006097EFC730
This show that the default shares on the machine (172.16.1.3) are the IPC$ share, the ADMIN$ share and the C$ share. Now that we know the shares, let's connect to one - c$.
smbclient \\\\172.16.1.3\\c$ -U jwhittal
smbclient now offers us a prompt, similar to that offered by an ftp session. Simply typing "help" should show us all the commands we can use to 'put' and 'get' files. Once on the host server (the Windows machine), try putting your /etc/hosts file:
put /etc/hosts
It should transfer it elegantly to the Windows machine. Getting files from the remote side is just as easy:
get pdf995\setup.exe
What makes smbclient really nifty is the ability to "tar" up whole subdirectories from one machine to another. In interactive mode (i.e. When there is a smb: \> prompt), one can simply set the "tarmode" flag, as well as the "recurse" and "prompt" toggles, as these will allow us to copy large volumes of data from one machine to another. So, the following commands will copy the pdf995 directory from the Windows server to the Linux client:
smbclient \\\\172.16.1.3\\c$ -U jwhittal smb: \" tarmode smb: \" lcd /tmp smb: \" recurse smb: \" prompt smb: \" mget pdf995/
And bingo, the entire directory get transferred to your Linux host. Naturally, transferring in the reverse direction is just as easy, only this time we can use a 'put' rather than a 'get'.
Another powerful feature is the ability to make these type of transfers in a non-interactive manner.
smbclient \\\\172.16.1.3\\c$ -U jwhittal -Tc backup.995.tar pdf995/
What this will do is to create (c) a tar (T) file called backup.995.tar of the directory on the Windows server pdf995/. Notice that despite Windows using a '\' for it's directory delimiter, the smbclient uses the '/' when specifying the directory. Once the tar begins, there is no problem with this, as the output below illustrates (notice here the correct Windows directory delimiter of '\'):
Domain=[WORKGROUP] OS=[Windows 5.0] Server= \
[Windows 2000 LAN Manager]
directory \pdf995\
5386 ( 142.2 kb/s) \pdf995\readme.html
directory \pdf995\res\
200 ( 7.5 kb/s) \pdf995\res\995.bat
directory \pdf995\res\convert\
34871 ( 396.0 kb/s) \pdf995\res\convert\a010013l.pfb
36354 ( 417.7 kb/s) \pdf995\res\convert\a010015l.pfb
35156 ( 377.3 kb/s) \pdf995\res\convert\a010033l.pfb
36128 ( 452.3 kb/s) \pdf995\res\convert\a010035l.pfb
....
and restoring that file we deleted by accident:)
smbclient \\\\172.16.1.3\\c$ -U jwhittal \
-Tx backup.995.tar ./pdf995/readme.html
So here ends the small chat on smbclient. What makes it so nice is that is can be used to test connectivity to a Windows network. Furthermore, if you set up a SAMBA server and have no Windows clients to test on it (as in the RedHat Certified Engineer Exam), smbclient will do just fine in ensuring your configurations work as stated. Of course, if you plan on setting up SAMBA at all, you should really have Windows clients on which to use it, otherwise all the Linux/UNIX style applications (NIS, NFS and friends) fill the gap occupied by SAMBA. Smbmount/smbumount
Once we have established that a Windows machine has some worthwhile stuff to share, it might be nice to have that available at our fingertips each time we use our Linux machine. Perhaps the Windows server is sharing music, or video, or perhaps better still, a software repository. Smbclient has it's uses, but it might be undesirable to transfer this information back and forth as we find a use for it. In this case, a simple answer is to mount these drives on the Linux host as we would any other drive. This is simple to achieve - and works in a fairly similar fashion to what NFS might in an all UNIX environment.
smbmount \\\\172.16.1.3\\c$ /mnt/thumb -o username=jwhittal
This time, the smbmount command takes the share name, a mount point (/mnt/thumb in my example above) and finally some options. Clearly, since C$ is not a guest based share (and so it should not be), I will need to supply a username for the share. I will be prompted for the password for the user "jwhittal". Since this 'drive' is now mounted, we can begin copying information to and from the mount point. Clearly, this implies that it is being copied to the Windows server. One might additionally place this in the /etc/fstab file on your Linux client workstation and therefore have the Windows share reloaded on every reboot of the Linux client workstation.
Smbumount is the command used to unmount the Windows share. In fact, smbmount and smbumount are just synonyms for the mount and umount commands in Linux. An alternative to the smbmount command above is:
mount -t smbfs -o username=jwhittal \\\\172.16.1.3\\c$ /mnt/thumb
Clearly, this would require that the smbfs module is compiled into the kernel and that it is able to mount SAMBA file systems. Nmblookup
nmblookup is a command that can be used to do a number of meaningful operations. In the example below, it shows us that this workstation is the master browser for this workgroup, that this machine is a member of the workgroup domain "WORKGROUP", and that the user who is currently logged into this workstation is "jwhittal".
nmblookup -A 172.16.1.3 Looking up status of 172.16.1.3 006097EFC730 "00" - B "ACTIVE" WORKGROUP "00" - "GROUP" B "ACTIVE" 006097EFC730 "20" - B "ACTIVE" 006097EFC730 "03" - B "ACTIVE" WORKGROUP "1e" - "GROUP" B "ACTIVE" WORKGROUP "1d" - B "ACTIVE" ..__MSBROWSE__. "01" - "GROUP" B "ACTIVE" JWHITTAL "03" - B "ACTIVE"
In the example below, the -M option indicates which machines are eligible to be master browsers on the network.
nmblookup -M -- - querying __MSBROWSE__ on 172.16.1.255 172.16.1.3 __MSBROWSE__"01" 172.16.1.1 __MSBROWSE__"01"
Smbtar
This is a useful command when you require your Windows system to be backed up to a Linux/UNIX client machine with a tape drive. Smbtar will tar the data to the tape that is on the Linux/UNIX system.
This, in a nutshell, is a summary of some of the SAMBA client utilities. They not only allow a Linux machine to operate seamlessly with other hosts on the network, but they offer the ability to treat Windows shares as something akin to NFS in Linux. Thus, it becomes a simple operation to work in an all-Windows environment.