Learning the basics of Samba

Samba, like NFS, allows you to share directories on your server with other computers within your network. Although both serve the same purpose, they fit different environments and use cases.

NFS is the oldest method and is widely used in the Linux and UNIX world. While we certainly have newer solutions (such as SSHFS), NFS is tried and true. But it's perhaps not the best solution in a mixed environment. These days, it's possible that not every computer on your network runs a particular operating system, so you may have nodes where NFS access isn't available or is not practical.

As mentioned earlier, only the more expensive editions of Windows support NFS. If you have a large network of Windows machines, it would be quite expensive to update them all to a higher edition if you wouldn't otherwise need to. This is the area where Samba shines the most. Windows, Linux, and Mac computers can access directories shared via Samba. In the case of Windows, even the lower end editions can access Samba shares (such as Windows 7 Home Professional or Windows 10 core) without any new installations or purchases.

The downside to Samba is that it doesn't handle permissions as well as NFS does, so you need to manage the configuration file in special ways to respect permissions. However, it's not foolproof. For example, Windows and Linux/UNIX systems adopt very different schemes of permissions, so they are not inherently compatible. In Samba's configuration file, you can tell it to use certain user and group permissions on newly created files, and you can even force Samba to treat ownership as something other than what is actually stored with the file. So there are certainly ways to make Samba handle permissions better, but not inherently as good as a Linux or UNIX native solution such as NFS.

As far as how as Samba server might fit within your network, the basic rule of thumb is to use Samba in a mixed environment and NFS whenever cross-platform compatibility is not necessary.

Setting up a Samba server

In this section, we'll go ahead and set up a Samba server. In the next section, I'll explain how to mount Samba shares. First, we'll need to install Samba. On both CentOS and Debian systems, the package is simply referred to as samba. So, install that package via apt-get or yum and you should have everything you need:

# yum install samba

The command using apt-get is as follows:

# apt-get install samba

On Debian systems, Samba is started as soon as it is installed. In fact, it's enabled as well, so it will automatically start each time you bring up your system. In the case of CentOS though, it is not enabled nor started after installation. If you chose CentOS to be your Samba server, you'll need to enable and start the daemon:

# systemctl start smb
# systemctl enable smb

Now, Samba is installed, enabled, but not configured. To configure Samba, we'll need to edit the /etc/samba/smb.conf file. By default, this file is created as soon as you install the required packages. However, the default file mainly exists to provide you with configuration examples. It's quite massive, but you may want to take a look at it to see some syntax examples you may want to use later. You can either open the file in a text editor or simply cat the file to view it on your terminal:

cat /etc/samba/smb.conf

To simplify things, I recommend that you start with a fresh file. While the configuration examples are definitely good, we should probably use a shorter file for production purposes. Since the original file may be useful later, create a backup:

# mv /etc/samba/smb.conf /etc/samba/smb.conf.default

Next, simply open the smb.conf file in a text editor, which will create a new/empty file since we moved the original file to a backup:

# vim /etc/samba/smb.conf

We can start with the following basic configuration:

[global]
server string = File Server
workgroup = HOME-NET
security = user
map to guest = Bad User
name resolve order = bcast hosts wins
include = /etc/samba/smbshared.conf

Let's go through this configuration file line by line. First, we start with the [global] section, which is where we're configuring options that will take effect for the entire server. In fact, this is the only section in this particular file.

Next, we have server string. The server string is the description you'll see if browsing the network shares on a Windows system. For example, you may see a share named Documents and with a description beneath that reads; File Server. This section isn't required, but it's nice to have. In a business network, this can be useful for outlining a note about the system, such as where it is, or what it's used for.

Following that, we set our workgroup. Those of you who have been administrators of Windows systems probably know this very well. The workgroup serves as a namespace to contain all systems of a particular purpose. In practice, this is typically the name of your LAN. Each computer within your LAN would have the same workgroup name, so they would show up as existing within the same network. When browsing shares on a Windows system, you'll likely see a list of workgroups and double-clicking on one of them would take you to a listing of systems that are sharing resources underneath that workspace. In most cases, you'll probably want to have the same workgroup name on each system, unless you'd like to separate resources. To view the workgroup name on an existing system, right-click on My Computer or This PC (depending on your version) and click on Properties. Your workgroup name should be listed within the window that appears.

