Avery common task that people use Linux for is to configure it as a file server. With regard to this task, Linux is very versatile; it offers support for all common protocols. In this chapter, you’ll learn how to configure Linux as a file server using either Samba or NFS.

Operating File Servers Securely

To operate a file server in a secure way, modern Linux distributions are using advanced security solutions such as firewalls and methods for mandatory access control, such as SELinux or Apparmor. In this chapter we’ll ignore these features completely and just focus on the functional part of the services involved. That means that you may need to shut off these services.

To ensure that no firewall rules are blocking access to your services, type iptables -L. If this command shows a lot of lines as output, you’ll have a firewall that is operational and that needs to be configured to make the network services accessible. You can shut it off temporarily by using the iptables -F command.

On Red Hat and derivatives, SELinux is used to offer an enhanced security. On a production system, using SELinux is definitely recommended, but as the purpose of this chapter is to teach you how to configure NFS and Samba, you might want to start shutting off SELinux before you start. To do this on a temporary basis, type setenforce 0.

If AppArmor is used, you don’t need to shut down anything. Apparmor is similar to SELinux, but not as restrictive. Notice that using the above commands to shut down the firewall and SELinux works on a temporary basis only. After a restart of your machine, these security mechanisms will be activated again automatically.

Creating a Samba File Server

In this section, you’ll first read about the background of the Samba project. This helps you to better understand what Samba is all about. Following that, you’ll read how to configure a Samba server to offer file services to end users using a Windows desktop. In the last part of this section, you’ll read how to access files on a computer that provides SMB file services from the Linux command line.

Background of the Samba Project

In 1998, Microsoft released the specifications of its Server Message Block (SMB) protocol, which spurred the start of the Samba project. The goal of the Samba project was to implement a free file server that offers SMB functionality. With such a server in place, companies would be able to migrate away from Windows Servers to Linux, without any hassle. With Samba, the end user wouldn’t notice the difference, as Samba can provide exactly the same services that Windows does.

Almost than twenty years on, the Samba project has made great progress. However, there are some problems also. The biggest challenge Samba team members have to face is that all they do is done by reverse engineering. Microsoft in general is not too willing to share the source code of the core functionality that is offered by Windows servers.

The result is that Samba functionality, in particular for advanced features such as Active Directory can appear a bit limited if compared to the Microsoft solutions. In comparison to Windows servers, you may find other functionality lacking as well. However, if you are looking for a fast and easy-to-configure file server that can replace such functionality on Windows, Samba offers a decent alternative.

Configuring a Samba File Server

Before you start configuring, make sure that Samba is installed on your computer. If which smb doesn’t give you anything, it’s not installed. In this case, install it with yum, zypper, or apt-get using yum | zypper | apt-get install samba. Configuring a Samba file server is not too hard, but you should know what this configuration is all about. The basic purpose of Samba is to offer access to shared directories over the network. To do so, you need a directory to share on the local Linux file system, and the share itself, which gives access to this directory over the network. The former is configured on Linux, the latter is configured in the main Samba configuration file /etc/samba/smb.conf. To get access to the Samba file server, you need two user accounts as well. First, there must be a Linux user who has Linux permissions to the Linux file system. Next, you need a user who has Windows-compatible credentials to access the share. After creating the share and the user account, you may need to configure some generic Samba parameters as well. Finally, when all this is done, you must start the processes that the Samba server needs. In the following sections, you’ll find more details about all of these tasks.

Configuring the Share

The first part in the configuration of a Samba server is the share. You’ll need the configuration file /etc/samba/smb.conf to do this. Before doing so, you need to create the directory you want to share in the Linux file system, and you need to configure access to the share. The following procedure describes how to do this for an imaginary share with the name /share. You will make this directory read/write accessible to members of the sales group. In this group, user linda needs special permissions to be able to do some application management. You’ll notice that none of the tasks described here is really new, but you will need to perform all of them as a part of the Samba configuration. All of the tasks described here assume that you have root permissions.

1. Use mkdir /share to create the shared directory in the Linux file system. It doesn’t really matter what file system you are using on Linux, although I do recommend you work with a file system that has support for ACLs (see Chapter 7 for more on ACLs). Samba works with ACLs to enable Windows-like permission inheritance.
2. After creating the directory, you need to configure permissions on the share. You could, of course, work with the infamous Everyone Full Control that you encounter on older versions of Windows servers. If you want this, just use chmod 777 /share. It is nicer though if you apply more granularity in the file system permissions. In this scenario, you need to make the share read/write accessible for all users in the group sales. Also, user linda needs group management permissions. You can do this by changing ownership on the directory using the following command: chown linda.sales /share. This command assigns user linda and group sales as the owners of the share /share.
3. At this point, you have configured ownership but still are working with the default permissions, which normally don’t allow group members to write to the share. To make sure that only user linda and members of the group sales can write to the share, use the following command: chmod 770 /share.

