What tool does Linux use to connect to SMB?

In my previous article, Interoperability: Getting started with Samba, I covered installing and configuring Samba shares on a Linux server. The real power of Samba comes when Windows clients can communicate with Linux file servers. In this article, I will cover how you can access Samba shares from both Linux and Windows clients.

Install the Samba client packages

To access Samba share from Linux clients we need to install a few Samba client packages.

On the client machine, install the samba-common and samba-client packages.

Check for available shares

Let's check if we can access our shares from the server. We can use either the hostname or ip address of the server. If you use the hostname, make sure DNS is working.

Create a directory that we can use as our mount point. I'm going to create a directory under /mnt, but you can use any directory you would like to. You may need to configure SELinux on that directory.

Now, mount the share.

Now that we’ve mounted our share, we can check the mounts with the following command:

Persistent mount

Let's make that directory mount persistently so it can withstand a reboot. Using the text editor of your choice, edit the /etc/fstab file. You can do this in multiple ways, but I'm going to demonstrate two ways to mount the Samba share at boot in /etc/fstab.

The first option provides a username and password for the Samba user in the fstab.

The other option is to create a credential file. You can call this file anything, but I would like to call it cred. I would like to place credentials files in the home directory of the user. In our demonstration it will be /home/user/.cred.

The _netdev option is important since we are mounting a network device. Clients may hang during the boot process if the system encounters any difficulties with the network.

Now create that .cred file inside the user's home directory.

Next, add the Samba user's username and password.

Finally, mount all filesystems.

Access a share from a Windows client

I will be using Windows 10 as my client machine with a workgroup called SAMBA. We need to create a local user account on the Windows machine that matches the username and password of the Samba user account we created in my previous article. Although account creation is not necessary, this will make things simpler when accessing the share.

Like I mentioned above, this step is optional and you can skip it completely. Although there are multiple approaches to adding a new local user on a Windows machine, for the simplicity of this article I will be using PowerShell. Launch PowerShell as an administrator and issue following commands:

Now that we have created a new local user account matching the Samba user account, we can log in to Windows with our newly created user account.

Access a share from Windows Explorer

To access the Samba share from Windows Explorer, start typing the IP address to our share in the search area. I am using the hostname of the Samba server. In my case, it is centos. You can also access the share by using the IP address of the Samba server.

You might be prompted to enter the username and password to access the share if you skipped the local user creation process. If you get prompted for credentials, enter the Samba username and password we created in the previous article.

You will need to enter the Samba share path every time you want to access the share. There is a better way to access the share by mapping a drive to Samba share in Windows.

Mapping a drive to a Samba share

To map a drive to the Samba share, open PowerShell and issue following command:

Wrap up

Accessing a Samba share on Linux and Windows is easy. With this basic setup, you will be able to access file shares from client machines in your network. With somewhat more configuration, you can deploy Samba shares in a domain environment. Samba can do more than file share. If you would like to learn more about Samba, read this article about Windows and Linux interoperability. This is a basic set up, but you can do so much more with Samba.

[ Want to test your sysadmin skills? Take a skills assessment today. ]

To test access to Samba shares on a Linux or UNIX computer, users should do the following:

To access Samba from a UNIX client session:

1. Log on to the Linux or UNIX computer using the Active Directory account that has been granted access to the local computer’s zone.

2. Run the following command:

   smbclient -k -L host_name

   The smbclient program displays information about Samba and the SMB shares that are available on the local computer. For example, you should see a listing similar to the following (where s.s.s is the Samba version):

   OS=[Unix] Server=[Samba s.s.s] Sharename Type Comment --------- ---- ------- samba-test Disk IPC$ IPC IPC Service (Samba-CDC) sara Disk Home directoriesOS=[Unix] Server=[Samba s.s.s] Server Comment --------- ------- Workgroup Master -------- -------

   ARCADE MAGNOLIA

If you are able to see the Samba shares as an Active Directory user logged on to the Linux or UNIX computer that is acting as the Samba server, you should next test accessing the Samba shares from a Windows desktop. For information about performing this test, see Accessing Samba shares from a Windows desktop.

Purging and reissuing Kerberos tickets on UNIX computers

If you see an error such as NT_STATUS_LOGIN_FAILURE instead of the expected results when you run the smbclient program, you may need to purge your existing Kerberos tickets and have them reissued. Try running the following command to remove all of your Kerberos tickets:

Then run the following command to reissue tickets after you provide your Active Directory password:

You can then run the following command to list the Kerberos tickets that have been issued to you:

After verifying the Kerberos tickets you have been issued, try running the smbclient program again.

Verifying the version of Samba you are using

If purging and reissuing tickets does not resolve the problem, confirm the version of the smbstatus that is currently running using the following command:

The command should display the Samba version you have installed. For example:

(where s.s.s is the installed Samba version)

If the correct version of Samba is installed, run smbstatus again and note the names of any *.tdb files that do not exist, and try restoring them from your backup, then try running the smbclient program again.

If you don’t see the correct Samba shares

If the smbclient program does not display the Samba shares you have defined in the configuration file, you should review the settings in the smb.conf file and then restart the DirectControl agent and run the adflush command.

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:

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:

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:

secondly, we could escape each '\' like:

or finally, we could just use double the number of '\' as in:

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.

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:

will yield:

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

It should transfer it elegantly to the Windows machine. Getting files from the remote side is just as easy:

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:

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.

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 '\'):

and restoring that file we deleted by accident:)

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.

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.

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:

Clearly, this would require that the smbfs module is compiled into the kernel and that it is able to mount SAMBA file systems.

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

In the example below, the -M option indicates which machines are eligible to be master browsers on the network.

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.