The [homes] Share
The [homes] share is a special directive. It doesn't correspond so much to a specific folder on your drive, like the [shared] share does above, but is more of an internal mechanism to indicate to Samba you want to share user home directories. Below is the default [homes] declaration:
[homes] comment = User Home Directories browseable = no read only = no create mode = 0750
You'll notice that the declaration starts out much like the [shared] declaration does, with the name of the share enclosed in brackets. You might be wondering at this point why there isn't a share labeled "homes" in the Network Neighborhood. Note that the browseable property for this share is set to no. This is what prevents the share labeled "homes" from appearing in Network Neighborhood. The other properties for this share are similar to our [shared] share above, though the default create mode is different. In this case, any new files will be read/write/execute by owner and read/execute by group, but no one else will have any access to the file. These are more conservative permissions for a user's home directory, while the [shared] share would want to be a little less secure due to its public nature.
Common Samba Directives
So far we've seen how to configure your machine's SMB settings, enable Windows sharing, and create additional disk shares. When configuring Samba, there are a lot of different directives you can use. Some of these directives affect Samba as a whole, others are specific to disk shares or print shares. Below I'll discuss some of the more commonly used directives and their intended uses.
SMB isn't the most secure protocol. It is designed to work on a local area network and tends to trust security to be handled by user authentication. This can be bad if your machine is directly connected to the Internet. A malicious person can examine what shares are available on your machine and attempt to access them. In order to lock things down a bit, it is possible to restrict only certain hosts to connect to Samba. To do this, add a "hosts allow" directive to your [global] section:
[global] hosts allow = localhost 192.168.1. . . .
This example will only allow access to those on the 192.168.1 network or from the machine itself. You can take this a step further by binding the Samba daemons to your LAN interface only by using the "interfaces" and "bind interfaces only" directives:
[global] interfaces = 192.168.1.29/255.255.255.0 bind interfaces only = yes . . .
The interface method can be difficult to maintain if you are using DHCP at all, since your interface's IP address might change, requiring a change to your configuration file. The hosts allow/hosts deny method is much easier. Many ISPs will filter the SMB ports as a security precaution. If you're attempting to use SMB over the Internet and wondering why it's not working, that could be why.
When accessing your Mac's shares from a Windows machine, you might
see a lot of files that begin with a period. Starting a file with a
period is a Unix convention, which is used to hide a folder or file in
most casual directory listings. A good example of this is the
.DS_Store file. The
.DS_Store file is used
to store Finder view preferences on Mac OS X. In order to keep these
files from showing up, you can use the "hide dot files" directive in
your smb.conf file:
[global] hide dot files = yes . . .
This will hide any files or folders which begin with a period. You can also use the "hide files" directive with a pattern to hide certain files. For example, to hide all files that have a .log extension:
[homes] hide files = /*.log/ . . .
Something important to note here is that these files are just hidden, they are still able to be accessed from the Windows machine. The files are given the equivalent of the FAT file system hidden attribute. This means that anyone who has "Show hidden files" or "Show hidden and system files" enabled in the Windows Explorer will still see these files. If you'd like to keep the files from being accessed at all, you can use the "veto files" directive:
[homes] veto files = /*passwd*/ . . .
This entry would keep all files that contain "passwd" in their file name from being shown at all. The Windows user would not even be able to tell they exist, unlike the "hide files" directive, which still allows access to a savvy user.
Restricting Directory Access
Samba also allows you to restrict access to directories within a
share. For example, let's say I want to restrict access to the
mp3 folder of my [shared] share. I have other
folders in the share that Windows users need access to, but I only
want users who access the machine directly to have access to the
mp3 folder. I can use the "dont descend" directive to
prevent this folder from being accessible by Windows users:
[shared] dont descend = mp3 . . .
The folder would still appear, but any Windows user who attempts to open the folder will be denied access. All other folders on the share would remain unaffected.
File and Directory Access
Earlier I mentioned the "create mode" directive. This directive is used to determine what permissions should be used when creating a file. Its companion directive, "directory mask", does the same thing for directories. One thing I want to clarify is how the masks are created. The masks are broken up into four positions. A single digit represents each position. The first position can be left out completely and often is. The next three positions represent owner, group, other, respectively. The owner corresponds to the user who is creating the file. The group will be that user's primary group. Other is everyone else.
To determine what digits to use, figure out what kind of access you want to give in each situation. The three types of access are read, write, and execute. In most cases, read/write will be sufficient for the owner. For the group and other permissions, think about who else might need to access the file and go from there. Once you know what kind of access is needed, follow this procedure: Start with 0, add 4 for read access, 2 for write access, and 1 for execute access. Thus if you want the owner to have read and write access, his group to have read access, and other to have no access, you'd use 640. If you want to give the owner and group read and write access, but other only read access, use 664.
For directories, it's the same procedure, but directories always require execute access in order to be opened. Thus if you want to create a directory that only he owner can use read and write to, you'd want 0700. If you are granting execute access, the user will need read access as well (you can't execute what you can't read). The file and directory masks can only be specified at the share level, it's not possible to have a folder within the share have a different mask. Also, there is no way from Windows to change these, but you can change them using the Inspector in the Finder or chmod in the Terminal.
Sharing a Printer
Samba also supports sharing a Unix-based printer with Windows
machines. Luckily Mac OS X now uses the Common Unix Printing System
(CUPS) for printing, so the lpr, lpq, and other Unix
printing commands will work with a printer you've added in Print
Center. You can also access the CUPS control panel by entering the URL
http://localhost:631 in your web browser. Sharing your
printer is a fairly easy process. The hardest part is configuring the
Windows machines with the proper driver. I've found that the
Generic/Text print driver works, but encountered problems when
printing PostScript using the Apple Color LaserWriter driver. These
problems were alleviated with a small shell script and portions of the
ESP Ghostscript package. I'll discuss this below, but your mileage may
The [printers] Share
The [printers] share is quite similar to the [homes]
share. Both shares are special in that they tell Samba to attempt to
create a share based on another field. In the case of the
[homes] share, that field is a username. With the
[printers] share, that field is a printer. Samba gets its list
of printers from the
/etc/printcap file. This file
contains a list of all printers that the machine currently knows
about. On Mac OS X, this usually corresponds to any local printers as
well as any discovered through Rendezvous. While it may be possible to
share a printer that is not directly attached to your Mac, for best
results you should only try to share printers that are connected right
to your machine.
The Samba directive that helps distinguish between a disk share and
a print share is "printable". If the printable property is set to true
(or yes), Samba will treat that share as a printer. With a print
share, the "path" directive is used to determine where the temporary
print file should be stored. The default is
should work just fine on Mac OS X. Samba handles printing by receiving
the document from the remote machine and storing it in a file in the
folder specified by the path directive. Samba will then use the
command specified by the "print command" directive to add the file to
the print queue. The excerpt below will use the
directory for all print files and will create a share for each entry
[printers] comment = All Printers path = /tmp browseable = no printable = yes guest ok = yes
As you can see, this share looks a lot like a disk share. The printable directive determines how the share is treated. Notice that the browseable property is set to no, much like how we set the [homes] share with the same value to prevent a ghost share from appearing. To specify which command is used to manipulate print jobs, you use the "print command" directive.
The print command directive is used to declare which program sends
print jobs to the print system. On Mac OS X, this command is
lpr, which is in the
/usr/bin directory. To use
lpr, you must specify which printer should handle the job and
what file is to be printed on its command line. In order to pass the
correct printer and filename to lpr, Samba offers two
variables: %p and %s. These represent the printer and the file
respectively. In Samba, you would end up with a print command
directive that looks something like /usr/bin/lpr -P%p -r
%s. Samba will substitute the real printer and filenames and
execute the command. lpr then takes the job and passes it to
the printing system. Here is an example of the print command directive
[global] . . . print command = /usr/bin/lpr -P%p -r %s