At this point, you have configured the Linux part of the file share. However, this doesn’t make the directory accessible over the network. To do that, you need to modify the /etc/ samba/smb.conf file. Since you’ve already set permissions on the Linux file system, the configuration of the Samba share can be really simple. In Listing 12-1, you can see what the share configuration might look like. This listing contains some code that you need to include in the /etc/samba/smb.conf file.

[share]
       comment = sales share
       path = /share
       read only = No
       inherit acls =yes
       create mask = 0660

In this share configuration, a few parameters are used:

• comment: This parameter is used to provide a comment, which is shown to Windows users who browse to the share. It’s a good idea always to use such a comment to make it clear to users what exactly they are connecting to.
• path: This parameter, the only required one in the list, tells you what directory the Samba server should share.
• read only: This parameter configures security on the Samba share. If you don’t use it, the share will be read-only. In this example, it is set to no, which means that the share is writable by all users who also have write permissions on the underlying Linux file system.
• inherit acls: This parameter tells Samba to honor Linux ACLs. This means that you can set ACLs on the Linux file system and benefit from them in the Samba environment.
• create mask: If you don’t use this parameter, Samba will use the default Linux umask when it creates new files on the Linux file system. Since the default umask gives read access to all users, this might not be a good idea. Therefore, in this example, a custom create mask is used to grant read/write permissions to the user and group owners, but no permissions at all to others. When specifying a create mask value, you have to enter the exact permissions you want to set. For instance, create mask 0660 would set read/ write permissions for the user and group and nothing for others.

At this point, you have configured all that needs to be configured to make the share accessible. In the next section, you’ll read how to handle user access.

Creating the User Account

To access a Samba share, you need access to the share on the Linux file system, as well as on the share itself. You can compare this to a Windows server, where a user needs NTFS permissions as well as share permissions. Unfortunately, the way that Windows handles encryption is not compatible with the way Linux handles permissions. Therefore, you cannot access a Linux directory from a Windows workstation if you only have a Linux user account; you need Windows credentials as well. The simplest way to fix this problem is to create a Linux user account as well as a Windows user account, which is exactly what we’ll do in this chapter.

When working in an enterprise environment where many users need to get access to a share, this may not be a workable solution, however. This is especially true if you have many servers with Samba shares. If your needs go beyond a situation where you can work with just a Linux and a Samba user account, there are some other options. As all are relevant in typical enterprise environments, none of these options are explained any further in this book:

• Set up an OpenLDAP Directory server: By using such a Directory server, you can create user accounts that have properties that make it a valid user in Linux, as well as properties that make it a valid user in Windows.
• Configure Samba as a Windows NT-style Domain Controller: When doing this, you still need Linux user properties to be able to access the Linux file system, but at least this method allows you to manage users in a centralized way. Another benefit is that you can configure end-user computers for domain logon, which is more flexible than local logon only.
• Configure Samba as a member server in Active Directory: This option is interesting in environments where an existing Active Directory environment is in use. If Samba is configured as a member server in Active Directory, it can get all user information from Active Directory, which means that you don’t have to set up Windows user accounts at all. However, you will still need to set up Linux user accounts.
• Use Winbind to get all required information from Active Directory: Winbind also is a decent solution if you want to use Samba in an environment that mostly uses Active Directory. To accomplish this, you’ll run the winbind service on the Linux computer. Winbind will authenticate user accounts against Active Directory, and once this authentication has happened successfully, the user account is authenticated on Linux as well. This solution therefore allows you to manage one user account only, centralized from Active Directory.
• Use the security=server option: This option allows you to configure one Samba server with user accounts. All other Samba servers can get the user information from this main Samba server.

In this book, I’ll only cover the option where you’ll create two different user accounts: the Linux user account and the Samba user account. The following procedure shows what you need to do to set up such an environment:

1. Create the Linux user account with the methods discussed in Chapter 6 of this book. For instance, to create a user linda and make sure that she has a home directory as well, use the following command (note that using the -m option is required on SUSE and not necessary on other Linux distributions):

   useradd -m linda

2. There is no need to set a password for this user account as well. A Samba user typically connects to a share over the network and never accesses the console of your Linux computer. If your Samba user needs local access, you can give him or her a Linux password. However, if the user account is used on a Windows computer only, you don’t have to do this.
3. Use the smbpasswd command to create the Samba user account. You can do this as follows:

   smbpasswd -a linda

The smbpasswd command now asks you to enter a password for the Samba user. This Samba password conforms to all rules that Windows normally uses for password storage and is stored with the user account in the configuration file /etc/samba/smbpasswd. Listing 12-2 shows the contents of this file after creating the user linda.

nuuk:~ # cat /etc/samba/smbpasswd
# This file is the authentication source for Samba if 'passdb backend' is set
# to 'smbpasswd' and 'encrypt passwords' is 'Yes' in the [global] section of
# /etc/samba/smb.conf
#
# See section 'passdb backend' and 'encrypt passwords' in the manual page of
# smb.conf for more information.
linda:1001:F6E8482239815354AAD3B435B51404EE:55DB0294BC42D6E1B81AE2B5C7F294
3F:[U          ]:LCT-49543651:

Apart from creating user accounts with smbpasswd, you can also use this command to manage user accounts. The command allows you to do this in local mode, as well as remote mode. The remote mode helps you in managing Samba user accounts on other computers. In local mode, you’ll manage Samba users on your computer only. Following is a list of the most useful parameters that you can use in smbpasswd local mode:

• -a: Adds a user
• -d: Disables a user account without removing it from your configuration
• -e: Enables a user account after it has been disabled
• -m: Creates a machine account, which is required in setups where workstations need to authenticate to a domain
• -x: Removes the user account from the smbpasswd file

At this point, you have done all that is necessary to enable the Samba user account. In the next section, you’ll read how to start Samba services.

Starting Samba Services

At this point all that you need to do to create a Samba file server has been done. It’s time to start it now! To do this, you normally need to run two different services. First is the smbd service, which starts Samba file services. Next is the nmbd service. This service gives you NetBios name services; you’ll only need to start it if you want to use NetBios for name resolution.

To start these services, on modern Linux distributions you’ll use systemctl start smb; followed by systemctl enable smb to make sure it is automatically activated upon reboot. If you need the nmb naming services to be started also, use systemctl start nmb; systemctl enable nmb.

Working with additional parameters in smb.conf

Based on the information that was just discussed, you are able to configure a Samba server that offers a share on the network. However, hundreds of other parameters exist that you can use to tune and enhance your server. I won’t cover every available parameter, but to give you an impression of some of the most important ones, Listing 12-3 shows an example smb.conf configuration file and an explanation of the parameters used in this file.

Before explaining the individual parameters, you should be aware of the main distinction used on the configuration file. There is a section with the name [global] as well as other sections. The section [global] contains global parameters. These are parameters that are not directly related to individual shares, but they define how your Samba server should behave in general. Most parameters used in this section are specific to the [global] section only; you can’t use them in individual shares. (There are some exceptions to this rule, but they are rare.)

Following the [global] settings are some specific share settings. In this example file, some “normal” file shares are used, but some specific shares are included as well that help you in enabling specific functionality. Here’s a list of the specific shares in Listing 12-3:

• [homes]: This share shares user home directories. When creating a Linux user, it normally gets a home directory in /home. This share makes sure that the Samba user can access the contents of this home directory as well.
• [profiles]: This share enables users to share their user profile on the Samba server.
• [printers]: This share makes a connection to the printing system, which on all current Linux distributions is the Common UNIX Printing System (CUPS).
• [print$]: This share enables access to printer drivers for end users. By using this share the way it is configured here, end users can install printer drivers directly from the Samba server.

nuuk:/etc/samba # cat smb.conf
 [global]
        workgroup = WORKGROUP
        printing = cups
        printcap name = cups
        printcap cache time = 750
        cups options = raw
        map to guest = Bad User
        include = /etc/samba/dhcp.conf
        logon path = \%Lprofiles.msprofile
        logon home = \%L\%U.9xprofile
        logon drive = P:
        usershare allow guests = Yes
[homes]
        comment = Home Directories
        valid users = %S, %D%w%S
        browseable = No
        read only = No
        inherit acls = Yes
[profiles]
        comment = Network Profiles Service
        path = %H
        read only = No
        store dos attributes = Yes
        create mask = 0600
        directory mask = 0700
[users]
        comment = All users
        path = /home
        read only = No
        inherit acls = Yes
        veto files = /aquota.user/groups/shares/
[share] 
        comment = sales share
        path = /share
        read only = No
        inherit acls =yes
        create mask = 0660
[groups]
        comment = All groups
        path = /home/groups
        read only = No
        inherit acls = Yes
[printers]
        comment = All Printers
        path = /var/tmp
        printable = Yes
        create mask = 0600
        browseable = No
[print$]
        comment = Printer Drivers
        path = /var/lib/samba/drivers
        write list = @ntadmin root
        force group = ntadmin
        create mask = 0664
        directory mask = 0775

Following is a list of the options used in Listing 12-3 and a short explanation for each of these options. Of these options, the only one that is required is path. All others are optional.

