Samba is in such popular use that many Unix distributions come with it already installed. If you choose to use a bundled version of Samba, you can breeze through most of this chapter, but you'll be stuck with the Samba version and compile-time options your vendor selected for you. That version of Samba can't be any newer than the operating system release, so you're likely to be pretty far behind the latest developments. On the other hand, you can be fairly sure that a bundled version has been installed properly, and perhaps it will take only a few simple modifications to your smb.conf file for you to be off and running. Samba is mature enough that you probably don't need the latest release to meet your basic needs, so you might be perfectly happy running a bundled version.
If you choose this option, be aware that your Samba files, including the very important smb.conf, might be in different places than they would be if you were to install from a binary or source distribution. For example, with the Red Hat, Debian, and Mandrake Linux distributions, smb.conf and some other Samba-related files are in the /etc/samba directory.
$ smbd -V Version 2.2.6
You might also be able to use a system-specific tool to query a software-package maintenance utility. On Red Hat Linux, you can use the rpm command to query the installed packages for Samba:
$ rpm -qa | grep samba samba-client-2.0.8-1.7.1 samba-2.0.8-1.7.1 samba-common-2.0.8-1.7.1
# rpm -e samba # rpm -e samba-client # rpm -e samba-common
One point worth mentioning is that the Samba source requires an ANSI C compiler. If you are on a legacy platform with a non-ANSI compiler, such as the cc compiler on SunOS Version 4, you'll have to install an ANSI-compliant compiler such as gcc before you do anything else.[1] If installing a compiler isn't something you want to wrestle with, you can start off with a binary package. However, for the most flexibility and compatibility on your system, we always recommend compiling from the latest stable or production source.
A typical installation will take about an hour to complete, including downloading the source files and compiling them, setting up the configuration files, and testing the server.
Here is an overview of the steps:
If you would like to download the latest version of the Samba software, the primary web site is http://www.samba.org. Once connected to this page, you'll see links to several Samba mirror sites across the world, both for the standard Samba web pages and for sites devoted exclusively to downloading Samba. For the best performance, choose a site that is closest to your own geographic location.
The standard Samba web sites have Samba documentation and tutorials, mailing-list archives, and the latest Samba news, as well as source and binary distributions of Samba. The download sites (sometimes called F T P sites) have only the source and binary distributions. Unless you specifically want an older version of the Samba server or are going to install a binary distribution, download the latest source distribution from the closest mirror site. This distribution is always named:
samba-latest.tar.gz
which for the 2.2.6 release is an approximately 5MB file.
$ tar xvfz samba-latest.tar.gz
Or, if you do not have the GNU tar program (which also handles the unzipping):
$ gunzip samba-latest.tar.gz $ tar xvf samba-latest.tar
Samba automatically configures itself prior to compilation. This reduces the likelihood of a machine-specific problem, but you might end up wishing for an option after Samba has been installed.
The source distribution of Samba 2.2 and above doesn't initially have a makefile. Instead, one is generated through a GNU configure script, which is located in the samba-2.2.x /source/ directory. The configure script takes care of the machine-specific issues of building Samba.
NOTE
configure: warning: running as non-root will disable some tests
# ./configure | more
We will show you another in a moment.
# ./configure --with-winbind
# ./configure --help
Each option enables or disables various features. You typically enable a feature by specifying the --with-feature option, which will cause the feature to be compiled and installed. Likewise, if you specify a --without-feature option, the feature will be disabled. A full list of configuration options is provided in Appendix E, but for now we want to point out three of them, which are features we cover later in this book:
Include support for Microsoft Distributed filesystem (Dfs), which allows dispersed network resources to be clumped together into one easy-to-navigate directory tree. See Chapter 8.
Include SMB wrapper support, which allows programs running on the Unix host to access SMB shared folders as if they were Unix filesystems. We recommend using this option. See Chapter 5.
Include smbmount support, which allows SMB shared folders to be mounted in the Unix filesystem. At the time of this writing, support for this feature exists only for Linux. This is also covered in Chapter 5.
Each option is disabled by default, and none of the features is essential to Samba. However, you may want to include them in your configuration (as we will in our example) at least to be able to try out the options in later chapters.
In addition, Table 2-1 shows some other parameters that you can give the configure script if you wish to store parts of the Samba distribution in different places, perhaps to make use of multiple disks or partitions. Note that the defaults sometimes refer to a prefix specified earlier in the table.
Option |
Meaning |
Default |
---|---|---|
--prefix=directory |
Install architecture-independent files at the base directory specified. |
/usr/local/samba |
--eprefix=directory |
Install architecture-dependent files at the base directory specified. |
/usr/local/samba |
--bindir=directory |
Install user executables in the directory specified. |
eprefix/bin |
--sbindir=directory |
Install administrator executables in the directory specified. |
eprefix/bin |
--libexecdir=directory |
Install program executables in the directory specified. |
eprefix/libexec |
--datadir=directory |
Install read-only architecture-independent data in the directory specified. |
prefix/share |
--libdir=directory |
Install program libraries in the directory specified. |
eprefix/lib |
--includedir=directory |
Install package-include files in the directory specified. |
prefix/include |
--infodir=directory |
Install additional information files in the directory specified. |
prefix/info |
--mandir=directory |
Install manual pages in the directory specified. |
prefix/man |
Here is a sample execution of the configure script, which creates a Samba 2.2.6 makefile for the Linux platform. Note that you must run the configure script in the source directory and that we are showing you yet another way to capture the output of the script:
$ cd samba-2.2.6/source/ $ su Password: # ./configure --with-smbwrapper --with-smbmount \ --with-msdfs --with-syslog --with-utmp 2>&1 | tee config.my.log loading cache ./config.cache checking for gcc... (cached) gcc checking whether the C compiler (gcc -O ) works... yes checking whether the C compiler (gcc -O ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for a BSD-compatible install... (cached) /usr/bin/install -c ...(content omitted)... checking configure summary configure OK creating ./config.status creating include/stamp-h creating Makefile creating include/config.h
In general, any message from configure that
doesn't begin with the words
checking or
creating is an
error; it often helps to redirect the
output of the configure script to a file so that yo^rL>,u֗vo8]_´
L6[0O{%/4O
z1Ӣ4Bqjesp,㈦N0HJc㿝bAO}ch´7}ciVYyM(J4sz8LIVE'ucx^0"p-}!)I7A4 m{Pw^yff1ݞ_jqE }s( 't}0.̔IED(2\Ľa#hݯg[{[]V|`}oi47/dýU٣pEyb1
Mt6xV\В&)GZ(iҮ
>3Soeo"][ki[iwt8g0gE)8M|촾Vޥ}b4 I-D^UFYNC#Z3"D1'%x(ĜD**4rU&Q"nEi2eeeyxT11\LɘK,0R?Lrv$^b R4Lztf:ѯD{$=1qà_E2Y^(,3+zcex<%EM1vzY8OCả;eqXuYJss7쎈QiTǼƱ]N+GY`̢
}ZzQzɭ.sD\"i[Ͱ>V8lsiɻ1ۦM#zH@zm@'a%=n)}5;ƽ'muZ~O$zq$mpMG_'/AdT~ y6M42=b_
If you encounter a problem when compiling, first check the Samba documentation to see if it is easily fixable. Another possibility is to search or post to the Samba mailing lists, which are given at the end of Chapter 12 and on the Samba home page. Most compilation issues are system-specific and almost always easy to overcome.
Now that the files have been compiled, you can install them into the directories you identified with the command:
# make install
If you happen to be upgrading, your old Samba files will be saved with the extension .old, and you can go back to that previous version with the command make revert. After doing a make install, you should copy the .old files (if they exist) to a new location or name. Otherwise, the next time you install Samba, the original .old will be overwritten without warning and you could lose your earlier version. If you configured Samba to use the default locations for files, the new files will be installed in the directories listed in Table 2-2. Remember that you need to perform the installation from an account that has write privileges on these target directories; this is typically the root account.
Directory |
Description |
---|---|
/usr/local/samba |
Main tree |
/usr/local/samba/bin |
Binaries |
/usr/local/samba/lib |
smb.conf, lmhosts, configuration files, etc. |
/usr/local/samba/man |
Samba documentation |
/usr/local/samba/private |
Samba-encrypted password file |
/usr/local/samba/swat |
SWAT files |
/usr/local/samba/var |
Samba log files, lock files, browse list info, shared memory files, process ID files |
TIP
# make install 2>&1 | tee make-install.log Using FLAGS = -O -Iinclude -I./include -I./ubiqx -I./smbwrapper -D_LARGEFILE64 _SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLOGFILEBASE="/usr/local/samba/va r" -DCONFIGFILE="/usr/local/samba/lib/smb.conf" ...(content omitted)... The binaries are installed. You can restore the old binaries (if there were any) using the command "make revert". You can uninstall the binaries using the command "make uninstallbin" or "make uninstall" to uninstall binaries, manpages and shell scripts. ...(content omitted)... ====================================================================== The SWAT files have been installed. Remember to read the swat/README for information on enabling and using SWAT. ======================================================================
Eventually a new version of Samba will be released, and you will want to upgrade. This is simple; just repeat the same steps you used to install your current version. Download the source distribution from the Samba web site and install it, then run the ./configure, make, and make install commands as before. If you've forgotten which options you used with the configure script, take a look at the source/config.status file in your previous version's source distribution. The first few lines of this file show the options used the last time configure was run.
When you run the make install command to install your new version, the files of the previous version are replaced with the new ones, and then all you have to do is restart the Samba daemons to get your new version running. See Section 2.8 later in this chapter for directions on how to do this.
You will probably want to run commands included in the Samba distribution without having to specify their full directory paths. For that to work, the directory in which the Samba executables are located, /usr/local/samba/bin by default, must be added to your shell's PATH environment variable. This environment variable is usually set in one or more of the shell's startup files, which in the case of bash are /etc/profile (systemwide) and the .bash_profile and .bashrc files in each user's home directory.
To be able to read the Samba manual pages using the man command, the directory where Samba's manual pages reside, /usr/local/samba/man by default, must be in your MANPATH environment variable. On Red Hat Linux, this can be accomplished by adding the following two lines to /etc/man.config:
MANPATH /usr/local/samba/man MANPATH_MAP /usr/local/samba/bin /usr/local/samba/man
The Samba Web Administration Tool (SWAT) runs as a daemon under inetd or xinetd and provides a forms-based editor in your web browser for creating and modifying Samba's configuration file. For SWAT to work, entries must be added for it in the /etc/services and /etc/inetd.conf (or /etc/xinetd.d/swat) configuration files. To add the entries, follow these two steps:
swat 901/tcp
Now for inetd or xinetd. These are "Internet super daemons" that handle starting daemons on demand, instead of letting them sit around in memory consuming system resources. Most systems use inetd, but xinetd is also used in some versions of Unix, notably the Red Hat Linux (Versions 7 and newer) that we use in our examples. You can use the ps command to see which of the two your system is running.
swat stream tcp nowait root /usr/local/samba/bin/swat swat
Then force inetd to reread its configuration file by sending it a SIGHUP (hangup) signal:
# /bin/kill -HUP -a inetd
Notice that we are using a version of the kill command that supports the -a option, so as to allow us to specify the process by name. On FreeBSD and Linux, you can use the killall command[2] as follows:
# killall -HUP inetd
If you are not running Linux or FreeBSD and your version of kill doesn't have the -a option, you will need to use the ps command to find the process ID and then supply that to kill:
# ps ax | grep inetd 780 ? S 0:00 inetd 1981 pts/4 S 0:00 grep inetd # kill -HUP 780
If your system is using xinet, add a file named swat in your /etc/xinetd.d directory, containing the following:
# description: swat is the Samba Web Administration Tool, which # allows an administrator to configure Samba using a web # browser interface, with the URL http://localhost:901 service swat. { socket_type = stream wait = no protocol = tcp only_from = localhost user = root log_on_failure += USERID server = /usr/local/samba/bin/swat port = 901 disable = no }
Then xinetd needs to be sent a signal[3] to make it reread its configuration files:
# /bin/kill -HUP -a xinetd
And that's pretty much it for the installation. Before you can start up Samba, however, you need to create a configuration file for it.
The installation process does not automatically create an smb.conf configuration file, although several example files are included in the Samba distribution. To test the server software, though, we'll use the following file, which you can create in a text editor. It should be named smb.conf and placed in the /usr/local/samba/lib directory:[4]
[global] workgroup = METRAN [test] comment = For testing only, please path = /usr/local/samba/tmp read only = no guest ok = yes
This brief configuration file tells the Samba server to offer the /usr/local/samba/tmp directory on the server as an SMB share called test. The server also becomes part of the METRAN workgroup, of which each client must also be a part. If you have already chosen a name for your own workgroup, use the name of your workgroup instead of METRAN in the previous example. In case you are connecting your Samba system into an existing network and need to know the workgroup name, you can ask another system administrator or go to a Windows system in the workgroup and follow these instructions:
Windows 95/98/Me/NT: open the Control Panel, then double-click the Network icon. Click the Identification tab, and look for the "Workgroup:" label.
Windows 2000: open the Control Panel and double-click the System icon. Click the Network Identification tab. The workgroup name will appear below the computer name.
Windows XP: open the Control Panel in Classic View mode and double-click the System icon. Then click the Computer Name tab.
We'll use the [test] share in the next chapter to set up the Windows clients. For now, you can complete the setup by performing the following commands as root on your Unix server:
# mkdir /usr/local/samba/tmp # chmod 777 /usr/local/samba/tmp
You might also want to put a file or two in the /usr/local/samba/tmp directory so that after your Windows systems are initially configured, you will have something to use to check that everything works.
We should point out that in terms of system security, this is the worst setup possible. For the moment, however, we only wish to test Samba, so we'll leave security out of the picture. In addition, we will encounter some encrypted password issues with Windows clients later on, so this setup will afford us the least amount of headaches.
If your Windows clients are using Windows 98 or Windows NT 4 Service Pack 3 or above (including Windows 2000 and Windows XP) and you are using a version of Samba earlier than 3.0, you must add the following entry to the [global] section of the Samba configuration file:
[global] encrypt passwords = yes
In addition, you must use the smbpasswd program (typically located in the directory /usr/local/samba/bin/ ) to enter the username/password combinations of the Samba users into Samba's encrypted password database. For example, if you wanted to allow Unix user steve to access shares from a client system, you would use this command:
# smbpasswd -a steve New SMB password: Retype new SMB password: Added user steve.
Creating a configuration file with SWAT is even easier than writing a configuration file by hand. To invoke SWAT, use your web browser to connect to http://localhost:901, and log on as root with the root password, as shown in Figure 2-1.
After logging in, click the GLOBALS button at the top of the screen. You should see the Global Variables page shown in Figure 2-2.
Next, click the SHARES icon. You should see a page similar to Figure 2-3. Select test (to the right of the Choose Share button), and click the Choose Share button. You will see the Share Parameters screen, as shown in Figure 2-3, with the comment and path fields filled in from your smb.conf file.
Now click the VIEW button at the top, and SWAT shows you the following smb.conf file:
# Samba config file created using SWAT # from localhost (127.0.0.1) # Date: 2002/09/05 04:56:43 # Global parameters workgroup = METRAN encrypt passwords = Yes wins support = Yes [test] comment = For testing only! path = /usr/local/samba/tmp read only = No
Once this configuration file is completed, you can skip the next step because the output of SWAT is guaranteed to be syntactically correct.
The smb.conf file you have just created is certainly good enough for the purpose of initial setup and testing, and you can use it as a starting point from which to develop the configuration of your production Samba server. But before you get too far with that, we want to bring one thing to your attention.
[global] oplocks = no
We will cover opportunistic locking (oplocks) in more detail in the section "Locks and Oplocks" in Chapter 8, and recommend that you understand the ideas presented there before implementing a production Samba server that serves database files or other valuable data.
The test parser, testparm, examines an smb.conf file for syntax errors and reports any it finds along with a list of the services enabled on your machine. An example follows; you'll notice that in our haste to get the server running we mistyped workgroup as workgrp (the output is often lengthy, so we recommend capturing it with the tee command):
Load smb config files from smb.conf Unknown parameter encountered: "workgrp" Ignoring unknown parameter "workgrp" Processing section "[test]" Loaded services file OK. Press Enter to see a dump of your service definitions # Global parameters [global] workgroup = WORKGROUP netbios name = netbios aliases = server string = Samba 2.2.6 interfaces = bind interfaces only = No ...(content omitted)... [test] comment = For testing only! path = /usr/local/samba/tmp read only = No
The interesting parts are at the top and bottom. The top of the output will flag any syntax errors that you might have made, and the bottom lists the services that the server thinks it should offer. A word of advice: make sure you and the server have the same expectations.
Used by Windows 2000/XP when NetBIOS over TCP/IP is disabled
For more information on configuring firewalls, see the O'Reilly book Building Internet Firewalls.
Two Samba processes, smbd and nmbd, need to be running for Samba to work correctly. There are three ways to start them:
If you're in a hurry, you can start the Samba daemons by hand. As root, simply enter the following commands:
# /usr/local/samba/bin/smbd -D # /usr/local/samba/bin/nmbd -D
To have the Samba daemons started automatically when the system boots, you need to add the commands listed in the previous section to your standard Unix startup scripts. The exact method varies depending on the flavor of Unix you're using.
With a BSD-style Unix, you need to append the following code to the rc.local file, which is typically found in the /etc or /etc/rc.d directories:
if [ -x /usr/local/samba/bin/smbd]; then echo "Starting smbd..." /usr/local/samba/bin/smbd -D echo "Starting nmbd..." /usr/local/samba/bin/nmbd -D fi
With System V, things can get a little more complex. Depending on your Unix version, you might be able to get away with making a simple change to an rc.local file as with BSD Unix, but System V typically uses directories containing links to scripts that control daemons on the system. Hence, you need to instruct the system how to start and stop the Samba daemons. The first step to implement this is to modify the contents of the /etc/rc.d/init.d directory by adding something similar to the following shell script, which for this example we will name smb :
#!/bin/sh # Check that the Samba configuration file exists [ -f /usr/local/samba/lib/smb.conf ] || exit 0 start( ) { echo -n "Starting SMB services: " /usr/local/samba/bin/smbd -D ERROR=$? echo echo -n "Starting NMB services: " /usr/local/samba/bin/nmbd -D ERROR2=$? if [ $ERROR2 -ne 0 ] then ERROR=1 fi echo return $ERROR } stop( ) { echo -n "Shutting down SMB services: " /bin/kill -TERM -a smbd ERROR=$? echo echo -n "Shutting down NMB services: " /bin/kill -TERM -a nmbd ERROR2=$? if [ $ERROR2 -ne 0 ] then ERROR=1 fi echo return $ERROR } case "$1" in start) start ;; stop) stop ;; *) echo "Usage: $0 {start|stop}" exit 1 esac exit $?
With this script, you can start and stop smbd and nmbd like this:
# /etc/rc.d/init.d/smb start Starting SMB services: Starting NMB services: # ps ax | grep mbd 1268 ? S 0:00 /usr/local/samba/bin/smbd -D 1270 ? S 0:00 /usr/local/samba/bin/nmbd -D 1465 pts/2 S 0:00 grep mbd # /etc/rc.d/init.d/smb stop Shutting down SMB services: Shutting down NMB services:
Finally, we need to add symbolic links to the smb script in the /etc/rc.d/rcX.d directories:
# ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc3.d/S35smb # ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc5.d/S35smb # ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc0.d/K35smb # ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc1.d/K35smb # ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc2.d/K35smb # ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc4.d/K35smb # ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc6.d/K35smb
An installation of Samba is bundled with the Darwin distribution, which is included in Mac OS X.[5]
The Samba daemons are started during system boot by the script /System/Library/StartupItems/Samba/Samba. To trigger the execution of this script, edit the file /etc/hostconfig and change the SMBSERVER parameter to look like this:
SMBSERVER=-YES-
On Mac OS X, the graphical user interface (GUI) provides an alternative to using the command line. Launch the System Preferences application, and select Sharing (see Figure 2-4). Under the Services tab, turn on Windows File Sharing. This will make the aforementioned change to /etc/hostconfig and immediately execute the startup item.
#!/bin/sh # Start Samba . /etc/rc.common if [ "${SMBSERVER:=-NO-}" = "-YES-" ]; then ConsoleMessage "Starting SMB server" if [ -f /usr/local/samba/lib/smb.conf ]; then /usr/local/samba/bin/smbd -D /usr/local/samba/bin/nmbd -D fi fi
# chflags uchg /System/Library/StartupItems/Samba/Samba
If you can afford a few minutes of downtime, reboot your system and again use the ps command to check that the smbd and nmbd daemons are running. And if you are managing a 24/7 server, we highly recommend that you find some downtime in which to reboot and perform this check. Otherwise, your next unscheduled downtime might surprise you with a mysterious absence of SMB networking services when the system comes up again!
The inetd [6] daemon is a Unix system's Internet "super daemon." It listens on ports defined in /etc/services and executes the appropriate program for each port, which is defined in /etc/inetd.conf. The advantage of this scheme is that you can have a large number of daemons ready to answer queries, but they don't all have to be running all the time. Instead, inetd listens for connection requests and starts the appropriate daemon when it is needed. The penalty is a small overhead cost of creating a new daemon process, as well as the fact that you need to edit two files rather than one to set things up. The inetd daemon is handy if you have only one or two Samba users or your machine is running too many daemons already. It's also easier to perform an upgrade without disturbing an existing connection.
If you wish to start from inetd, first open /etc/services in your text editor. If you don't already have them defined, add the following two lines:
netbios-ssn 139/tcp netbios-ns 137/udp
Next, edit /etc/inetd.conf. Look for the following two lines and add them if they don't exist. If you already have smbd and nmbd lines in the file, edit them to point at the new smbd and nmbd you've installed. Your brand of Unix might use a slightly different syntax in this file; use the existing entries and the inetd.conf manual page as a guide:
netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd netbios-ns dgram udp wait root /usr/local/samba/bin/nmbd nmbd
Finally, kill any smbd or nmbd processes and send the inetd process a hangup (HUP) signal to tell it to reread its configuration file:
# /bin/kill -TERM -a smbd # /bin/kill -TERM -a nmbd # /bin/kill -HUP -a inetd
After that, Samba should be up and running.
As we've pointed out before, Red Hat and perhaps other Unix vendors supply xinetd rather than inetd. If you need to use xinetd, you will need to supply a configuration file in the /etc/xinetd.d directory.
We're nearly done with the Samba server setup. All that's left to do is to make sure everything is working as we think it should. A convenient way to do this is to use the smbclient program to examine what the server is offering to the network. If everything is set up properly, you should be able to do the following:
# /usr/local/samba/bin/smbclient -U% -L localhost added interface ip=172.16.1.1 bcast=172.16.1.255 nmask=255.255.255.0 Domain=[METRAN] OS=[Unix] Server=[Samba 2.2.6] Sharename Type Comment --------- ---- ------- test Disk For testing only, please IPC$ IPC IPC Service (Samba 2.2.6) ADMIN$ Disk IPC Service (Samba 2.2.6) Server Comment --------- ------- TOLTEC Samba 2.2.6 on toltec Workgroup Master --------- ------- METRAN TOLTEC
If there is a problem, don't panic! Try to start the daemons manually, and check the system output or the debug files at /usr/local/samba/var/log.smb to see if you can determine what happened. If you think it might be a more serious problem, skip to Chapter 12 for help on troubleshooting the Samba daemons.
If it worked, congratulations! You now have successfully set up the Samba server with a disk share. It's a simple one, but we can use it to set up and test the Windows 95/98/Me and NT/2000/XP clients in the next chapter. Then we will start making it more interesting by adding services such as home directories, printers, and security, and by seeing how to integrate the server into a larger Windows domain.
[1] gcc binaries are available for almost every modern machine. See http://www.gnu.org/ for a list of sites with gcc and other GNU software.
[2] Do not confuse this with the Solaris killall command, which performs part of the system shutdown sequence!
[3] Depending on the version of xinetd you have and how it was compiled, you might need to send a USR1 or some other signal rather than the HUP signal. Check the manual page for xinetd (8) on your system for details.
[4] If you did not compile Samba, but instead downloaded a binary, check with the documentation for the package to find out where it expects the smb.conf file to be. Or, try running the testparm program and look for the location of smb.conf in the first line of output. If Samba came preinstalled with your Unix system, an smb.conf file is probably already somewhere on your system.
[5] In this book, we cover Darwin Version 6.0 and OS X Version 10.2.
[6] With early releases of Samba 2.2, there were reports of intermittent errors when starting from inetd. We provide this information so that it will be available for later releases when the problem will hopefully have been identified and corrected.