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.
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
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
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
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.
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
[homes] section as a template for this
Listing 1 shows a typical
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
- 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
%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
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
case sensitive, which can be
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
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.
default case and
preserve case parameters work with each other.
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.
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
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
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
Second, the user must own the directory being shared unless
usershare owner only is set to
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 listlists the user shares the user has created.
net usershare info docsshows the configuration of the docs share.
net usershare delete docsremoves the docs share.
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
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
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
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
command shows the mounted file system.
Another command is
smbsh. Instead of mounting a
file system through standard UNIX means,
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.
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.
- 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.
- At the LPIC Program site, find detailed objectives, task lists, and sample questions for the three levels of the LPI's Linux systems administration certification. In particular, look at the LPI-302 detailed objectives and the tasks and sample questions.
- 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.
- Exam Preparation Resources for Revised LPIC Exams provides a list of other certification training resources maintained by LPI.
- 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.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
- Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
- Follow developerWorks on Twitter, or subscribe to a feed of Linux tweets on developerWorks.
Get products and technologies
- Get the latest Samba version so that you're up to date with the latest features.
- 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.
- Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
Dig deeper into Linux on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.