• workgroup: This option specifies the workgroup name your Samba server uses, which serves not only as the workgroup name in Windows peer-to-peer networking, but also as the domain name in an environment where domains are used. This can be a Windows NT 4 environment, an Active Directory environment, or an environment where Samba is used to provide domain functionality.
• printing: This parameter tells Samba what local solution is used to handle printing. On Linux, this will normally be CUPS.
• printcap name: In pre-CUPS Linux printing, the printing system had its own configuration file, which had the name /etc/printcap. In CUPS printing, there is no longer such a file. Samba needs to know what to do with /etc/printcap though, and that’s why in this example, cups is used as the value for this parameter.
• cups options: This parameter tells Samba how it should offer data to CUPS printers.
• map to guest: In a Windows environment, a guest user can be used. Therefore, the Samba server may receive requests addressed to the guest user. Using this parameter, you tell Samba how to handle such requests. For instance, you can map the Windows guest user to a local Linux user account that has limited permissions. In this example, the parameter has the value of Bad User, which completely disables the Windows guest user feature.
• include: Use this parameter if you also want to read the contents of an additional configuration file. In this example, the contents of a file with the name dhcp.conf is read. In this file, you’ll need to specify additional Samba commands. Using an additional configuration file is useful in making sure that the main smb.conf configuration file doesn’t grow too big.
• logon path: In a domain environment, workstations that are in the domain need to know where they can find system logon information. Samba makes that clear by using the logon path parameter. This parameter has as its argument the name of a share that this Samba server offers. In the share, %L is used to refer to the localhost name.
• logon home: In a Windows 9x environment, users may also use home directories. If this is the case, they’ll use the logon home parameter to discover where to find all home directory related settings.
• logon drive: This parameter indicates which drive is used on the Windows workstation to map to the share that contains home directories. Make sure that this drive is not already in use by something else.
• usershare allow guest: This parameter indicates whether you allow guest users in user shares. If you want to maintain tight security, you should set this to no.
• comment: Use this parameter to make it clear what a share is used for. Users will see the value that you’ve used here when browsing the network environment.
• valid users: You can use this parameter to indicate which users are allowed access to this share. This is a very good measure for security: if a user is not on the list, he or she simply doesn’t get access. You can also refer to all members of a group by using the @ sign. For instance, @sales would allow access to all users who are a member of the group sales.
• browseable: This parameter indicates whether you allow browse access to a share. A user who has browse access can see all contents of the share. It is typical to switch this off on home directories and shares that relate to printing.
• read only: This parameter sets basic security on a share. If not set, the share will be read only. Change this to read only = no (or writeable = yes, both work) to allow write access to the share.
• inherit acls: This parameter is used to let your Samba server cooperate with Linux ACLs. If this parameter is set to yes, Samba will honor ACLs and create new files according to the specification of the ACL setting.
• path: This parameter, which is required, indicates which path on the Linux file system is shared by this share.
• store dos attributes: If you want to store DOS attributes, make sure that this parameter is set to yes. As DOS attributes require additional disk space, they are not stored by default.
• create mask: This parameter is used to set a create mask for new files. The create mask determines permissions on new files. If you use inherit acls, you should not use this parameter because the settings in a default ACL and the settings in the create mask may conflict with one another.
• directory mask: This parameter accomplishes the same as the create mask parameter, with the only difference being that it works on directories.
• printable: This parameter is needed on a printer share to allow the CUPS printing sub- system to get files from this share and print them.
• write list: This parameter contains a list of users who have write access to a share. You can use it in combination with the valid users parameter for more strict security settings. Only valid users get access, and only users who are on the write list are able to write new files in the share.
• force group: This parameter tries to set the group owner to the group whose name is specified here. If the user is not a member of that group, the default primary group of that user is set as the owner. You don’t need this parameter if you have already applied the SGID permission (see Chapter 7), or if you are working with a default ACL.

Accessing a Samba File Server

After applying all items that are discussed in the preceding sections, you should now have a decent Samba file server up and running. Time to test whether it works! You could, of course, use a Windows workstation and connect to the network share by using UNC naming. For example, if the name of your host is nuuk and the name of the share is share, you would try from Windows to map a network drive as \nuukshare. Windows would then ask you to enter a username and password and connect you to the share.

If you don’t have a Windows workstation available at the moment, there is an alternative: you can connect to the share from the Linux command line. In the next two sections, you’ll learn how to test the share and connect to it from the command line. Following that, you’ll also read how to connect to the share automatically when starting your workstation by including it in the /etc/fstab startup file on your workstation.

Accessing Samba from the Command Line

There are two methods to connect to a Linux share from the command line. You can use the smbclient utility, which gives you an FTP-like interface to the Samba shared file system. This means that you would need to use FTP-like commands like put and get to transfer files to and from your local workstation. When working this way, the share doesn’t really integrate smoothly to your file system, so you probably don’t want to do that. To integrate the share in the Linux file system, you can mount it using the mount command.

Before connecting to a share, you might be interested to find out whether the share exists. Even if you have started the Samba server using systemctl start smb and not seen a failure, there may be another reason why accessing the share fails. Hence, you need to make sure that it works first. To do this, you can use the smbclient utility. Using this utility, you can ask the Samba server to get an overview (list) of all available shares. You do this by entering the following command:

smbclient -L //servername

The command next asks for a password, but you can ignore that and just press the Enter key, as no password is needed to get a mere overview of shares that are offered. Listing 12-4 shows the result of the smbclient -L command on the machine that uses the example Samba configuration file that you’ve seen in Listing 12-3.

nuuk:/etc/samba # smbclient -L //localhost
Password:
Domain=[NUUK] OS=[Unix] Server=[Samba 3.0.28-0.5-1657-SUSE-CODE10]

        Sharename      Type      Comment
        ---------      ----      -------
        profiles        Disk      Network Profiles Service
        users           Disk      All users
        share           Disk      sales share
        groups          Disk      All groups
        print$          Disk      Printer Drivers
        IPC$            IPC       IPC Service (Samba 3.0.28-0.5-1657-SUSE-CODE10)
Domain=[NUUK] OS=[Unix] Server=[Samba 3.0.28-0.5-1657-SUSE-CODE10]

        Server               Comment
        ---------            -------
        Workgroup            Master
        ---------            -------

Given the output provided by the smbclient -L command, our test server is available, and it has some shares to offer. So it’s time to connect now. To make a connection to a share by using the mount command, you first need a directory that is available to mount the file system on. For testing purposes, let’s use the directory /mnt/samba. This directory doesn’t exist by default, so make sure that you create it before you start, using mkdir /mnt/samba. To connect the Samba share to that directory, you need to use an option that tells mount that it should connect to a Samba share, which by the way can also be a share on a Windows machine. To make this clear to the mount command, you can use either the -t cifs option.

Next, you need to tell Samba what user credentials to use. You can do this by passing the username as a special option to the mount command, using -o username=. Using a special option, you can even pass the password directly on the command line to the mount command, but that is a very bad idea, since this password would be readable text on the command line with no encryption applied. This means that other users would be able to get the password by using such mechanisms as the history command. As the third and fourth arguments, you need to tell mount what share to connect to and where to mount this share. The result of all this is a command that looks like the following:

mount -t cifs -o username=linda //nuuk/share /mnt/samba

At this point, the directory /mnt/samba on your Linux computer is connected to the share on your Samba server. It looks a little weird to use a Windows protocol to connect one Linux machine to another Linux machine, but why shouldn’t you? Samba is a fast, versatile solution that offers way more options to secure it than the alternative NFS file system. Also, using this solution, you can not only connect your Linux computer to a Samba server, but also to a share that is offered by a Windows machine, and that is useful if you need to exchange files between Windows and Linux computers.

Configuring Samba Access on Booting

In a test environment, an excellent solution is to perform a manual mount to connect to the Samba share. Once you have verified it’s working, you probably want a solution that is more user friendly. You can do this by using the /etc/fstab file to mount the share automatically.

Before typing your share entry in /etc/fstab, however, you should have a plan. This plan is based on the answer to one question: what exactly are you going to do with your share?

There are three common scenarios:

• The share gives access to user home directories. If this is the case, you want to mount the contents of the home directory share on the /home directory of the local machine.
• The share gives access to a shared group directory. If this is the case, you may want to create a directory with the name /groups on the local workstation and mount the share in a subdirectory of that directory. For instance, if you want to mount //server/sales, you might want to do that on /groups/sales.
• It is another, more generic kind of share. If the share is not used in a specific user or group scenario, but is of a more generic kind, it is a good idea to mount it in the /srv directory. Many distributions have this directory by default now to allow you to access common server-based files. For example, if you have a tools directory on the Samba server that you want to make accessible on the local file system, it’s a good idea to create a directory named /srv/samba/tools and mount it there. Of course, you may also use another solution—any solution that makes sense to you is fine.

After deciding where to mount the share, you just have to mount it. To do this for the share //nuuk/share that was discussed previously, you can add the following line to your fstab file (see Chapter 3 for more information about fstab and its contents):

//nuuk/share    /groups/sales    cifs _netdev,username=linda,password=secret    0    0

Since the same options are used as when you are performing the mount manually, there are only two items that need a little explanation. First is the option _netdev. This option tells fstab that the share is on the network. The result is that your computer will wait until the network is available before trying to mount this share. Next, the password of the user is in the fstab file in clear text. Since this is the case, you do want to apply some additional security to the fstab file. I recommend you at least remove the read permissions for the others entity.

Basic Samba Troubleshooting

Based on the preceding information, your Samba server should now be up and running. Sometimes it won’t though. In case this happens, here is a basic troubleshooting procedure for you to follow, based on the problems I’ve seen people having with Samba:

