4.5. Example Shares
Knowing what the parameters are that control Samba share definitions and knowing how to use those parameters are two different things. Failing to see the forest for the trees, as it were, is easy to do when confronted with a list of Samba parameters. For this reason, this chapter concludes with a look at several common uses of Samba file and printer shares: the [homes] share, which provides users with data storage space for their own files; a share that can store program files, templates, and other shared read-only files; shares for exchanging files between users; a closer look at the [printers] share introduced earlier; and a "printer" share that generates PDF files rather than paper printouts.
4.5.1. The [homes] Share
Many Samba server computers function, in whole or in part, as centralized storage locations for users' files. Users store their important files on the Samba server, enabling them to store more or larger files than would fit on their clients' disks and to move from one client to another and access their own home files. This strategy can also greatly simplify backup; if users' data files are on a single server, that server can be backed up more easily than can an entire network's worth of files, thus providing more reliable insurance in case of hardware failure.
The user data storage function is so important that Samba provides a special share name just for this purpose: [homes]. This share functions much like an ordinary file share but with several important differences:
A typical [homes] share definition can be quite short:
[homes] comment = Home Directories writeable = Yes create mask = 644 browseable = No
The Samba default is to make shares read-only, but because the intended [homes] shares enable users to store files that they create, changing this default is particularly important for these shares. The create mask = 644 parameter isn't necessary, and, in fact, it's undesirable if you want to preserve the archive bit on files. Using this parameter keeps the owner execute bit from being set, though, which may be desirable if users make heavy use of shell access or access via NFS or some other means that preserves this bit as such.
Ordinarily, shares on which you set browseable = No aren't visible in file browsers, but [homes] shares are exceptions to this rule. Specifically, the browseable parameter applies to the share called HOMES; if you omit the browseable = No parameter or set it to Yes, a share called HOMES appears in clients' network browsers. Part of the definition of the [homes] share is that a share named after the user who accesses the server appears in the user's browse lists. (Only the home share for the user who accesses the server is displayed; users won't see other users' home shares, although they can be accessed by entering their names directly.)
This example share doesn't specify a directory or path; it relies on the [homes] default. Although you can set a directory for the share, setting a static directory is usually undesirable. If you want to provide users with different home directories for remote text-mode or GUI logins than for Samba access, you can specify a Samba directory that is unique for each user by including variables such as %S, %u, or %U; these variables all expand to values related to the username. (In many cases, they expand to the same value.) For instance, you might set the path like this:
path = /home/samba/%u
Many sample smb.conf files include [homes] shares, so this share may already exist on your server. Of course, if you don't need it, you can delete it or change the definition to suit your particular needs.
4.5.2. A Windows Program Share
Samba servers can also be used as central repositories for files that many clients must access in a read-only mannerprogram executables, templates, clip art, fonts, and so on. Most users have no need to write to such shares, so most users receive read-only access. Somebody must maintain these shares, though, so a write list parameter provides an exception to the rule:
[programs] comment = Program Files for All Users path = /usr/share/samba/windows-programs write list = linnaeus, mendel force user = linnaeus force group = users read only = Yes create mask = 660 directory mask = 770
In addition to the write list, this example share includes force user and force group parameters. These parameters force all files to be owned by a single user and group; even those files written by mendel will be owned by linnaeus, which makes for a cleaner on-server set of ownerships; however, this also means you can't track whoever installed a particular file. These parameters also guarantee that all users will be able to read the files in the share, at least assuming that no files are written to the share through non-Samba means. Note that the force user parameter in conjunction with write list does not give all users write access to the share; write list applies to users' true logon usernames, not their identities as determined by force user.
If you create a share like this, be sure to set appropriate permissions on the share's directory (/usr/share/samba/windows-programs in this example). If you don't give linnaeus write access to the directory, neither linnaeus nor mendel can store files in the share. You may also want to consider local Samba server security issues. For instance, if the share contains files that shouldn't be accessible to some non-Samba users of the server, you should set create mask and directory mask parameters that deny world access (as in the example) and ensure that these users aren't in the group specified by force group.
4.5.3. File-Exchange Shares
A read-only share such as the [programs] share is relatively straightforward to configure. A share that's used for data exchange between users is much more complex because you must decide how to set ownership and permissions that enable those who should be able to write to files to do so, while preventing those who shouldn't. Several approaches to solving this problem exist:
Precisely how you would configure such a share depends on which approach you take and on your Linux server's local security configuration. For one example, consider this file share:
[sanescientists] comment = Share for Use by Sane Scientists Only path = /usr/share/samba/sane valid users = @sane, linnaeus, mendel, curie writeable = Yes force group = sane create mask = 660 directory mask = 770 [madscientists] comment = Share for Use by Mad Scientists Only path = /usr/share/samba/mad valid users = @mad, morbius, moreau, frankenstein writeable = Yes force group = mad create mask = 660 directory mask = 770
These two shares, in combination, provide separate file-exchange areas for two groups of users. The first grants access to all members of the Linux sane group, plus three others who might or might not be members of that group. The second share does the same for the mad group and three other users. You can include a user in both groups if you like, in which case that user has access to both shares. For instance, you can place the user jekyl in both the sane and mad groups, or add the user explicitly to one or both shares' valid users lines. If you want to give one group read-only access to another group's shares, add the members of both groups to the share's valid users line but use read list to restrict some users' access to the share.
Another way to implement a similar system is to create a single share:
[scientists] comment = Share for Use by All Scientists path = /usr/share/samba/scientists valid users = @sane, @mad writeable = Yes inherit permissions = Yes
You then create subdirectories within the share's directory with appropriate permissions set to enable only members of particular groups to access the directories. The result might look like this, as viewed using Linux's ls:
# ls -l /usr/share/samba/scientists total 8 drwxrwx--- 2 root mad 4096 May 2 14:47 mad drwxrwx--- 2 root sane 4096 May 2 14:47 sane
The result is that members of the mad group can exchange files in the mad subdirectory, and members of the sane group can exchange files in the sane subdirectory. As configured, members of each group can't view the contents of or read files from the other group's subdirectory unless the individual is a member of both Linux groups. By changing permissions on the directories to 775 (rwxrwxr-x) rather than 770 (rwxrwx---), you can enable members of the groups to read but not write files in each others' directories. Because of the reliance on the local Linux groups, this scheme doesn't work well if some users aren't members of the underlying groups; this is the reason the individual users (linnaeus, morbius, and so on) were omitted from the valid users line in the share definition. You should also attend to ownership and permissions on the share directory itself; depending on its settings, users could create new subdirectories, which can complicate your security settings.
These are just two examples of common-access file shares. Many variants and alternatives are possible, that use Samba's security features, Linux's security features, or an interaction of the two. As a general rule, it's best to start with a simple security system; trying to use too many sophisticated features can lead you into trouble if you forget an important consequence or interaction.
4.5.4. The [printers] Share
Most print servers use a single [printers] share to make all printers available. This share can consist of just a few lines, but it relies on a few global settings, and some of its implications deserve elaboration. First, before defining a [printers] share, be sure to set the following parameters in the [global] section of smb.conf:
printing = CUPS printcap name = CUPS load printers = Yes printer admin = gutenberg guest ok = Yes
In this example, the printing and printcap name parameters are both set to CUPS, which tells Samba to use CUPS for printing, including using CUPS' own API for determining what printers are available. Of course, if you use another printing system, you'll change these parameters appropriatelysay, to printing = LPRng and printcap name = /etc/printcap.
The load printers = Yes parameter tells Samba to read information on available local printers from the file pointed to by printcap name (or, if printcap name = CUPS, to read the data using the CUPS API). By itself, this doesn't do anything; only if you provide an explicit [printers] share does this parameter have any effect.
The printer admin line is optional; it sets the Linux username of a printer administratora user whose accesses to printer shares are done as if by root. This user should be able to delete others' print jobs and otherwise perform maintenance on the queues.
The guest ok = Yes parameter tells Samba to accept guest access to the printer shares. This can be handy if you don't want to maintain a user database on a dedicated print server, but you'll need to adjust the global map to guest and guest account parameters. Enabling guest access also opens the system to potential abuses, particularly if the server is accessible to the Internet at large. (Imagine coming in one morning to discover that a high-speed, high-capacity printer has printed its entire load of paper with completely black pages, wasting both paper and toner or ink.)
Once you've set the global options, you can create a [printers] share. This share is likely to be fairly uninteresting on the surface:
[printers] comment = All Printers path = /var/spool/samba printable = Yes
Once this share is defined, and Samba either detects the changes (which it should do after a few minutes) or is restarted, you should see printer shares corresponding to all of your local printers that appear in clients' network browsers. The shares won't be usable, though; you must first install printer drivers on the clients, as described in Section 4.4.
Using a [printers] share doesn't mean that you're restricted from creating other printer shares. You can do so in either of two ways:
The shares generated by [printers] may be PostScript printers, non-PostScript printers that appear to clients as PostScript printers because of the use of Ghostscript in the Linux printer queue, or non-PostScript printers with raw Linux printer queues for which native printer drivers are necessary on the clients. In fact, you can provide a mixture of share types; the [printers] share simply doesn't care.
4.5.5. A PDF-Generation Printer Share
Samba printer shares can be unusually flexible. This flexibility is derived, in part, from the print command parameter, which enables you to bypass the usual print processing. In fact, you can do some extremely complex and unusual things with this parameter, but in this section I describe a use that's at least related to printing: creating Portable Document Format (PDF) files.
Several tools exist to generate PDF files from various formats. One of these is almost certainly already installed on your Linux computer: Ghostscript. In addition to generating output in formats that can be printed by your printer, Ghostscript can generate several common file formats, such as Tagged Image File Format (TIFF), Portable Network Graphics (PNG), and PDF. To create a Samba share that generates a PDF file, you call Ghostscript (with appropriate parameters) as the print command:
[makepdf] comment = Share to Make PDFs path = /var/spool/samba printable = Yes print command = gs -dNOPAUSE -dBATCH -q -sDEVICE=pdfwrite \ -sOutputFile=%H/%s.pdf; rm %s
When the MAKEPDF share receives a PostScript file, it passes it through Ghostscript (gs), specifying various parameters to generate PDF output without prompts and saving the output as %H/%s.pdf. Because %H is the user's home directory and %s is the print job's filename, the result is a file whose name begins with the Samba print job name and ends in .pdf. This filename is likely to be ugly, but it will at least be unique. The print command line ends with rm %s, which deletes the original print job, keeping it from cluttering the disk.
Of course, the [makepdf] share, as just presented, requires users to have access to their home directories, presumably through a [homes] share. If this isn't true of your system, you can deliver the results in some other ways. For instance, you might have Samba email the PDF files to users. If necessary, you can write a script that passes the file through Ghostscript, looks up users' email addresses in a list, and sends the file. Then call the script on the print command line, passing it whatever Samba variables you need, such as the print job filename (%s) and the username (%u or %U).
To clients, this particular share is indistinguishable from a real printer's share. Because it expects PostScript input, you should install PostScript drivers on clientsideally a fairly generic PostScript driver. Instead of printed output, though, users will find PDF files in their home directories soon after printing documents. This share can be a good way to provide basic PDF-generation capabilities to all users in all their programs that can print. It might not be enough for all functions; some dedicated PDF-generation tools support features that aren't available through Ghostscript or Windows PostScript printer drivers.