## Using Samba

Robert Eckstein, David Collier-Brown, Peter Kelly
1st Edition November 1999
1-56592-449-5, Order Number: 4495
416 pages, $34.95

Buy the hardcopy

Table of Contents

| Chapter 8 |

> # 8. Additional Samba Information

> Contents:
> Supporting Programmers
> Magic Scripts
> Internationalization
> WinPopup Messages
> Recently Added Options
> Miscellaneous Options
> Backups with smbtar

> This chapter wraps up our coverage of the smb.conf configuration file with some miscellaneous options that can perform a variety of tasks. We will talk briefly about options for supporting programmers, internationalization, messages, and common Windows bugs. For the most part, you will use these options only in isolated circumstances. We also cover performing automated backups with the smbtar command at the end of this chapter. So without further ado, let's jump into our first subject: options to help programmers.

> ## 8.1 Supporting Programmers

> If you have programmers accessing your Samba server, you'll want to be aware of the special options listed in Table 8.1.

> Table 8.1: Programming Configuration Options
> Option | Parameters | Function | Default | Scope
> --- | --- | --- | --- | ---
> `time server` | boolean | If `yes`, nmbd announces itself as a SMB time service to Windows clients. | `no` | Global
> `time offset` | numerical (number of minutes) | 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 a MS nmake bug. | `no` | Share

> ### 8.1.1 Time Synchronization

> Time synchronization can be very important to programmers. Consider the following options:

>     time service = 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 the kind of compatible file times that Visual C++, nmake, and other Microsoft programming tools require. Otherwise, PC make programs will tend to think that all the files in a directory need to be recompiled every time. Obviously, this is not the behavior you want.

> #### 8.1.1.1 time server

> If your Samba server has an accurate clock, or if it's a client of one of the Unix network time servers, you can instruct it to advertise itself as an SMB time server by setting the `time` `server` option as follows:

>     [global]
>     	time service = yes

> The client will still have to request the correct time with the following DOS command, substituting the Samba server name in at the appropriate point:

>     C:\NET TIME \\server /YES /SET

> This command can be placed in a Windows logon script (see Chapter 6, Users, Security, and Domains ).

> By default, the `time` `server` option is normally set to `no`. If you turn this service on, you can use the command above to keep the client clocks from drifting. Time synchronization is important to clients using programs such as make, which compile based on the last time the file was changed. Incorrectly synchronized times can cause such programs to either remake all files in a directory, which wastes time, or not recompile a source file that was just modified because of a slight clock drift.

> #### 8.1.1.2 time offset

> To deal with clients that don't process daylight savings time properly, 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

> #### 8.1.1.3 dos filetimes

> 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/Windows machine: any user can change the last modified date on a file in that share if he or she has write permission to it. In order 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.

> #### 8.1.1.4 dos filetime resolution

> `dos` `filetime` `resolution` is share-level option. If set to `yes`, Samba will arrange to have the file times rounded to the closest two-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.

> #### 8.1.1.5 fake directory create times

> 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 1st, 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.

7.3 Name Resolution with Samba |  | 8.2 Magic Scripts

O'Reilly Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
International | About O'Reilly | Affiliated Companies

© 1999, O'Reilly & Associates, Inc.