1. Start by narrowing the scope: can you reach the Samba host with the ping utility? Try the command ping 1.2.3.4, and make sure to replace 1.2.3.4 with the IP address of the machine where the Samba server resides. Are you getting a reply? Then you know the problem is not on the network.
2. Now do some checks on the computer that runs the Samba server. The best check to start with is the smbclient -L //localhost command. This command gives an overview of all shares that are locally offered. If this command does not give anything that looks like Samba shares, proceed with Step 3. If this command does give you a list of available shares, proceed with Step 4.
3. If smbclient didn’t return anything looking like Samba shares, the problem is probably in the service process. Make sure that it is up and running using ps aux | grep smb. In case this command doesn’t give you any running Samba servers, start the Samba service now with the procedure that is appropriate for your distribution. This should fix the problem.
4. If smbclient -L did give a result, there can be two possible causes. First, you may have made a syntax error while writing the smb.conf file. Step 5 describes what to do in that case. Another reason can be an error in the user configuration. See Step 6 for more details on how to fix this.
5. Samba has an excellent tool that helps you look for syntax errors in the smb.conf configuration file. Its name is testparm, and you can just run it like that from the command line. The tool will first give you the results of its analysis and, after you press Enter, display all the effective parameters (which in fact is a dump of all active lines in smb.conf, excluding comment lines). In Listing 12-5, you can see an example of its output. In this output, the tool points out an unknown parameter directory mask, which in this case helps in fixing the problem.

   Listing 12-5. The testparm Utility Analyzes smb.conf for Syntax Errors

   nuuk:/etc/samba # testparm
   Load smb config files from /etc/samba/smb.conf
   Processing section "[homes]"
   Processing section "[profiles]"
   Unknown parameter encountered: "diectory mask"
   Ignoring unknown parameter "diectory mask"
   Processing section "[users]"
   Processing section "[share]"
   Processing section "[groups]"
   Processing section "[printers]"
   Processing section "[print$]"
   Loaded services file OK.
   Server role: ROLE_STANDALONE
   Press enter to see a dump of your service definitions

6. If you still haven’t found the problem, it is probably user related. In this case, the solution really depends on the way you’ve set up the user accounts. If you did it in the way described in this chapter, you can run a few checks to see whether the user setup still works. If you are using an external service for user authentication, check the configuration and availability of that service. The first thing to do if a user gives a problem is to check whether the user is available on your Linux computer. You can do this by using grep on /etc/passwd, which is shown in the following example code line:

   grep linda /etc/passwd

   If this command does not give you a result, use useradd -m to create the local user account. In case this command does give a result, it may help to reset the password for the user. The following command will do that for you:

   smbpasswd linda

   The smbpasswd command will now ask you to enter the password for your user twice. Once you’ve entered it, try again and see whether that has made the user account functional.

I am aware that this section on Samba troubleshooting was short. However, I’ve described the most common problems, which will help you in resolving these issues. Other problems are less common and therefore not covered in this chapter.

Configuring an NFS Server

The preceding part of this chapter described how to configure Samba to offer file access to mostly Windows users. In this section, you’ll learn how to configure Network File System (NFS) services on your computer. Following a brief overview of the protocol, you’ll next learn how to build a configuration to share NFS services and how to access these NFS shares.

NFS Backgrounds

NFS is an old protocol that allows you to share files on a UNIX/Linux network. It goes back to the days when you still had to wear a white coat before being allowed to approach the computer. In those days, computers that were networked were also computers that were trusted, because there was no such thing as the Internet that allowed everyone to connect to your computer. Given this environment, NFS was developed as a protocol that offers a fast-and-easy way to share files. Unfortunately, it was never developed with security in mind.

Security in NFS has always been based on hosts. When creating a share, you’ll give access to a host, not to individual users. After the host has made contact, the users on that host will have the same permission as the users on the NFS server. That is, the user with user ID 501 (or any other user ID) on the NFS client will automatically get the permissions that user 501 has on the NFS server. You can imagine that there can be some serious problems with this. Since NFS was often used in conjunction with the NIS service, which allows for centralized user management (i.e., which takes care that the user with UID 501 is the same on all hosts involved), this feature was not really harmful.

In the recent version 4 of the NFS protocol, Kerberos security has been added as an option. Using Kerberos security allows you to use Kerberos tickets, which allows user-based access control as well. Setting up Kerberized NFS shares requires insight in the working of Kerberos and for that reason goes beyond the scope of this chapter. Version 4 has become the default NFS version on all Linux distributions, which is why in this chapter we’ll be working with NFS version 4, even if Kerberos will not be used.

You may wonder, however, why people still want to use NFS. There are two main reasons: its speed and the ease with which you can set it up. As you will find out in the next sections, setting up an NFS share really is not hard to do, as is using the NFS environment.

