Learn Linux, 302 (Mixed environments)

File services

Learn how to create and configure file shares in a mixed environment

Sean A. Walberg
Published on May 25, 2011

In this article, learn to:

• Create and configure file sharing
• Plan a file service migration
• Hide the administrative share, IPC$
• Create scripts for user and group handling of file shares
• Use command-line tools relating to file shares

This article helps you prepare for Objective 312.2 in Topic 312 of the Linux Professional Institute's Mixed Environment Specialty exam (302). The objective has a weight of 4.

Prerequisites

To get the most from the articles in this series, you should have an advanced knowledge of Linux and a working Linux system on which you can practice the commands covered in this article. In addition, you should have access to a Windows environment that you can use to test file and print access.

Creating file shares

Recall from the previous article that Samba understands any section inside smb.conf other than homes, printers, and global to be a share name. Besides the name of the share, mapping the share name to a location on disk is the other important piece of information. Here is the simplest useful share:

[tmpdir]
path = /var/tmp

This code defines a share called tmpdir that maps to /var/tmp on the Samba server. For example, if the server were named phoenix, then users would be able to access that file share with the Universal Naming Convention (UNC) path \\phoenix\tmpdir. This sparse configuration is not useful, however: The default setting for a share is to be read-only, so the share above would not be writable.

Using security parameters

Samba has many security-related parameters that control what can be accessed by whom and from where. Many of these parameters affect the interaction between Samba and the underlying UNIX file permissions and are not discussed in this article. However, a few more general parameters are discussed here.

Server Message Block (SMB) servers, including native Microsoft implementations, have a share called IPC$, which is the interprocess communication share and is used to execute software functions over a network. A share ending in a dollar sign ($) is considered hidden and not shown in Microsoft clients, even thought the server will advertise the existence of the share.

Samba creates the IPC$ share even though it may not exist in smb.conf. If you create the share, you can control access to it. Here is an example of a restricted IPC$ share:

[IPC$]
  hosts allow = 192.168.1.0/255.255.255.0
  browsable = no

This snippet defines the IPC$ share and marks it as only accessible to people on the 192.168.1.0 network. The example further turns off the Browsable feature, which tells Samba that the share should not be shown when clients ask for it.

Some time ago, it was common practice to hide sensitive shares such as IPC$ in hopes that an attacker might ignore the target. This is silly with regard to the IPC$ share. For example, asking a server for a list of shares relies on connecting to the IPC$ share. If you look at Samba debugs and packet traces, you will see that this Browsable option has no effect. The reason I even bring it up is because it is mentioned in the exam outline. It is far better to restrict the hosts that can connect than it is to try and hide the IPC$ share.

A user can connect to a share without a user name, which makes that user a guest. By default, a share does not allow guest users, but you can enable this account with guest ok = yes at the share level. The default guest user is nobody, but you can change this user with the global guest account parameter.

Symbolic links are used extensively on UNIX systems to link two areas of a file system. For example, in your home directory, you can create a symbolic link to the system-wide temporary directory and use it as if it were part of your home directory. Samba follows these symbolic links, which could let people access areas outside of the file share. If you don't want this to happen, use follow symlinks = no in your share.

If you want to restrict the users who can access a share, use the valid users parameter. For example, valid users = sean, jon, isaac allows only those three users to access the share on which that parameter is used. You can use this parameter in addition to file-level permissions as an extra level of safety for sensitive shares.

Home shares

It is common to give users a home directory for their personal files. Each user in the UNIX password file has a home directory assigned. You can easily export any number of home directories through Samba without having to type a separate configuration section by using the [homes] section. When someone requests a share called joe, Samba looks for a configured share called joe; if Samba doesn't find that share, it looks for a user by the same name. If the user is found, Samba then uses the configuration in the [homes] section as a template for this share.

Listing 1 shows a typical [homes] section.

Listing 1. A template for user home shares

[homes]
 comment = Home Directories
 writable = yes
 browsable = yes
 valid users = %S

