There are three basic current problem areas: bad hostnames, routed networks, and network collisions. These are covered in the discussion below.

As a general rule, the contents of the smb.conf file should be kept as simple as possible. No parameter should be specified unless you know it is essential to operation.

Many UNIX administrators like to fully document the settings in the smb.conf file. This is a bad idea because it adds content to the file. The smb.conf file is re-read by every smbd process every time the file time stamp changes (or, on systems where this does not work, every 20 seconds or so).

As the size of the smb.conf file grows the risk of introduction of parsing errors increases also. It is recommended to keep a fully documented smb.conf file on hand, and then to operate Samba only with an optimized file.

The preferred way to maintain a documented file is to call it something like smb.conf.master. You can generate the optimized file by executing:

root#  testparm -s smb.conf.master > smb.conf

You should carefully observe all warnings issued. It is also a good practice to execute the following command to confirm correct interpretation of the smb.conf file contents:

root#  testparm
Load smb config files from /etc/samba/smb.conf
Can't find include file /etc/samba/machine.
Processing section "[homes]"
Processing section "[print$]"
Processing section "[netlogon]"
Processing section "[Profiles]"
Processing section "[printers]"
Processing section "[media]"
Processing section "[data]"
Processing section "[cdr]"
Processing section "[apps]"
Loaded services file OK.
'winbind separator = +' might cause problems with group membership.
Server role: ROLE_DOMAIN_PDC
Press enter to see a dump of your service definitions

You now, of course, press the enter key to complete the command, or else abort it by pressing Ctrl-C. The important thing to note is the noted Server role, as well as warning messages. Noted configuration conflicts must be remedied before proceeding. For example, the following error message represents a common fatal problem:

ERROR: both 'wins support = true' and 'wins server = <server list>' 
cannot be set in the smb.conf file. nmbd will abort with this setting.

There are two parameters that can cause severe network performance degradation, socket options and socket address. The socket options parameter was often necessary when Samba was used with the Linux 2.2.x kernels. Later kernels are largely self-tuning and seldom benefit from this parameter being set. Do not use either parameter unless it has been proven necessary to use them.

Another smb.conf parameter that may cause severe network performance degradation is the strict sync parameter. Do not use this at all. There is no good reason to use this with any modern Windows client. The strict sync is often used together with the sync always parameter. This, too, can severely degrade network performance, so do not set it or if you must, do so with caution.

Finally, many network administrators deliberately disable opportunistic locking support. While this does not degrade Samba performance, it significantly degrades Windows client performance because this disables local file caching on Windows clients and forces every file read and written to invoke a network read or write call. If for any reason you must disable oplocks (opportunistic locking) support, do so on the share on which it is required only. That way, all other shares can provide oplock support for operations that are tolerant of it. See ??? for more information.

On a network segment where there is a PDC and a BDC, the BDC carries the bulk of the network logon processing. If the BDC is a heavily loaded server, the PDC carries a greater proportion of authentication and logon processing. When a sole BDC on a routed network segment gets heavily loaded, it is possible that network logon requests and authentication requests may be directed to a BDC on a distant network segment. This significantly hinders wide-area network operations and is undesirable.

As a general guide, instead of adding Domain Member servers to a network, you would be better advised to add BDCs until there are fewer than 30 Windows clients per BDC. Beyond that ratio, you should add Domain Member servers. This practice ensures that there is always sufficient Domain Controllers to handle logon requests and authentication traffic.

Every network client has its own peculiarities. From a management perspective, it is easier to deal with one version of MS Windows that is maintained to a consistent update level, than it is to deal with a mixture of clients.

On a number of occasions, particular Microsoft service pack updates of a Windows server or client have necessitated special handling from the Samba server end. If you want to remain sane, keep you client workstation configurations consistent.

Many SAN-based storage systems permit more than one server to share a common data store. Use of a shared SAN data store means that you do not need to use time- and resource-hungry data synchronization techniques.

The use of a collection of relatively low-cost front-end Samba servers that are coupled to a shared backend SAN data store permits load distribution while containing costs below that of installing and managing a complex clustering facility.

Microsoft DFS (distributed file system) technology has been implemented in Samba. MSDFS permits data to be accessed from a single share and yet to actually be distributed across multiple actual servers. Refer to TOSHARG, Chapter 16, for information regarding implementation of an MSDFS installation.

The combination of multiple back end servers together with a front-end server and use of MSDFS can achieve almost the same as you would obtain with a clustered Samba server.

Consider using rsync to replicate data across the wide-area network during times of low utilization. Users can then access the replicated data store rather than needing to do so across the wide-area network. This works best for read-only data, but with careful planning can be implemented so that modified files get replicated back to the point of origin. Be careful with your implementation if you choose to permit modification and return replication of the modified file; otherwise, you may inadvertently overwrite important data.

Networking hardware prices have fallen sharply over the past five years. A surprising number of Samba networking problems over this time have been traced to defective network interface cards (NICs) or defective hubs, switches, and cables.

Not surprising is the fact that network administrators do not like to be shown to have made a bad decision. Money saved in buying low-cost hardware may result in high costs incurred in corrective action.

Defective NICs, hubs, and switches may appear as intermittent network access problems, intermittent or persistent data corruption, slow network throughput, low performance, or even as blue-screen-of-death (BSOD) problems with MS Windows clients. In one case, a company updated several workstations with newer, faster Windows client machines that triggered problems during logon as well as data integrity problems on an older PC that was unaffected so long as the new machines were kept shut down.

Defective hardware problems may take patience and persistence before the real cause can be discovered.

Networking hardware defects can significantly impact perceived Samba performance, but defective RAID controllers as well as SCSI and IDE hard disk controllers have also been known to impair Samba server operations. One business came to this realization only after replacing a Samba installation with MS Windows Server 2000 running on the same hardware. The root of the problem completely eluded the network administrator until the entire server was replaced. While you may well think that this would never happen to you, experience shows that given the right (unfortunate) circumstances, this can happen to anyone.

This chapter has touched in broad sweeps on a number of simple steps that can be taken to ensure that your Samba network is resilient, scalable, and reliable, and that it performs well.

Always keep in mind that someone is responsible to maintain and manage your design. In the long term, that may not be you. Spare a thought for your successor and give him or her an even break.

Last, but not least, you should not only keep the network design simple, but it should be well documented. This book may serve as your pattern for documenting every aspect of your design, its implementation, and particularly the objects and assumptions that underlie it.