Another reason why NFS is still being used, is because it is a default option in that is provided by many hardware storage appliances. These appliances are common in large corporate environments and are offering NFS because it’s a simple protocol that is fast and not very difficult to configure.

Understanding NFS Processes

To use an NFS server, a couple of components are involved. First is the NFS server itself. This is provided by the Linux kernel. To offer its services, NFS uses another service, which is the NFS RPC (Remote Procedure Call) portmapper. Let’s see what role this service plays first.

Most modern services have their own port number. Historically this has never been the case for NFS, as NFS was created at a time where TCP and UDP ports hadn’t become the standard yet.

NFS was created a long time ago, when the Internet port numbers in use nowadays weren’t yet common. As a result, NFS uses its own kind of port numbers, the so-called RPC program numbers.

Up to NFS version 3, to offer compatibility with the way that modern computers offer services on the network, these RPC numbers must be converted to an Internet port number. This is the task of the portmap program, which runs as a daemon to support your NFS server. When an RPC-based service, such as NFS, is started, it will tell portmap on what port number it is listening and what RPC program numbers it serves. When a client wants to communicate to the RPC-based service, it will first contact the portmapper on the server to find out the port number it should use. Once it knows about the port number, its requests can be tunneled over the Internet port to the correct RPC port.

To find out on which RPC program numbers your server is currently listening, you can use the rpcinfo -p command. In Listing 12-6, you can see an example of this command showing its results.

SFO:~ # rpcinfo -p
   program    vers   proto   port
    100000       2     tcp   111 portmapper
    100000       2     udp   111 portmapper
    100003       2     udp   2049 nfs
    100003       3     udp   2049 nfs
    100003       4     udp   2049 nfs
    100003       2     tcp   2049 nfs
    100003       3     tcp   2049 nfs
    100003       4     tcp   2049 nfs
    100024       1     udp   1147 status
    100021       1     udp   1147 nlockmgr
    100021       3     udp   1147 nlockmgr
    100021       4     udp   1147 nlockmgr
    100024       1     tcp   2357 status
    100021       1     tcp   2357 nlockmgr
    100021       3     tcp   2357 nlockmgr
    100021       4     tcp   2357 nlockmgr
    100005       1     udp   916 mountd
    100005       1     tcp   917 mountd
    100005       2     udp   916 mountd
    100005       2     tcp   917 mountd
    100005       3     udp   916 mountd
    100005       3     tcp   917 mountd

As you can see in the output of the rpcinfo -p command, NFS is listening to Internet port 2049 for version 2, 3, and 4 calls. Internally, it is using RPC port 100003 as well. Before the NFS server is started, you must make sure that the portmapper is started. All of the main Linux distributions will take care of this automatically when you start the NFS server.

After starting the portmapper, the other NFS server components can be started. First is the rpc.nfsd program. This program makes sure that the portmapper is informed there is an NFS server present, and it will give the proper portmapper program number to the NFS server.

Next, the rpc.mountd program must be loaded. This program allows users to make NFS mounts to the NFS server. As the third component, the rpc.lockd program needs to be started. This program ensures that only one user can have access to a file at a time; when it is accessed, the nfs.lockd program locks access to the file for other users. You don’t need to load all these programs individually; they are loaded automatically when the NFS server is started through its systemctl script.

Notice that things have changed significantly with the release of NFSv4. In NFSv4, NFS offers its services on port 2049 by default. This makes managing NFS a lot easier, especially in environments where firewalls are being used.

The last part of the NFS server consists of its configuration files. Two different files are involved. First is the /etc/exports file. In this file, the NFS shares are specified. Then on some distributions such as SUSE and Red Hat, there is also the /etc/sysconfig/nfs configuration file, where the number of NFS threads and other startup parameters are specified.

Configuring an NFS Server

On most distributions, two configuration files are involved if you want to manage the NFS server by hand. First and most important is the /etc/exports file. You will find it on all Linux distributions. This file is used to configure all NFS shares you want to offer from your NFS server. Apart from that, your distribution may use the /etc/sysconfig/nfs file, in which a couple of parameters is provided to the NFS server, determining the way that server offers its services.

In the file /etc/exports, the NFS shares are defined. The generic structure of the lines where this happens is as follows:

directory hosts(options)

In this, directory is the name of the directory you would like to share, for example, /share. Next, hosts refers to the hosts that you want to grant access to that directory. The following can be used for the host specification:

• The name of an individual host, either its short name or its fully qualified domain name
• The IP address of an individual host
• A network referred to by its name, for example, *.mydomain.com
• A network referred to by a combination of IP address and subnetmask, for example, 192.168.10.0/255.255.255.0
• All networks, referred to by an asterisk

After indicating which hosts are granted access to your server, you need to specify the options with which you want to give access to the NFS share. Some of the most used options are listed in Table 12-1.