The configuration in Listing 1 performs these tasks:

• Begins the configuration of the homes section
• Assigns a comment, which is shown to people looking at the details of available file shares on that server
• Marks the share as writable so that users can make changes to their home directory
• Indicates that the share can be seen when users browses for a list of shares; they will see both homes and a share with their user name
• Limits the users who can connect to this share to the user who owns the share

Note the use of the %S macro in Listing 1: This macro expands to the name of the share. Because the user name is the same as the share, the valid users restriction enforces that only the owner of the share can use it.

Now, whenever users look for a list of shares, they will see their home directory and be able to connect to it. The share will be mapped to their UNIX home directory.

Another interesting thing about the homes share is that if you connect to \\server\homes directly, you will get your own share, just as if you had connected to \\server\username. This is an extra feature the Samba team put in place to help people on shared machines and reduce confusion.

Scripts to add users and groups

If you look to a Microsoft domain for your user list, it's possible that a user connecting to your server might not have a local UNIX account. One way around this issue is to have Samba create the user for you when the user connects with the add user script parameter. The %u macro expands to the user in question. You can use a system tool like useradd or write your own scripts.

A similar parameter exists for groups—add group script—which you use when you use Microsoft tools to manage the Samba instance. Also helpful if you use these tools are add user to group and the similar delete scripts. The smb.conf man page has a complete list of scriptable tasks.

Having a daemon create users on demand is not always the best idea. You may be better served by using winbind or a Lightweight Directory Access Protocol (LDAP)-based authentication mechanism so that Samba and Linux can share a common user database.

Dealing with mixed case

The case of a file or directory name does not matter in the Microsoft realm. That is, FILE, file, and FiLe all refer to the same file. In Linux, however, case is important, so those three files would all be different. Samba needs to know how to map between these two worlds to resolve any conflicts. This case-mapping process is part of a larger process called name mangling.

A few parameters affect mangling of file name case. The most important parameter is case sensitive, which can be yes, no, or auto. If case sensitive is enabled, Samba uses whatever case the client requests. If this setting is disabled, Samba looks through the directory for a case-insensitive match.

One problem with case sensitivity is that set incorrectly, you might not be able to access some files. Consider a directory with two files—one called test and the other called TEST. If Samba doesn't use case-sensitive access, then it is unable to differentiate between the two files.

The default for this setting is auto, which looks for a client extension field to indicate that the client supports case-sensitive access. Windows clients do not support this functionality, so they will not use case sensitivity.

The default case and preserve case parameters work with each other. If preserve case is set to yes, then whatever the client sets is used. If preserve case is set to no, then the value of default case is used to determine the case of the newly created file.

Enabling Usershare

Users can create their own shares without having to modify smb.conf by using a feature called Usershare. After the administrator enables the Usershare feature, regular users use a command-line tool to export directories of their choosing. Users can also delete their shares when they are done.

The first step to using Usershare is to enable the feature at the global level. Listing 2 shows a part of smb.conf that enables Usershare.

Listing 2. Enabling Usershare

[global]
  usershare path = /var/lib/samba/usershares
  usershare max shares = 5
  usershare prefix allow list = /home
  usershare prefix deny list = /var, /usr

Listing 2 operates in the [global] section. First, the usershare path defines a directory that Samba uses for the configuration related to the user share. There are several restrictions on this directory that will be explained later. Next, a limit on the number of user shares is imposed. The last two parameters show how to restrict the directories that can be shared. usershare prefix allow list restricts all the shares to the given directories—in this case, the shares must come from under /home. usershare prefix deny list takes the opposite approach and allows anything except the given directories.

Samba imposes two other restrictions on user shares. First, the usershare path must be writable by the user creating the share, and the directory must have the sticky bit set (1000 or +t). Second, the user must own the directory being shared unless usershare owner only is set to false.

The first restriction regarding file permissions means that care must be taken when creating the usershare path. If you want to restrict user shares to people in the usershare group, then a series of commands like these are required:

# mkdir -p /var/lib/samba/usershares
# chown root:usershares /var/lib/samba/usershares
# chmod 1770 /var/lib/samba/usershares

The first command creates the directory and any required parent directories. The next command sets the user and group ownership of the directory to root and usershares, respectively. The final command sets the owner and group permissions of the directory to Read/Write/Execute, denies access to everyone else, and sets the sticky bit. Thus, only root and members of the usershares group can use this directory; by virtue of the sticky bit, only the owner of a file can delete the file.

Setting up the share is perhaps the most difficult part of the exercise. A user can run:

net usershare add docs /home/me/Documents/ "My docs" Everyone:F

The above command exports /home/me/Documents as a share called docs with Full Control for everyone. Other commands allowed are:

• net usershare list lists the user shares the user has created.
• net usershare info docs shows the configuration of the docs share.
• net usershare delete docs removes the docs share.

Command-line tools

Samba comes with several command-line tools. Through the libsmbclient that Samba provides, other people have made SMB/Common Internet File System (CIFS) utilities that are in common use.

One striking difference between UNIX and Windows is that UNIX has one big file system, where Windows has a series of drive letters. The smbclient utility lets you browse a remote Windows share in an File Transfer Protocol (FTP)-like interface, but to be transparent to applications, a remote Windows share should be mountable like any other file system.

Samba comes with a utility called smbmount, which is sometimes repackaged as mount.cifs. You can call this command directly or through the mount command. Listing 3 shows a Linux system mounting a remote CIFS share onto the regular file system.

Listing 3. Mounting a remote CIFS share

# mount -t cifs '\\192.168.1.134\docs' /mnt -o user=myuser
Password:
# mount
...
\\\\192.168.1.134\\docs on /mnt type cifs (rw)

The first command mounts a CIFS file system on the given UNC path and places it on /mnt. Other than the UNC path, this looks like a standard mount invocation. Options are passed with the -o option. The only option needed here is the user name. The mount.cifs man page outlines all the other options, which can include a password and a domain. If you don't specify a password, you will be prompted for one. Finally, the mount command shows the mounted file system.

Another command is smbsh. Instead of mounting a file system through standard UNIX means, smbsh intercepts library calls for file requests and, if necessary, redirects the request to a CIFS share. Most systems do not ship with this command anymore, because it is not as reliable as mounting a file system.

Migrating file shares

When you move file services from one server to another, users may forget to access the new server. Samba allows you to have your server respond to another name. For example, if you move file shares from a server called phoenix to a server called fs2, you can have fs2 respond to requests for phoenix. You will, of course, have to make sure that phoenix doesn't respond, either by turning it off or renaming it.

To add an alias to a server, use the netbios aliases global parameter. If you want to change the name of a Samba server to something other than the UNIX name of the server, use the netbios name parameter.

The commands you have learned so far about mounting file systems will also be helpful in copying files from one server to another in preparation for a migration. You may also wish to use UNIX utilities like rsync to help out.

Moving forward

This is the end of the file shares topic. The next exam objective, 312.3, will have you creating and configuring print shares and learning how to access these shares from other systems.

Downloadable resources

• PDF of this content

Related topics

• The web version of the smb.conf man page is more convenient than the command-line version.
• The SMB HOWTO goes into much more detail about how to access remote file systems from a Linux machine.
• If you are using SELinux, this document on managing Samba and SELinux will come in handy, especially when configuring home directories.
• Review the entire LPI exam prep series on developerWorks to learn Linux fundamentals and prepare for systems administrator certification based on LPI exam objectives prior to April 2009.
• Get the latest Samba version so that you're up to date with the latest features.
• In the developerWorks Linux zone, find hundreds of how-to articles and tutorials, as well as downloads, discussion forums, and a wealth of other resources for Linux developers and administrators.
• Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
• Follow developerWorks on Twitter, or subscribe to a feed of Linux tweets on developerWorks.