Setting up a Samba server

Viewing properties of a Windows system to gather the workgroup name, which is LOCALNET in this case

The setting security = user tells Samba to use the user's username and password for authentication. If this matches, the user won't be prompted for a password to access the resource.

The map to guest = Bad User tells Samba that if the username and password that's provided does not match a local user account, treat the connecting user as if he or she connected via a guest account. If you'd rather such mapping not take place, remove this section.

Next, name resolve order = bcast hosts wins determines the order in which name resolution happens. Here, we're using whatever name is broadcast first, followed by any hostname mappings in our /etc/hosts file, followed by wins (wins has largely been replaced by DNS, it's only included here for compatibility). In most networks, this order should work fine.

Finally we've include = /etc/samba/smbshared.conf at the end of our configuration file. Basically, this allows us to include another configuration file as if it were part of the existing one. In this case, we're including the contents of /etc/samba/smbshared.conf, which would be read by Samba once it reads this particular line. We'll create this file next. Essentially, this allows us to designate our shares in a separate configuration file. This isn't required, but I think it makes things much easier to manage. If you'd prefer, you could include the contents of the smbshared.conf file in your smb.conf file so that everything is in a single file.

Here's an example smbshared.conf I've created for the purposes of this activity. In your case, all you would need to do is to ensure that the values match your system and the directories you've chosen to share:

[Music]
## My music collection
        path = /share/music
        public = yes
        writable = no

[Public]
## Public files
        path = /share/public      
        create mask = 0664
        force create mode = 0664
        directory mask = 0777
        force directory mode = 0777
        public = yes
        writable = yes

Here, I've created two shares. Each share begins with a name in brackets (which will be displayed on other systems while browsing shares on this machine) and then the configuration for that share. As you can see, I have a shared directory called Music and another called Public.

To declare the path to a share, use path = and then the path to the directory that the share corresponds to. In my example, you can see that I have the following directories shared:

/share/music
/share/public

Next, I also declare the shares as public by adding public = yes. This means that it's okay for guests to be able to access this share. If I would prefer guests not to be able to access it, I could set this to no.

In my music share, I have writable = no. As the name suggests, this disables the ability for other computers to change files within this share. In my case, I share my music collection with other computers on my network, but I wouldn't want to accidentally delete music files.

In my public share, I have added a few extra options:

        create mask = 0664
        force create mode = 0664
        directory mask = 0777
        force directory mode = 0777

These options all correspond to the permissions that are defaulted to when a new file is created within that share. For example, if I mounted my public share and then created a directory there, it would obtain permissions of 777. If I created a file, its permissions would be 664. Of course, you may not want to allow your files to be wide open, so you can change these permissions as you see fit. This option ensures consistency with permissions on newly created directories and files. This can be essential on a network where you may have automated processes running that need to access these files, and you'd want to make sure that you wouldn't need to manually correct the permissions each time such a process is run.

Now that you've created your own Samba configuration, it's a good idea to test your configuration. Thankfully, Samba itself includes a special command that allows you to do this. If you run testparm on your system, it will display any errors in syntax that you may have in your file. Then, it will display your configuration. Go ahead and run testparm on your system. If there are any errors, go back and ensure that there are no issues with what you typed in. If everything proceeds normally, you should see no errors, and then you'll get a summary of your configuration. Once you've verified your configuration, restart the Samba daemon so that the changes take effect. To do that, simply run the following command on your Debian system:

# systemctl restart smbd

For CentOS, use the following command:

# systemctl restart smb

Now, you should be able to access your Samba shares on Windows or Linux systems. On Linux, most GUI file managers should allow you to browse your network for Samba shares. On Windows, you should be able to open My Computer or This PC and then click on Network to browse local networked computers with active shares. Perhaps a simpler way to access the shares on a Windows machine is to press the Windows key on your keyboard followed by R to open a run dialog, and then simply type in the name of your Samba server beginning with two backslashes. For example, to access my Debian-based file server (Pluto) from a Windows system, I would type the following into the run dialog and press Enter:

\pluto

I got a list of shares from that system, as shown in the following screenshot:

Setting up a Samba server

Viewing Samba shares (served from a Linux System) from a Windows 7 PC

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset