LPIC-3 Mixed Environments 3.0 Introduction #03: 303 Samba Share Configuration

This blog posting is the third in a series that will help you to prepare for the new version 3.0 of the LPIC-3 Mixed Environments exam. In the previous posts we set up a virtual lab, installed Samba, and set up an Active Directory domain. The lab also contains a file server as a domain member. This week’s posting is all about the file server’s share configuration.

Samba File Share Configuration

To get started, let’s review how shares are declared. Usually, each share is a dedicated section in the smb.conf file. The name of the share is the section name surrounded by square brackets. Within each file share, the path option specifies what part of the server’s file system is accessible through the share.

Let’s first of all determine who can connect to the share at all. The smb.conf options valid users and invalid users are the initial doorman deciding who can connect. Try to configure a share to allow or reject connections from specific users and test that the users are connected or rejected as expected. Remember the notation of users mapped from your domain as well as the ability to specify groups in these options.

File Access and Permissions

Once a user is connected, access to the individual files requires further permissions. These permissions are managed in multiple layers. First of all, Samba uses the read list and write list options in smb.conf to determine which users have which kind of access in general. Once a user passes this hurdle, the access to a specific file is subject to file system permissions. The simplest form of these permissions are the classic file ownership and permissions, as managed by chown and chmod.

When accessing a share, Samba uses the identity of the user connected to the share to perform operations on the Linux file system. Thanks to ID mapping on the file server, each domain user has an equivalent in the Linux file server’s user database.

When multiple users access the same share, they might end up creating files they can not mutually access, due to the files’ different owners and permissions assigned to the owning user and group only. An easy way to force a standard owner and permissions is to use the smb.conf options create mask / create mode, directory mask / directory mode, force create mode, force directory mode, force user, and force group / group, which manage the ownership and permissions of files stored in a share independent from the connecting user. If you would like to practice, create a file share for your accounting department and grant several users access to it. Now configure the share to enforce that all files belong to the same group (maybe create an accounting group in your AD and add the users) and that all files are writable by the group.

Access Control Lists

More complex than classic Unix permissions, Access Control Lists (ACLs) allow you to set individual permissions for specific users and groups. Linux uses Extended POSIX ACLs, which are managed by getfacl and setfacl. Adopt the previous example by creating another share that uses ACLs to grant access to all group members, without Samba enforcing any specific ownership and permissions. Review the smb.conf option inherit acls and enable it if necessary. The Samba wiki contains more information about POSIX ACLs on file shares.

It is perfectly fine to use POSIX ACLs on the Linux side to manage access to files on a Samba share. However, POSIX ACLs are different from Windows ACLs. To use Windows ACLs, Samba needs to store additional ACL information besides the POSIX ACLs. The VFS module acl_xattr uses extended file system attributes for this information. setfacl does not update the respective Windows ACLs, which is why ACLs on a share using Windows ACLs should always be set through Samba, by using either a Windows client or the samba-tool ntacl command. The smbcacls command is another tool that manages ACLs on SMB shares. Again, the Samba wiki has some great information about Windows ACLs on SMB shares.

Make Shares Appear Nicely

Once permissions are set, situations may occur where users see files they cannot access. The smb.conf options hide unreadable and hide unwritable files are used to hide these files from the user. Similarly, the options hide dot files and hide special files ensure that users are not bothered by other irrelevant files. Some file managers tend to create hidden files, such as indexes or file thumbnails. Uploading these files to a file share is usually undesirable, so the options veto files and delete veto files can reject or delete such files.

In a real world scenario, multiple file servers likely exist to satisfy all storage requirements. In this case, users need to know which shares are located on which servers. In addition, when shares are reorganized between servers, client configurations need to be changed. The Distributed File System (DFS) allows a server to offer shares that are actually just redirects to the actual share, potentially on another server. This allows users to always access their data using the same path via the DFS share, even if the data is reorganized. Again, the Samba wiki has more information about DFS on Samba.

Printer Shares and Print Drivers

In addition to files, Samba can also provide printable shares. The pattern is the same as for files: for each printer, a share with the printer’s name exists. Samba, however, needs a print server to handle the actual printing. Nowadays, CUPS is the de facto standard for printing on Linux. Samba can query CUPS to determine which printers are available and automatically offer the printers as individual shares. However, it is also possible to manually configure printer shares. The Samba wiki provides an example for configuring a PDF printer share.

In most cases, the printer clients prepare the print jobs so that they are ready to be forwarded to the printer without additional processing. This is called “raw printing”, because the print server passes the print jobs on as they are. In order to prepare the print jobs, the client needs the drivers of the specific printer. These drivers can be distributed by Samba. The Samba wiki has a guide to setting up this configuration.

A security issue called Printnightmare recently used Microsoft’s driver distribution mechanisms to allow users to escalate their privileges. You can read about how this issue was discovered but not yet fixed. But keep in mind that the current exam was developed before the issue was discovered. Therefore, for now, assume that there are no restrictions in place to mitigate Printnightmare.

Moving On

This post concludes the part of this series about Samba server configuration. As usual, the exam objectives include some additional options and commands in addition to those covered in here. Take some time to review the exam objectives and make sure you’ve tried everything mentioned there. The result will be a fully configured Active Directory domain along with a file server.

Next week we will focus on the client side and learn how we can access our shares from Linux and Windows, how to authenticate against an Active Directory domain, and how to use Active Directory to manage Windows systems.

<< Read the previous post of this series | Read the next post of this series >>