Paranoid Penguin - Samba Security, Part IV

Creating restricted shares on your secure Samba file server.
Using mount.cifs for Persistent Samba Mounts

Now that I've got a restricted share available to me, suppose it will contain things I need to read and change on a regular basis. Do I need to access it via an interactive smbclient shell every time?

Of course not. The ability to mount remote Samba shares as though they were local volumes is one of the best things about Samba. You can do this by using the standard mount command, along with Samba's mount.cifs module, on your Samba client systems.

On Red Hat-derived and SUSE systems, the cifs filesystem and associated utilities are included with the standard samba-client package. On Debian, Ubuntu and other Debian derivatives, however, you'll need to install the package smbfs.

Although based on the same protocols, smbfs and cifs are actually two different things. cifs is newer than smbfs, and the smbmount command formerly used for mounting Samba file shares via the smbfs filesystem has been deprecated by the Samba team in favor of cifs and the mount.cifs module. smbfs and smbmount are still distributed with Samba, but they are not being actively maintained.

While we're installing Ubuntu packages, you'll also want the package winbind, which mount.cifs needs in order to resolve NetBIOS or Windows NT names (the Samba server we've been setting up uses NetBIOS name resolution, not Windows NT). SUSE users will need the package samba-winbind. I'm not positive, but I believe winbind is included in Red Hat/CentOS/Fedora's samba-client package.

After installing winbind, you should add the string wins to the hosts: line in /etc/nfsswitch.conf (only root can do this; you'll need to use su or sudo).

After mount.cifs and winbind are in place, you're ready to start mounting Samba shares. To to this manually from a command line, you can invoke the mount command as root or, as shown here, using sudo:

myclientlaptop-$ sudo mount -t cifs //CASA_DE_MICK/BUZZ-OFF 
 ↪./mymountpoint -o rw,suid,user=mick

In this example, we're telling mount to use a filesystem type (-t) of cifs. We're mounting, obviously, the share BUZZ-OFF on the server //CASA_DE_MICK, using the mountpoint ./mymountpoint (which is an existing directory within my current working directory). Note that I can, if necessary, use my Samba server's IP address rather than its NetBIOS (or Windows NT) name, in which case, that part of the command would look something like //

The -o gives a list of options for this mount. The first option, rw, lets me both read files from and write them to the share. suid causes any set-uid bits on files in the share to be acknowledged. user passes my Samba user name to the mount.cifs module so it can authenticate the session. After entering the above command, I'll be prompted first for the root password and then for mick's password.

Whatever you do, do not enter your password on the command line using the password= option. Because shell commands may be logged in various places and are stored in shell histories, it's generally a terrible idea to use any password as a command argument.

If your Samba credentials are unimportant, for example, because they do not correspond to any user account with actual shell access, it's still a good idea to avoid passing its password to a command. A better option in that scenario is to use a credentials file, which is simply a text file containing a user name and password.

However, that method is not appropriate for storing any credentials you actually use to log in to systems. Even with strict file permissions set, it may be possible for some unauthorized person or process to copy or read the credentials file.

As with any type of filesystem mounting, you can save yourself typing by creating an entry for your mount in /etc/fstab. For the example we just used, a corresponding fstab entry would look like this:

//CASA_DE_MICK/BUZZ-OFF /home/mick/mymountpoint cifs 
 ↪rw,noauto,suid,user=mick 0 0

As you can see, this line is very similar to the mount command line we used earlier. One new option here is noauto, which causes this line to be ignored at system startup—this Samba share won't be mounted until you issue a mount command, like this:

myclientlaptop-$ sudo mount /home/mick/mymountpoint

sudo will prompt you for the root password. (Again, if you aren't running Ubuntu, you could omit the sudo command and instead execute the rest of the command from a root shell session.) Then, mount will prompt you for mick's password.

Assuming authentication succeeds, you'll be able to use BUZZ-OFF as if it were part of your local filesystem, located in /home/mick/mymountpoint. When you're done working, you can unmount it like this:

bash-$ sudo umount /home/mick/mymountpoint

If you prefer your Samba mount to be activated every time your system starts, you can omit the noauto option in your fstab entry. However, unless you use a credentials file, you'll need to be present during each startup in order to enter the Samba password when prompted; otherwise, your startup will wait for you indefinitely. On a laptop system this probably isn't a problem, but on other types of systems it very well could be an issue.

Similarly, if your Samba server is unavailable for some reason when your client system starts up, this also can cause the client startup to hang or delay. When in doubt, stick to noauto mounting.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Great article

bobwdn's picture

I have looked forward each month to each installment of this series. Great job. Have been using Samba and configuring by manual adjustments within the smb.conf file. This article has helped me now look at my existing configuration (through SWAT) and understand the intent of SWAT.

Years back, the Samba/SWAT documentation was weak and confusing in some areas. I learned to adjust the configuration manually (if you will) and got Samba running to "get by". Now, with the help of these articles, I can greatly improve my security and understanding of Samba configuration settings.

Thanks, Mick for all your work. It paid off with a great article.