|
|
This chapter wraps up our coverage of the smb.conf configuration file with some miscellaneous options that can perform a variety of tasks. We talk briefly about options for time synchronization, internationalization, messages, and common Windows bugs. For the most part, you will use these options only in isolated circumstances.
In a network of computers, the systems on the network must agree on the current time and also on what time files have been modified. One example of the importance of synchronization is the roaming profiles we covered in Chapter 4. It is vital for all clients accessing a roaming profile to agree on what time it is and which client last modified the user's profile.
Time synchronization can also be very important to programmers. A useful group of settings consists of the following options:
[global] time server = yes dos filetimes = yes fake directory create times = yes dos filetime resolution = yes delete readonly = yes
If you set these options, Samba shares will provide compatibility of file-modification times that Visual C++, nmake, and other Microsoft programming tools require. Otherwise, PC make programs might think that all the files in a directory need to be recompiled every time. Obviously, this is not the behavior you want.
In Chapter 4, we showed you how to create a logon script that used the net time command to synchronize clients' clocks automatically when they log on to the domain. If your network is configured as a workgroup rather than a domain, you can still make use of net time by placing the command:
net time \\sambaserver /set /yes
in a startup script on each client that is run when the system boots. Samba always provides time service—regardless of whether it is running as a primary domain controller—or the time service configuration file parameter is set.
Assuming that domain users log on to the domain at least once per day and workgroup clients reboot frequently, the net time command can keep client systems' clocks fairly well synchronized. However, sometimes domain users stay logged on for longer periods, and workgroup clients can run for days between reboots. In the meantime, the systems' hardware clocks can wander enough to become a problem. It might be possible to work around this, depending on the version of Windows the client system is running. On Windows 98/Me, you can use the Task Scheduler to run the net time command at regular intervals. Likewise, on Windows 2000/XP you can use the MS-DOS at command. However, a better way to deal with this issue is to use Network Time Protocol, which we will discuss shortly.
Proper time synchronization is also important when operating in an Active Directory domain because Active Directory uses Kerberos authentication. When a Kerberos domain controller creates an authentication ticket for a client, the time is encoded into the challenge-and-response exchanges between the client and domain controller. If the client's clock disagrees with the server's clock, authentication can fail.
To provide proper time synchronization in Active Directory domains, Microsoft has adopted Network Time Protocol (NTP), using the name Windows Time Service for its implementation. For further information, the Microsoft white paper entitled The Windows Time Service can be downloaded from http://www.microsoft.com.
The nice thing about this is that NTP is the standard method for synchronizing Unix hosts on a network, so you can synchronize all your Unix systems (including the Samba server) and Windows systems with the following method:
Run NTP on the Unix systems in your network. For more information on using NTP, refer to http://www.ntp.org.
Use one of the Unix systems (such as the Samba host system) as an NTP server to serve Windows 2000/XP clients.
For other Windows clients, you might have to download an update from Microsoft to add Windows Time Service client support or use a third-party application such as the free analogX Atomic TimeSync (http://www.analogx.com). Or you can use the net time command to update the client's clock periodically, as discussed previously.
To support roaming profiles, programmers accessing your Samba server, and other time-sensitive functions on your network, you'll want to be aware of the options listed in Table 11-1.
Option |
Parameters |
Function |
Default |
Scope |
---|---|---|---|---|
time server |
Boolean |
If yes, announces nmbd as an SMB time service to Windows clients |
no |
Global |
time offset |
numeric |
Adds a specified number of minutes to the reported time |
0 |
Global |
dos filetimes |
Boolean |
Allows non-owners of a file to change its time if they can write to it |
no |
Share |
dos filetime resolution |
Boolean |
Causes file times to be rounded to the next even second |
no |
Share |
fake directory create times |
Boolean |
Sets directory times to avoid an MS nmake bug |
no |
Share |
Samba always operates as an SMB time server, matching the behavior of Windows systems. However, Samba's default is not to advertise itself as a time server to the network. When this option is set to yes, Samba advertises itself as an SMB time server:
[global] time service = yes
To deal with clients that don't properly process daylight savings time, Samba provides the time offset option. If set, it adds the specified number of minutes to the current time. This is handy if you're in Newfoundland and Windows doesn't know about the 30-minute time difference there:
[global] time offset = 30
Traditionally, only the root user and the owner of a file can change its last-modified date on a Unix system. The share-level dos filetimes option allows the Samba server to mimic the characteristics of a DOS or Windows system: any user can change the last-modified date on a file in that share if she has write permission to it. To do this, Samba uses its root privileges to modify the timestamp on the file.
By default, this option is disabled. Setting this option to yes is often necessary to allow PC make programs to work properly. Without it, they cannot change the last-modified date themselves. This often results in the program thinking all files need recompiling when they really don't.
The dos filetime resolution parameter is a share-level option. If set to yes, Samba rounds file times to the closest 2-second boundary. This option exists primarily to satisfy a quirk in Windows that prevents Visual C++ from correctly recognizing that a file has not changed. You can enable it as follows:
[data] dos filetime resolution = yes
We recommend using this option only if you are using Microsoft Visual C++ on a Samba share that supports opportunistic locking.
The fake directory create times option exists to keep PC make programs sane. VFAT and NTFS filesystems record the creation date of a specific directory, while Unix does not. Without this option, Samba takes the earliest recorded date it has for the directory (often the last-modified date of a file) and returns it to the client. If this is not sufficient, set the following option under a share definition:
[data] fake directory create times = yes
If set, Samba will adjust the directory create time it reports to the hardcoded value January 1, 1980. This is primarily used to convince the Visual C++ nmake program that any object files in its build directories are indeed younger than the creation date of the directory itself and need to be recompiled.
Magic scripts are a method of running programs on Unix and redirecting the output back to the SMB client. These are essentially an experimental hack. However, some users and their programs still rely on these two options for their programs to function correctly. Magic scripts are not widely trusted, and their use is highly discouraged by the Samba Team.
Table 11-2 lists the options that deal with magic scripts on the Samba server.
Option |
Parameters |
Function |
Default |
Scope |
---|---|---|---|---|
magic script |
string (filename) |
File to be executed by Samba, as the logged-on user, when closed |
None |
Share |
magic output |
string (filename) |
File to log output from the magic file |
scriptname.out |
Share |
If the magic script option is set to a filename and the client creates a file by that name in that share, Samba will run the file as soon as the user has opened and closed it. For example, let's assume that the following option was created in the share [accounting]:
[accounting] magic script = tally.sh
Samba continually monitors the files in that share. If one by the name of tally.sh is closed (after being opened) by a user, Samba will execute the contents of that file locally. The file will be passed to the shell to execute; it must therefore be a legal Unix shell script. This means that it must have newline characters as line endings instead of Windows CRLFs. In addition, you need to use the #! directive at the beginning of the file to indicate under which shell or interpreter the script should run, unless the script is for the default shell on your system.
This option specifies an output file to which the script specified by the magic script option will send output. You must specify a filename in a writable directory:
[accounting] magic script = tally.sh magic output = /var/log/magicoutput
If this option is omitted, the default output file is the name of the script (as stated in the magic script option) with the extension .out appended onto it.
Starting with Samba 3.0, Samba supports Unicode "on the wire," requiring no additional effort on your part to support filenames and other text containing characters in international character sets.
Samba 2.2.x has a limited ability to speak foreign tongues: if you need to support filenames containing characters that aren't in standard ASCII, some options that can help you are shown in Table 11-3.
Option |
Parameters |
Function |
Default |
Scope |
---|---|---|---|---|
client code page |
Described in this section |
Sets a code page to expect from clients |
850 |
Global |
character set |
Described in this section |
Translates code pages into alternate Unix character sets |
None |
Global |
coding system |
Described in this section |
Translates code page 932 into an Asian character set |
None |
Global |
valid chars |
string (set of characters) |
Adds individual characters to a code page |
None |
Global |
The character sets on Windows platforms hark back to the original concept of a code page. These code pages are used by DOS and Windows clients to determine rules for mapping lowercase letters to uppercase letters. Samba can be instructed to use a variety of code pages through the use of the global client code page option to match the corresponding code page in use on the client. This option loads a code page definition file and can take the values specified in Table 11-4.
Code page |
Definition |
---|---|
437 |
MS-DOS Latin (United States) |
737 |
Windows 95 Greek |
850 |
MS-DOS Latin 1 (Western European) |
852 |
MS-DOS Latin 2 (Eastern European) |
861 |
MS-DOS Icelandic |
866 |
MS-DOS Cyrillic (Russian) |
932 |
MS-DOS Japanese Shift-JIS |
936 |
MS-DOS Simplified Chinese |
949 |
MS-DOS Korean Hangul |
950 |
MS-DOS Traditional Chinese |
You can set the client code page as follows:
[global] client code page = 852
The default value of this option is 850, for MS-DOS Latin 1. You can use the make_smbcodepage tool that comes with Samba (by default in /usr/local/samba/bin ) to create your own SMB code pages, in the event that those listed earlier are not sufficient.
The global character set option can be used to convert filenames offered through a DOS code page (see the previous section, Section 11.3.1.1) to equivalents that can be represented by Unix character sets other than those in the United States. For example, if you want to convert the Western European MS-DOS character set on the client to a Western European Unix character set on the server, you can use the following in your configuration file:
[global] client code page = 850 character set = ISO8859-1
Note that you must include a client code page option to specify the character set from which you are converting. The valid character sets (and their matching code pages) that Samba accepts are listed in Table 11-5.
Character set |
Matching code page |
Definition |
---|---|---|
ISO8859-1 |
850 |
Western European Unix |
ISO8859-2 |
852 |
Eastern European Unix |
ISO8859-5 |
866 |
Russian Cyrillic Unix |
ISO8859-7 |
737 |
Greek Unix |
KOI8-R |
866 |
Alternate Russian Cyrillic Unix |
Normally, the character set option is disabled completely.
The coding system option is similar to the character set option. However, its purpose is to determine how to convert a Japanese Shift JIS code page into an appropriate Unix character set. To use this option, the client code page option described previously must be set to page 932. The valid coding systems that Samba accepts are listed in Table 11-6.
Character set |
Definition |
---|---|
SJIS |
Standard Shift JIS |
JIS8 |
Eight-bit JIS codes |
J8BB |
Eight-bit JIS codes |
J8BH |
Eight-bit JIS codes |
J8@B |
Eight-bit JIS codes |
J8@J |
Eight-bit JIS codes |
J8@H |
Eight-bit JIS codes |
JIS7 |
Seven-bit JIS codes |
J7BB |
Seven-bit JIS codes |
J7BH |
Seven-bit JIS codes |
J7@B |
Seven-bit JIS codes |
J7@J |
Seven-bit JIS codes |
J7@H |
Seven-bit JIS codes |
JUNET |
JUNET codes |
JUBB |
JUNET codes |
JUBH |
JUNET codes |
JU@B |
JUNET codes |
JU@J |
JUNET codes |
JU@H |
JUNET codes |
EUC |
EUC codes |
HEX |
Three-byte hexadecimal code |
CAP |
Three-byte hexadecimal code (Columbia AppleTalk Program) |
The valid chars option can be used to add individual characters to a code page. You can use this option as follows:
valid chars = Î valid chars = 0450:0420 0x0A20:0x0A00 valid chars = A:a
Each character in the list specified should be separated by spaces. If there is a colon between two characters or a numerical equivalent, the data to the left of the colon is considered an uppercase character, while the data to the right is considered the lowercase character. You can represent characters both by literals (if you can type them) and by octal, hexadecimal, or decimal Unicode equivalents.
If you use this option, it must be listed after the client code page to which you wish to add the character.
One of the odd features of SMB protocol is its ability to send text messages between computers. Although both the name and functionality are similar to that of Windows Messenger, the two are not the same. Windows Messenger (also called MSN Messenger) is an Internet-oriented instant messenging service, while Windows Messenger Service is an older and simpler LAN-oriented service. Using the Windows Messenger Service, messages can be addressed to users, individual computers, or entire workgroups on the network.
The WinPopup tool (Winpopup.exe), shown in Figure 11-1, can be used on Windows 95/98/Me to send or receive messages. WinPopup is a handy tool for sending messages. However, to receive messages, it must already be running when the message is sent from the remote system.
On Windows NT/2000/XP, the messenger service lets you receive messages without having an application already running; messages will automatically appear in a small dialog box on the screen when received, as shown in Figure 11-2.
To send messages, it is necessary to use the net send command from a command-prompt window, like this:
C:\> net send maya "Who's There?" The message was successfully sent to MAYA.
Samba has a single option to handle Windows Messenger Service, message command, as shown in Table 11-7.
Option |
Parameter |
Function |
Default |
Scope |
---|---|---|---|---|
message command |
string (shell command) |
Sets a command to run on Unix when a WinPopup message is received |
None |
Global |
Samba's message command option defines the command that will run on the server when a Windows Messenger Service message arrives. The command will be executed as the guest account user. What to do with messages is questionable because most Samba hosts run as unattended servers. One solution is to mail the messages to root like this:
[global] message command = /bin/mail -s "SMB Message From %f on %m" root <%s; rm %s
Note the use of variables here. The %s variable will be replaced by the name of the file in which the message resides. This file should be deleted when the command is finished with it; otherwise, a buildup of message files will collect on the Samba server. In addition, the command must either exit quickly or fork its own process (using an & after the command); otherwise, the client might suspend and wait for notification that the command was sent successfully before continuing.
In addition to the standard variables, Table 11-8 shows the three unique variables that you can use in a message command.
Variable |
Definition |
---|---|
%s |
The name of the file in which the message resides |
%f |
The name of the system that sent the message |
%t |
The name of the system that is the destination of the message |
Many Samba options are available to deal with operating system issues on either Unix or Windows. In particular, some of these options are used for setting limits for clients' use of resources on the Unix server. The options shown in Table 11-9 deal with some of these issues.
Option |
Parameters |
Function |
Default |
Scope |
---|---|---|---|---|
deadtime |
numeric (minutes) |
Number of minutes of inactivity before a connection should be terminated. |
0 |
Global |
dfree command |
string (command) |
Used to specify a command that returns free disk space in a format recognized by Samba. |
None |
Global |
fstype |
NTFS, FAT, or Samba |
Filesystem type reported by the server to the client. |
NTFS |
Global |
keepalive |
numeric (seconds) |
Number of seconds between checks for an inoperative client. |
300 (none) |
Global |
max disk size |
numeric (MB) |
Largest disk size to return to a client, some of which have limits. Does not affect actual operations on the disk. |
0 (infinity) |
Global |
max mux |
numeric |
Maximum number of simultaneous SMB operations that clients can make. |
50 |
Global |
max open files |
numeric |
Limits number of open files to be below Unix limits. |
10000 |
Global |
max xmit |
numeric |
Specifies the maximum packet size that Samba will send. |
65535 or 16644 |
Global |
nt pipe support |
Boolean |
Turns off an NT/2000/XP support feature; for benchmarking or in case of an error. |
yes |
Global |
nt smb support |
Boolean |
Turns off an NT/2000/XP support feature; for benchmarking or in case of an error. |
yes |
Global |
ole locking compatibility |
Boolean |
Remaps out-of-range lock requests used on Windows to fit in allowable range on Unix. Turning it off causes Unix lock errors. |
yes |
Global |
panic action |
string |
Command to run if Samba server fails; for debugging. |
None |
Global |
set directory |
Boolean |
If yes, allows VMS clients to issue set dir commands. |
no |
Global |
status |
Boolean |
If yes, allows Samba to monitor status for smbstatus command. |
yes |
Global |
strict sync |
Boolean |
If no, ignores Windows application requests to perform a sync-to-disk. |
no |
Global |
sync always |
Boolean |
If yes, forces all client writes to be committed to disk before returning from the call. |
no |
Global |
strip dot |
Boolean |
If yes, strips trailing dots from Unix filenames. |
no |
Global |
change notify timeout |
numeric (seconds) |
Interval between checks when a client asks to wait for a change in a specified directory. |
60 |
Global |
stat cache |
Boolean |
If yes, Samba will cache recent name mappings. |
yes |
Global |
stat cache size |
numeric |
Number of entries in the stat cache. |
50 |
Global |
This global option sets the number of minutes that Samba will wait for an inactive client before closing its session with the Samba server. A client is considered inactive when it has no open files and no data is being sent from it. The default value for this option is 0, which means that Samba never closes any connection, regardless of how long they have been inactive. This can lead to unnecessary consumption of the server's resources by inactive clients. We recommend that you override the default as follows:
[global] deadtime = 10
This tells Samba to terminate any inactive client sessions after 10 minutes. For most networks, setting this option as such will not inconvenience users because reconnections from the client are generally performed transparently to the user. See also the keepalive parameter.
This global option is used on systems that incorrectly determine the free space left on the disk. So far, the only confirmed system that needs this option set is Ultrix. There is no default value for this option, which means that Samba already knows how to compute the free disk space on its own and the results are considered reliable. You can override it as follows:
[global] dfree command = /usr/local/bin/dfree
This option should point to a script that returns the total disk space in a block and the number of available blocks. The Samba documentation recommends the following as a usable script:
#!/bin/sh df $1 | tail -1 | awk '{print $2" "$4}'
On System V machines, the following will work:
#!/bin/sh /usr/bin/df $1 | tail -1 | awk '{print $3" "$5}'
This share-level option sets the type of filesystem that Samba reports when queried by the client. Three strings can be used as a value to this configuration option, as listed in Table 11-10.
Value |
Definition |
---|---|
NTFS |
Microsoft Windows NT filesystem |
FAT |
DOS FAT filesystem |
Samba |
Samba filesystem |
The default value for this option is NTFS, which represents a Windows NT filesystem. There probably isn't a need to specify any other type of filesystem. However, if you need to, you can override the default value per share as follows:
[data] fstype = FAT
This global option specifies the number of seconds that Samba waits between sending NetBIOS keepalive packets. These packets are used to ping a client to detect whether it is still alive and on the network. The default value for this option is 300 (5 minutes), which you can override as follows:
[global] keepalive = 600
The value of 600 (10 minutes) is good for networks populated by reliable clients. If your network contains relatively unreliable clients, you might prefer to set keepalive to a lower value, such as 30. If keepalive is set to 0, no NetBIOS keepalive packets will be sent. See also the deadtime parameter.
This global option specifies an illusory limit, in megabytes, for each share that Samba is offering. It only affects how much disk space Samba reports the share as having and does not prevent more disk space from actually being available for use. You would typically set this option to prevent clients with older operating systems—or running buggy applications—from being confused by large disk spaces. For example, some older Windows applications become confused when they encounter a share larger than 1 gigabyte. To work around this problem, max disk size can be set as follows:
[global] max disk size = 1000
The default value for this option is 0, which means there is no upper limit.
This global option specifies the maximum number of concurrent SMB operations Samba allows. The default value for this option is 50. You can override it as follows:
[global] max mux = 100
This global option specifies the maximum number of open files that Samba should allow at any given time for all processes. This value must be equal to or less than the amount allowed by the operating system, which varies from system to system. The default value for this option is 10000. You can override it as follows:
[global] max open files = 8000
This global option sets the maximum size of packets that Samba exchanges with a client. In rare cases, setting a smaller maximum packet size can increase performance, especially with Windows for Workgroups. In Samba versions up to 2.2.5, the default value for this option is 65535. In 2.2.7 and later versions, the default was changed to 16644 to match the behavior of Windows 2000 and improve support for Windows NT 4.0. You can override the default as follows:
[global] max xmit = 4096
This global option is used by developers to allow or disallow Windows NT/2000/XP clients the ability to make connections to NT-specific SMB IPC$ pipes. As a user, you should never need to override the default:
[global] nt pipe support = yes
This global option is used by developers to negotiate NT-specific SMB options with Windows NT/2000/XP clients. The Samba Team has discovered that slightly better performance comes from setting this value to no. However, as a user, you should probably not override the default:
[global] nt smb support = yes
This global option turns off Samba's internal byte-range locking manipulation in files, which gives compatibility with Object Linking and Embedding (OLE) applications that use high byte-range locks as a method of interprocess communication. The default value for this option is yes. If you trust your Unix locking mechanisms, you can override it as follows:
[global] ole locking compatibility = no
This global option specifies a command to execute in the event that Samba encounters a fatal error when loading or running. There is no default value for this option. You can specify an action as follows:
[global] panic action = /bin/csh -c 'xedit <<: "Samba has shutdown unexpectedly";:'
This Boolean share-level option allows Digital Pathworks clients to use the setdir command to change directories on the server. If you are not using the Digital Pathworks client, you should not need to alter this option. The default value for this option is no. You can override it per share as follows:
[data] set directory = yes
This global option indicates whether Samba should log all active connections to a status file. This file is used only by the smbstatus command. If you have no intentions of using this command, you can set this option to no, which can result in a small increase of speed on the server. The default value for this option is yes. You can override it as follows:
[global] status = no
This share-level option determines whether Samba honors all requests to perform a disk sync when requested to do so by a client. Many Windows clients request a disk sync when they are really just trying to flush data to their own open files. In this case, a disk sync is generally unnecessary on Unix due to its high reliability, and it mostly has the effect of substantially reducing the performance of the Samba host system. The default value for this option is no, which allows the superfluous disk sync requests to be ignored. You can override the default as follows:
[data] strict sync = yes
This share-level option decides whether every write to disk should be followed by a disk synchronization before the write call returns control to the client. Even if the value of this option is no, clients can request a disk synchronization; see the earlier strict sync option. The default value for this option is no. You can override it per share as follows:
[data] sync always = yes
This global option determines whether to remove the trailing dot from Unix filenames that are formatted with a dot at the end. The default value for this option is no. You can override it per share as follows:
[global] strip dot = yes
The change notify timeout global option emulates a Windows NT/2000 SMB feature called change notification. This allows a client to request that a Windows NT/2000 server periodically monitor a specific directory on a share for any changes. If changes occur, the server will notify the client.
Samba performs this function for its clients at an interval that defaults to 1 minute (60 seconds). Performing these checks too often can slow down the server considerably; however, you can use this option to specify an alternate time that Samba should wait between performing checks:
[global] change notify timeout = 30