Following is an example of a configuration line that is quite common in /etc/exports. Check man 5 exports for more examples.

/        ilulissat(rw) kangerlussuaq(rw,no_root_squash)

In this line, the host ilulissat gets read/write access to the shared root file system, but root from that host will not get root permissions on the NFS server. The computer kangerlussuaq gets read/write access as well, but the user root will still have his root permissions when connecting to this share.

Tuning the List of Exported File Systems with exports

When the NFS server is activated, it keeps a list of exported file systems in the /var/lib/nfs/ xtab file (your distribution may use a different location). This file is initialized with the list of all directories exported in the /etc/exports file by invoking the exportfs -a command when the NFS server initializes. With the exportfs command, it is possible to add a file system to this list without editing the /etc/exports file or restarting the NFS server. For example, the following is used to export the directory /srv to all servers in the network 192.168.1.0:

exportfs 192.168.1.0/255.255.255.0:/srv

The exported file system will become available immediately, but will only be available until the next reboot of your NFS server, as it is not in the /etc/exports file. If you want it to be available after a reboot as well, make sure to include it in the /etc/exports file as well.

Configuring an NFS Client

Now that the NFS server is operational, you can configure the clients that need to access the NFS server. There are two ways to do so:

• Mount the NFS share by hand.
• Mount the NFS share automatically from fstab.

Mounting an NFS Share with the mount Command

The fastest way to get access to an NFS shared directory is by issuing the mount command from the command line. Just specify the file system type as an NFS file system, indicate what you want to mount and where you want to mount it, and you have immediate access. In the next example, you can see how to get access to the shared directory /opt on server STN via the local directory /mnt:

mount -t nfs STN:/opt /mnt

Notice the colon after the name of the server; this required element separates the name of the server from the name of the directory that you want to export. Although you can access an NFS shared directory without using any options, there are some options that are used often to make accessing an NFS mounted share easier. These options are summarized in Table 12-2.

Mounting an NFS Share automatically from fstab

Mounting an NFS share with the mount command will do fine for a mount you only need occasionally. If you need the mount more than once, it is better to automate it using /etc/fstab.

If you know how to add entries to /etc/fstab, it isn’t difficult to add an entry that mounts an NFS share as well. The only differences with normal mounts are that you have to specify the complete name of the NFS share instead of a device, and that some NFS options must be specified. When mounting from fstab, you should always include the options rsize, wsize, and soft for optimal performance. To refer to the server, its name as well as its IP address can be used. The following line gives an example of what the line in fstab could look like:

server:/nfsshare    /mnt/nfsserver    nfs    rsize=8192,wsize=8192,soft    1 2

Getting a List of available NFS Shares

To mount an NFS share, you first must know what shares are offered by a machine. You can find that out using the showmount command. This command is fairly simple in use: just type showmount -e followed by the name of the host that you want to check. The example in Listing 12-7 shows what its result can look like.

nuuk:/ # showmount -e localhost
Export list for localhost:
/share *

In the previous exercise you have created an NFS share and mounted it. At the end of the exercise you have tried to write a file to the share but that didn’t succeed. The reason is that user root by default is “squashed”, which means that the UID 0 is mapped to the user nfsnobody, a user with no permissions whatsoever on the share. If you wanted to make it possible for this user to write to the NFS share anyway, you would need to grant access permissions on the mount point, for instance by making the user nfsnobody owner of the mount point and giving this user write permissions on it. Notice that it wouldn’t be a good idea to use the mount option no_root_squash, as this would mean that everybody who connects to the share will get root permissions to the share. This is a major flaw in security and should be avoided at all times.

Summary

In this chapter, you’ve learned how to set up Linux as a file server. You’ve read about Samba, which nowadays is a kind of universal option for configuring a Linux file server. It works for Windows, but also for Apple and Linux users. You’ve also read how you can enable NFS file sharing, which is a useful method for file sharing if you want to share files between Linux computers. In this chapter, you’ve learned about the following commands and configuration files:

• smbd: The process responsible for Samba file sharing.
• nmbd: The process that offers NetBIOS-style name services.
• smb.conf: The main Samba configuration file.
• mount -t smbf/mount -t cifs/mount -t nfs: Specific options that specify the file system type that should be used when mounting a Samba or an NFS share.
• testparm: Command that does a syntax check on the smb.conf configuration file.
• rpcinfo: Command that gives information about mappings between NFS ports and RPC ports.
• exports: The main configuration file for your NFS server. All NFS shares are in this file.
• exportfs: Command that lets bypass the /etc/exports file if you need an NFS share for temporary use. Use exportfs with the name of the directory you want to export as its argument.
• showmount: Command that helps you discover which shares are available on any host offering NFS services.

In the next chapter, you will learn how to manage the kernel, its modules, and its hardware on your computer.