By the time you receive this update Samba-3 will be four months old. Amazingly, the first update took three months. Samba-3.0.1 shipped December 19, and Samba-3.0.2 shipped in February.

How many bugs were squashed in 3.0.1? There were approximately 160 CVS updates that fixed a range of nuisance issues. The most serious issues addressed since 3.0.0 in 3.0.1 are:

• Improved interoperability with Microsoft Office applications
• SWAT fixes
• Signing fixes
• Internationalization support fixes
• Fixes for some segfault/crash bugs
• Improvements to Kerberos support
• Winbind maturation changes
• Improvements to Quota support
• MTLMv2 session support added
• Additional built-in SID support

Fixes since 3.0.1:

• General segfault and oops fixes
• Improved compile-time warnings
• Better detection of Windows NT/200x domain types
• Better DNS handling
• Improvements in schannel support
• Improvements in NSS support
• Quota enhancements
• SWAT fixes
• Documentation updates

Note: Samba documentation has now been put into a separate package called samba-docs. Documentation had been significantly updated, and obsolete man pages have been removed. The Samba-HOWTO-Collection has been updated.

Now that documentation has been mentioned, the book version of the Samba-HOWTO-Collection, The Official Samba-3 HOWTO and Reference Guide, has been updated also; as you read this the book will be in its fifth printing. A huge thanks to all who purchased the book.

The original reviewers of the Samba-HOWTO-Collection strongly suggested the addition of detailed example deployments to the original work. A decision was made not to do this as the HOWTO was already becoming large enough without it. Instead, another book, Samba-3 by Example, is scheduled for release in April at the SambaXP Conference. The release to the North American market will take place at the RealWorld Linux Conference in Toronto, Canada, on April 14.

Samba-3 by Example describes a series of real network examples from the perspective of customer needs, technical requirements, and political constraints, and then presents a step-by-step implementation of the designed solution. With the aid of this book, you can take a freshly installed Linux system and, just by following the steps provided, end up with a working network.

Samba-3 users have experienced a few inconveniences, many of which have been addressed in Samba-3.0.1 and Samba-3.0.2. Some who used Samba-3.0.1 found they could join a domain, but then couldn't log onto it using Windows XP Professional or Windows 2000 Professional Service Pack 4. So far as we are aware, this issue is fully resolved in Samba-3.0.2.

The following areas have caused difficulties over the past four months, so I hope that the advice given here will be helpful and may permit you to escape traps that have caught unwary players.

Migration Issues
A surprising number of users reported problems with migration from Samba-2.2.x series to Samba-3. It is exceedingly important to ensure that you make a backup of all Samba-2.x files before attempting to update.

Before commencing an upgrade from one major version to another, it's good practice to read the manual. The authoritative Samba manual is the Samba-HOWTO-Collection, which includes a chapter that describes the parameters that have changed. If your Samba-2.x smb.conf file contains any parameter that has been affected, you should update to use the newer parameters (if required).

Samba-3 has been designed so that for the most part it is possible to operate with the samba smb.conf file as with Samba-2.x. Key parameters that are no longer supported are those that were previously necessary to force a particular behavior in respect of character set handling and group handling.

Samba-3 supports Unicode and therefore can support multiple concurrent locales. Samba-2 required configuration for a specific locale and could not handle concurrent use of Samba from multiple differing wide-character set locales.

Samba-2 did not support NT-style groups; Samba-3 does this through a new group mapping scheme that permits Unix groups to be mapped to NT groups (better called Windows Domain Global groups).

Another area that changed significantly between Samba-2.x and Samba-3 is in the way that Samba-3 supports smarter handling of local, domain, and foreign domain users and groups. All of these are now automatically mapped to UIDs and GIDs by winbind. This involves the specification of the idmap uid and idmap gid ranges from which winbind may allocate local identities.

Unlike Samba-2.x, it is recommended that you run winbind on every system because it is now a primary identity management tool that smbd can depend on.

Roaming Profiles
The handling of roaming profiles continues to present challenges for some network administrators. There are two main problems:

1. They do not work (generally through simple causes).
2. They are not wanted.

Fortunately, both problems are easy to deal with.

Failure to Work
There are two components that must be correctly configured for roaming profiles to function correctly; it's also necessary to join the machine to the Samba Domain. Once a Windows client has been joined to the Samba Domain, the user must log onto the Domain before roaming profile handling can kick into gear.

There are two components that involve Samba configuration:

1.  In your smb.conf file you must specify a valid logon path parameter. If one is not specified, the default is set to use a directory called profile in the users' home directory. Please refer to the notes in the online man page for smb.conf with respect to use of the default setting. You will see the clear warning that this does not work well. The default is the safest setting we can provide in the event that the network administrator fails to provide a specific profiles share (the preferred solution). Where a specific profile share is provided in the smb.conf file, it must also be correctly configured from the file system share point. More on that in a moment. The path provided as the argument to the logon path consists of:
-The name of the profile server – generally specified by %L if it is the local Domain Controller
-The name of the profiles share itself
-A directory that may be particular to the user, or that may be a common directory in which you can provide a group profile. Group profiles may be shared by many users. Where the profiles share is specified as follows:

[profiles]
path = /var/lib/samba/profile
comment = Profiles Share
read only = No
profile acls = Yes

And where the logon path = \\%L\profiles\%U, this means that:

• The profile server will be any server that processes the users' logon session.
• It will use the profiles share on that server (as long as it exists).
• It will expect to find an already prepared directory that has the exact same name as the login ID of the user. That directory must be set to permissions so that the user has full read, write, and execute control, and so that the users' group and others have read and execute control.

If you want profiles to be stored on a specific server, just replace the %L with the name of that server. For example

logon path = \\BIGSERVER\profiles\%U

In this case the top level for storage in the file system of the pro file server for a user called fred will be /var/lib/samba/profiles/ fred on the server called BIGSERVER.

2.  In those situations where you do not want a default profile, or wish to disable roaming profile use from within Samba, simply set the logon path = with no argument given. This tells Samba to supply the empty profile path. This is interpreted by Windows clients as use a local default profile.

It should be noted (as mentioned in the Samba-HOWTO-Collection – see 21.2.1.4) that roaming profiles can be disabled on a particular Windows client through a simple registry setting.

In the next issue I will deal with CUPS printing support – a powerful facility that has caused untold grief for some administrators. So stay tuned for the next exciting edition of Samba Update.