Running multiple instances of Samba in a LifeKeeper cluster introduces additional configuration requirements and restrictions. The following Samba configuration scenarios may involve multiple instances of Samba:

  • Active/Standby configuration with multiple LifeKeeper Samba instances on one server
  • Active/Active configuration with multiple LifeKeeper Samba instances on more than one server

Either of these configurations could include a non-LifeKeeper protected version of Samba.

As previously noted in Configuring the LifeKeeper for Linux Samba Recovery Kit, when running multiple instances of Samba each version must have a uniquely named configuration file, or the files must reside in different directories. Within each configuration file a number of directives are required and must be unique – in particular, netbios name, lock directory, pid directory, interfaces and log file. If these directives are not unique, Samba may not startup and therefore will not be available for client connections. Additionally, the lock, log file, and pid directories specified for each instance must exist on all servers in the cluster.

smbpasswd Utility and Multiple Instances of Samba

Although not required by LifeKeeper, some Samba utilities used by the Samba Recovery Kit expect to be able to open smb.conf in its default location. The Recovery Kit uses the smbclient and nmblookup utilities to connect to smbd and nmbd (respectively) in order to determine the health of the daemon processes while under LifeKeeper protection. These two utilities will not error out if they do not find smb.conf in its default location. However, smb.conf is required by the smbpasswd utility to be in its default location.

smbpasswd is used to maintain the smbpasswd file for authentication of users on client connection requests when the security level is set to share or user. If the default configuration file is missing, any attempt to change Samba passwords will fail. To avoid this problem, one of the instances of Samba must use the default configuration file if the security level is set to share or user, or if the server is acting as the smbpasswd server for those systems with Samba security level set to server. The reason for this is that smbpasswd uses the default configuration file to obtain the location of the smbpasswd file. Because of this requirement only one location for the smbpasswd file can exist within the LifeKeeper cluster. The configuration files for all instances of Samba in the cluster must have the directive smb passwd file set to the same value. Additionally, the smbpasswd file must be kept in sync on all servers in the cluster.

The smbpasswd utility is also affected by the use of the bind interfaces only directive, which is required by the LifeKeeper Samba Recovery Kit. With the bind interfaces only directive set to Yes, a regular user changing his Samba password will attempt to connect to a smbd daemon process using the localhost address of If that address has been added to the interfaces directive in the configuration file used by the smbd daemon, and if smbd has connected to and is listening on that address, then the password change will be successful. If the daemon does not have that address in its configuration file interfaces directive, then the password change will fail. In a multiple instance environment, if the localhost is specified in more than one configuration file, only one instance will be able to start up and run. Using the –r netbios_name option to smbpasswd will work in place of adding the localhost address to the interfaces list (for example: smbpasswd -r server1 print1…).

Samba and User Authentication Considerations

Samba supports several methods for user authentication via the security parameter (e.g. share, user, domain, …) which must be considered when protecting Samba via LifeKeeper to ensure data files such as /etc/samba/smbpasswd or /etc/samba/secrets.tdb are kept in sync on all servers in the cluster. So when using security methods such as user, you must ensure that the smbpasswd file is kept in sync on all servers in the cluster. Additionally, security methods such as domain require synchronization of the secrets.tdb file. A LifeKeeper active/active configuration with the secrets.tdb file requires the use of the private dir parameter to specify the location of the file. The value for this parameter must be unique for each LifeKeeper Samba instance.


Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment