VMS Software / Documentation / Samba V4.15-13A for VSI OpenVMS

Samba V4.15-13A for VSI OpenVMS

Release Notes

Publication Date: January 2026

Operating Systems:: VSI OpenVMS x86-64 Version 9.2-2 or higher
VSI OpenVMS IA-64 Version 8.4-2L1 or higher

Kit Names:: VSI-I64VMS-SAMBA-V0415-13A-1.PCSI$COMPRESSED
VSI-X86VMS-SAMBA-V0415-13A-1.PCSI$COMPRESSED

1. Introduction

VMS Software Inc. (VSI) is pleased to announce a new version of Samba V4.15-13A for VSI OpenVMS IA-64 and x86-64. This release of Samba for VSI OpenVMS is based on Samba V4.15-13 and includes significant improvements over the previous release (V4.10-16). Primarily a bug-fix release, it addresses various issues identified in the earlier 4.10-16D kit.

For a more detailed description of new features, enhancements, and known issues, refer to the release notes at https://www.samba.org/samba/history/samba-4.15.13.html. Be aware that some product features may be platform-specific.

2. What's New in This Release

2.1. New and Changed Features

Since the first release of Samba for VSI OpenVMS, a number of changes in operation and configuration of Samba for OpenVMS needed to be made according to the changes that were introduced in Samba 4.15.13. See the list of changes below:

The RMS protection mask of the SAMBA$SETTINGS.COM file now includes W:E by default.
The value of the client ldap sasl wrapping parameter was changed from plain to sign in SAMBA$CONFIG.COM.
The SAMBA$CONFIG Server Comment option now supports the percent sign (%).
The SMBSHOW symbol definition has been modified to include the headers from the SHOW SYSTEM display.
The SAMBA$DEFINE_COMMANDS.COM no longer sets the process parse style to EXTENDED.
Multichannel support is disabled by default.
Offline domain join is disabled by default.
An option for enabling SMB1 from SMBCONF has been added and is disabled by default. The user can enable it from SMBCONF → 2. Generic Options → 6. Enable SMB V1.

A list of significant issues from the previous release of Samba for VSI OpenVMS that were fixed in this release, is provided in Section 2.2, ''Fixed Issues and Improvements''.

2.2. Fixed Issues and Improvements

For earlier fixes, refer to: Samba V4.10-16D for VSI OpenVMS Release Notes.

Samba installation and upgrade procedures now reliably create all required OpenVMS accounts, with no password issues.
Samba now retains a limited number of old log and core files to avoid filling up storage space.
Previously, when the smbclient utility was used to list the contents of a directory only containing files copied from a Windows system using the net use, smbclient would hang or fail the operation. This issue has been fixed in the current release.
Samba now correctly handles the OpenVMS identifiers granted to users, ensuring that the access permissions for domain users are set as expected.
The Samba logical name that conflicted with GNV has been removed, eliminating the related compatibility issues.
Providing an invalid value in the "SMB ports" setting now produces a clear error message instead of causing a crash or rendering the configuration unusable.
Samba now displays a warning message when a NetBIOS alias name is too long.
Samba now rejects configurations where the NetBIOS computer name and cluster alias are the same.
Samba now checks for the missing required settings (such as an empty NetBIOS name) and reports an error instead of crashing or rendering the configuration unusable.
Fixed an issue related to Samba connections.
Resolved an IA-64 architecture-specific issue with opening or downloading files larger than 60KB.
Fixed a crash in the SMBD process when listing shares containing more than 500 files.
Fixed an issue with the samba$root and samba$log logicals.
Resolved a conflict between Samba-defined logicals and other OpenVMS applications.
Fixed a timeout issue when one or more KDCs are listed in KRB5.CONF_<domain>.
Fixed a crash in the SMBD process caused by the UNIX charset.
Resolved an issue where filenames without extensions caused the SMBD process to crash.
Addressed issues with log file parameters (%v, %m, %l) not functioning correctly.
Fixed an issue with Samba copy and paste functionality.
CVE-2020-25717 was fixed, which allows a user on the domain to become root on domain members.
CVE-2016-2124 was fixed, which allows SMB1 client connections to be downgraded to plaintext authentication.

2.3. Known Issues and Limitations

The list below identifies the currently known problems and limitations in this release.

On Windows clients, the initial listing of very large directories (approximately 1000+ entries) on Samba shares may omit certain subdirectories. A subsequent refresh or re-listing displays all entries. Other clients (for example, smbclient with a timeout) are not affected.
On OpenVMS IA-64 systems that run Multinet (including Multinet V5.6) with Samba V4.10-16D or V4.15-13A, using the smbcontrol utility against nmbd, winbindd, or certain Samba PIDs may cause the targeted process to crash with the ACCVIO/“Signal 10” internal error.
An attempt to list a large number of files (3000+) in the Standalone mode or the Member mode causes the NT_STATUS_INVALID_NETWORK_RESPONSE error.
On OpenVMS IA-64 Multinet 5.6 systems, copying large files from Samba share is currently unstable.
On OpenVMS IA-64 systems, connecting to Samba share for the first time causes the following error message:
```
protocol negotiation failed: NT_STATUS_IO_TIMEOUT
```
The modified date on some files may change unexpectedly after the file has been opened but its contents have not been changed. This issue is most commonly observed with Microsoft Office files. In order to avoid this problem, it is necessary to ensure that the logical name DECC$EFS_FILE_TIMESTAMPS is defined (with a value of “TRUE”) such that the logical name is visible to Samba processes, and to ensure that any file systems serving the files in question has file access times set on (per the SET VOLUME/VOLUME_CHARACTERISTICS=ACCESS_DATES command).
To use Kerberos authentication (via the -k option) with the SMBCLIENT utility, perform the following steps:
1. If necessary, disable elevated process privileges (NOIMPERSONATE, NOSYSPRV, NOREADALL, and NOBYPASS):
```
$ SET PROCESS/PRIVILEGE=(NOALL,TMPMBX,NETMBX)
```
2. Obtain a Kerberos ticket using your domain username:
```
$ net ads kerberos kinit --user domain-username
```
3. Optionally (and if possible) elevate process privileges (to avoid potential non-fatal errors); for example:
```
$ SET PROCESS/PRIVILEGE=ALL
```
4. Run SMBCLIENT, specifying values for server and share names as appropriate:
```
$ SMBCLIENT -k \\server\share
```
The OpenVMS owner of new objects created by users with a local Samba account that is included in the admin users list is incorrectly set to SAMBA$SMBD instead of the owner of the parent directory. In many environments, this issue can be avoided by adding the following line to the applicable share section in SAMBA$ROOT:[LIB]SMB.CONF:
```
inherit owner = yes
```
The net rpc user rename command is not supported by Samba for OpenVMS. This is consistent with previous CIFS for OpenVMS behavior.
If the Samba share parameter inherit owner equals no and a parent directory is owned by a resource identifier, when a user creates a new file or folder, Samba sets the file owner to the UIC of the user creating the file rather than the resource identifier. To retain the usual OpenVMS behavior (that is, to set the resource identifier as the file owner), add inherit owner = yes to the applicable [share] sections in SMB.CONF.
For systems running the TCPware TCP/IP stack, Samba is not able to auto-detect the active TCPware IP interface addresses. Therefore, the list of interfaces available for use by Samba must be configured manually (see Section 10, ''Systems Running TCPware TCP/IP'' for additional information).
Excessive CPU usage can be detected when SMBCLIENT starts a session. Several NET ADS commands that use Kerberos also induce 5 seconds of 100% CPU usage. To resolve, change the option in SMBCLIENT to --use-kerberos=off.
The SMBCLIENT more command, which displays the contents of a file, requires the GNV for OpenVMS to be installed. The GNV kit and the associated documentation are available at https://sourceforge.net/projects/gnv/.
After installing GNV, perform the following tasks to allow the SMBCLIENT more command to function correctly:
1. Define the GNU logical name by running the command below (you may wish to add this command to the system start up procedure):
```
$ @SYS$STARTUP:GNV$STARTUP.COM
```
2. Make the GNV utilities available by running the following command, which ensures that the logical name DCL$PATH is correctly defined in order for users to access more and other GNV commands. You may wish to add this command to your LOGIN.COM file or to SYS$MANAGER:SYLOGIN.COM.
```
$ @GNU:[LIB]GNV_SETUP.COM
```
3. If the process has a MORE symbol defined, it must be deleted:
```
$ SHOW SYMBOL MORE
$ DELETE/SYMBOL[/GLOBAL] MORE
```

In a cluster, if one of the nodes becomes unavailable, the user may have problems with connecting to the shared resource by using Samba Cluster Alias Name from the other nodes. In this situation, it is better to restart Samba on the available node.

The user can restart Samba by running the following:

> smbstop
Shutting down SAMBA processes and SMBD services...
Disabling TCPIP SMBD services...
  SMBD services disabled
Shutting down SMBD processes...
  SMBD process not found
Shutting down WINBIND process...
  WINBIND process was terminated, pid 29047D79
Shutting down NMBD process...
  NMBD process was terminated, pid 29049178
  Successfully shutdown SAMBA processes and SMBD services

> smbstart
Creating NMBD Process...
%RUN-S-PROC_ID, identification of created process is 2904818C
Creating WINBIND Process...
%RUN-S-PROC_ID, identification of created process is 2904918D
Enabling SMBD services...
  Successfully enabled TCPIP SMBD services

2.4. What’s Missing?

This release of Samba for OpenVMS does not include the following functionality:

The classic Primary Domain Controller (PDC) and Backup Domain Controller (BDC) roles are not supported.
The Active Directory Domain Controller role is not supported in this release. Support for this functionality is being considered and may be added later.
A copy of the source code for Samba for OpenVMS is not included with the installation kit. However, we will provide a copy of the code on request, contact <support@vmssoftware.com>.
The samba-tool tool is not available. Instead, use smbconf.

3. Requirements

3.1. System Requirements

Operating system and layered product software versions requirements for Samba V4.15-13A for VSI OpenVMS servers are listed below.

VSI OpenVMS x86-64 Version 9.2-2 or higher, VSI OpenVMS IA-64 Version 8.4-2L1 or higher.
VSI TCP/IP Services for OpenVMS, HPE TCP/IP Services for VSI OpenVMS, or MultiNet TCP/IP.
Samba for VSI OpenVMS must be installed and run on an ODS-5 file system volume. The software cannot be installed on an ODS-2 file system volume and ODS-2 file systems cannot be used for file shares.
The VSI OpenVMS internationalization data kit (VMSI18N) must be installed for Samba to be able to correctly display international characters in file names.
On VSI OpenVMS IA-64 V8.4-2L3, it is recommended that use RTL no lower than V6.0 (the VMS842L3I_RTL-V0600 kit).
VSI SSL3 V3.0.16 or higher.
VSI LDAP V2.6-6 or higher.

The user should be familiar with the installation, configuration, and use of open-source products such as Samba in the VSI OpenVMS environment.

3.2. DNS Requirements for Samba Member Servers

A Samba member server requires a proper DNS configuration to avoid long delays or timeouts when attempting to locate domain controllers.

If an OpenVMS host is configured to use the same DNS domain as the domain Samba will join, no changes are required.

However, if Samba is connected to a domain which is not the same DNS domain configured on the OpenVMS host, the OpenVMS host should be configured as a cache-only BIND server and use a stub zone or conditional forwarding for the domain that Samba will connect to. Additionally, the DNS name resolver on the OpenVMS host should be configured to use localhost as its DNS server.

Prior to connecting the Samba server to a domain, customers should verify the OpenVMS host is capable of resolving DNS SRV record types for the domain. For example, use the following command to verify that Samba will connect to a domain named example.com:

$ dig SRV _kerberos._tcp.example.com +noall +answer +additional

The response should be a list of domain controllers.

3.3. Memory Requirements

Since Samba defines many OpenVMS process logical names and dynamically activates image libraries, systems running Samba may require increased amounts of process dynamic memory space. The process dynamic memory size is controlled by the SYSGEN CTLPAGES parameter. Samba may consume the following amount of process dynamic memory:

Architecture	Memory Consumed
IA-64	220KB
x86-64	250KB

On IA-64 and x86-64 hosts, the default value of CTLPAGES is 1056 pagelets (528KB), which is typically sufficient to support Samba requirements.

When the process dynamic memory space is insufficient, Samba administrators may encounter errors similar to the following:

When executing SAMBA$ROOT:[BIN]SAMBA$DEFINE_COMMANDS.COM:
```
%SYSTEM-F-INSFMEM, insufficient dynamic memory
```

When executing Samba utilities, such as SMBSTATUS, SMBCLIENT, and NET (the displayed image name may be different):

%DCL-W-ACTIMAGE, error activating image LIBAUTHKRB5-SAMBA4-CLI-EIMGNAME, image file
SYS$SYSDEVICE:[VMS$COMMON.SAMBA.][LIB.ALPHA.PRIVATE]SAMBA$LIBAUTHKRB5-SAMBA4.EXE;1
-SYSTEM-F-INSFP1POOL, insufficient process dynamic memory

When starting Samba (the displayed image names may be different):

Creating NMBD Process...
%RUN-S-PROC_ID, identification of created process is 20E00456
Creating WINBIND Process...
%RUN-S-PROC_ID, identification of created process is 20E00457
Enabling SMBD services...
%DCL-W-ACTIMAGE, error activating image LIBGSSAPI-SAMBA4-CLI-EIMGNAME, image file
SYS$SYSDEVICE:[VMS$COMMON.SAMBA.][LIB.ALPHA.PRIVATE]SAMBA$LIBGSSAPISAMBA4.EXE;1
-SYSTEM-F-INSFP1POOL, insufficient process dynamic memory
%DCL-W-ACTIMAGE, error activating image DPML$SHR-CLI-E-IMGNAME,
image file SYS$SYSDEVICE:[VMS$COMMON.SAMBA.][SYSLIB]DPML$SHR.EXE
-SYSTEM-F-INSFP1POOL, insufficient process dynamic memory
%DCL-W-ACTIMAGE, error activating image DPML$SHR-CLI-E-IMGNAME,
image file SYS$SYSDEVICE:[VMS$COMMON.SAMBA.][SYSLIB]DPML$SHR.EXE
-SYSTEM-F-INSFP1POOL, insufficient process dynamic memory

To determine the amount of process dynamic memory in use, execute the SHOW PROCESS/MEMORY command. If "Free Space" is depleted, increase the value of the CTLPAGES SYSGEN parameter by the following minimum amounts (pagelets):

Architecture	Pagelets
IA-64	440
x86-64	500

The value of CTLPAGES is used in AUTOGEN calculations, so to change the value, VSI recommends adding the appropriate line to SYS$SYSTEM:MODPARAMS.DAT (for example, ADD_CTLPAGES=230), running AUTOGEN, and rebooting the system.

4. Recommended Reading

Before using Samba V4.15-13A for OpenVMS, VSI recommends that users read the documentation available at https://www.samba.org/samba/docs/ in order to understand how to configure and manage the software.

Warning

Certain features of Samba for OpenVMS may not be part of the open source version of Samba, and therefore are described only in this document.

5. Before Installing the Kit

Make sure your system meets the following requirements before you install Samba for VSI OpenVMS.

Samba requires the SYSGEN parameters listed in the table below to be set at least to the specified minimum value, otherwise the installation will fail. Note that each time you change the values of these SYSGEN parameters, you must run AUTOGEN for the changes to take effect and then reboot your system.

Parameter	Minimum Value	Add to MODPARAMS.DAT
PROCSECTCNT	512	MIN_PROCSECTCNT = 512
CHANNELCNT	2560	MIN_CHANNELCNT = 2560
PQL_DPGFLQUOTA	256000	MIN_PQL_DPGFLQUOTA = 256000

If you are upgrading or migrating from the old CIFS for OpenVMS to Samba for VSI OpenVMS, VSI strongly recommends that you backup the existing CIFS SAMBA$ROOT directory tree prior to installing Samba.

Make sure enough space is allocated to process dynamic memory. For details, see Section 3.3, ''Memory Requirements''.

5.1. Important Cluster Considerations

Running the old CIFS for OpenVMS and Samba for VSI OpenVMS in the same cluster is not supported. Existing CIFS for OpenVMS configurations will be migrated to Samba for VSI OpenVMS equivalents when SAMBA$CONFIG.COM is executed.

Multiple instances of Samba can be run in a cluster. An instance is defined by the SAMBA$ROOT: directory tree. If there are two separate SAMBA$ROOT: directory trees, the cluster will contain two instances of Samba. Cluster members that share the same SAMBA$ROOT: directory tree form a Samba cluster.

Each Samba instance requires a unique Samba cluster alias name. For example, in a cluster with three nodes, the following configurations are possible:

All nodes can be members of a single Samba cluster instance.
Two nodes can be members of a Samba cluster instance while the third node runs a separate, standalone instance of Samba.
All three nodes can run separate standalone instances of Samba.

Warning

No two instances of Samba should allow access to the same share directories and files in a cluster as this can lead to data corruption. Separate instances of Samba do not share file locking details with other instances.

6. Installing the Kit

The Samba kit is provided as a compressed VSI OpenVMS PCSI kit that can be installed by a suitably privileged user via the following command:

$ PRODUCT INSTALL SAMBA

By default, Samba will be installed to SYS$SYSDEVICE:[VMS$COMMON.SAMBA].

If multiple cluster members will share the same SAMBA$ROOT: directory tree, Samba must be installed onto a device that is mounted by all cluster members.

If you plan to run Samba on multiple cluster members of the same architecture which do not have a common system disk, install Samba on one cluster member only. Then, follow the post-installation instructions described in Section 7, ''Post-Installation Steps'' to complete the installation on other cluster members.

The installation directory of Samba for VSI OpenVMS is associated with the SAMBA$ROOT logical name. SAMBA$ROOT is a rooted logical name that defines the root location for the Samba configuration files, logs, and other product files. Samba configuration files are stored in SAMBA$ROOT:[LIB] and, by default, logs are stored in SAMBA$ROOT:[VAR]. The SAMBA$ROOT logical name is defined in SYS$STARTUP:SAMBA$DEFINE_ROOT.COM (which is executed from the Samba start up procedure, SYS$STARTUP:SAMBA$STARTUP.COM).

Below you can see a sample installation log on a system disk. Note that your output may differ slightly from that shown below, depending on the platform and other factors.

The following product has been selected:
VSI X86VMS SAMBA V4.15-13A Layered Product

Do you want to continue? [YES]

Configuration phase starting ...

You will be asked to choose options, if any, for each selected product and for
any products that may be installed to satisfy software dependency requirements.

Configuring VSI X86VMS SAMBA V4.15-13A: VSI OpenVMS SAMBA

OpenVMS SAMBA is released under the terms of GNU Public License.

This installation procedure requires that all the following
conditions are satisfied:

1. This procedure is running on a x86_64 processor.
2. The x86_64 operating system is running OpenVMS V9.2-2 or later.
3. SSL3 x86_64 installed V3.0-16 or later.
4. LDAP/OPENLDAP x86_64 installed V2.6-6 or later.
5. All required privileges are currently enabled.
6. No CIFS or SAMBA images are running on this node or anywhere in
the cluster that make use of common samba$root installation
directory.
7. ODS5 filesystem only.
8. SYSGEN Parameter values:

Parameter Minimum Required
------------ ----------------
CHANNELCNT 2560
PROCSECTCNT 512
PQL_DPGFLQUOTA 256000

Do you want to continue? [Please, type N or NO if you don't want to continue, any other answer means YES]

* This product does not have any configuration options.

Execution phase starting ...

The following product will be installed to destination:
VSI X86VMS SAMBA V4.15-13A DISK$THORIN_SYS:[VMS$COMMON.]

Portion done: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%

Creating OpenVMS accounts required by Samba

SAMBA$SMBD account already exists.
SAMBA$SMBD account updated...
SAMBA$NMBD account already exists.
SAMBA$NMBD account updated...
SAMBA$GUEST account already exists.
SAMBA$GUEST account updated...
SAMBA$TMPLT account already exists.
SAMBA$TMPLT account updated...
SMBADMIN account already exists.
SMBADMIN account updated...
Try to deassign SAMBA$ROOT in system table exec
SAMBA$ROOT is defined as "SYS$SYSDEVICE:[VMS$COMMON.SAMBA.]"
Setting file protections...
File protections are set
Creating Samba for OpenVMS root definition file SYS$COMMON:[SYS$STARTUP]SAMBA$DEFINE_ROOT.COM...
File created
Save startup files
Setup SAMBA logical environment
%DCL-I-SUPERSEDE, previous value of SAMBA$EXE has been superseded
Restoring configuration files...
Successfully finished

In a cluster, on all the nodes that are going to use common
samba$root installation directory as the current node, copy
the following files to SYS$STARTUP directory of each node:

SYS$STARTUP:SAMBA$STARTUP.COM
SYS$STARTUP:SAMBA$SHUTDOWN.COM
SYS$STARTUP:SAMBA$DEFINE_ROOT.COM

To automatically start OpenVMS SAMBA during system startup
add the following line to the file SYS$MANAGER:SYSTARTUP_VMS.COM
after the TCPIP startup command procedure:

$ @SYS$STARTUP:SAMBA$STARTUP.COM

To shut down OpenVMS SAMBA during system shutdown
add the following line to the file SYS$MANAGER:SYSHUTDWN.COM:

$ @SYS$STARTUP:SAMBA$SHUTDOWN.COM

Press Enter to continue:

To configure OpenVMS SAMBA on any of the nodes in OpenVMS
cluster that will share the common samba$root installation
directory as the current node, execute:

$ @SYS$STARTUP:SAMBA$DEFINE_ROOT.COM
$ @SAMBA$ROOT:[BIN]SAMBA$CONFIG.COM

Define symbols for all Samba utilities:

...100% $ @SAMBA$ROOT:[BIN]SAMBA$DEFINE_COMMANDS.COM

The following product has been installed:
VSI X86VMS SAMBA V4.15-13A Layered Product

7. Post-Installation Steps

After you have successfully installed Samba for VSI OpenVMS, follow these steps to configure it:

Verify that the SAMBA$ROOT logical name is set:
```
$ SHOW LOGICAL SAMBA$ROOT
"SAMBA$ROOT" = "SYS$SYSDEVICE:[VMS$COMMON.SAMBA.]"
```
If the logical name is not defined, execute the following command:
```
$ @SYS$STARTUP:SAMBA$DEFINE_ROOT
```

Define symbols for all Samba utilities:

$ @SAMBA$ROOT:[BIN]SAMBA$DEFINE_COMMANDS.COM

In a cluster, copy the files from SAMBA$ROOT:[CLUSTER] to the SYS$COMMON:[SYS$STARTUP] directory on the nodes in the cluster that meet both of the following requirements:
- Use the same SAMBA$ROOT directory tree as the installation node.
- Do not boot from the same system disk as the installation node.
Configure the Samba server:
Note
For this release of Samba for VSI OpenVMS, the server must be configured as a standalone server or a domain member server.
Run the Samba configuration utility to generate the Samba configuration files. These files are not created during installation and must be generated as described below. Note that the Samba configuration utility also migrates existing CIFS for OpenVMS configurations to Samba (see Section 8, ''Migrating CIFS for VSI OpenVMS'').
When configuring multiple cluster members that share the same SAMBA$ROOT: directory tree, be aware of the following:
- The Core and Generic menu options are shared by all members of the same Samba cluster instance; changes to these options affect all cluster members. The System Specific menu options are unique to the cluster member on which they are set.
- On the first cluster member, at the main menu, select option A to configure all options.
- On subsequent cluster members, at the main menu, select only option 1 – System Specific options.
```
$ SMBCONF

                SAMBA Configuration Utility

Use this utility to configure the server role, create TCP/IP
services, and configure other options.

The following conditions must be met prior to configuring Samba:

    1. Log into OpenVMS using a privileged system account.
    2. Shutdown Samba. If Samba is running on multiple cluster
       members, shutdown Samba on all cluster members which
       share the same SAMBA$ROOT: directory tree as the node
       being configured.

For more information about Samba Server configuration,
please refer to the Samba for OpenVMS release notes.

Press Enter to continue:

NOTE: The Option "1 - System Specific setup" should be executed
      on each of the nodes sharing common samba$root installation
      directory.

      On an OpenVMS cluster, please execute the following options
      from the OpenVMS Samba Main Configuration Options Menu on
      only one of the cluster nodes that share the common samba$root
      installation directory:
          2 - Generic options
          3 - Core environment

      If Samba Server is being configured afresh on this node, choose
      option:
      A - Configure options 1 – 3

Press Enter to continue:

Checking for existing Samba Server configuration...

            OpenVMS Samba Main Configuration Options Menu

Configuration options:

    1 - System specific setup
    2 - Generic options
    3 - Core environment
    A - Configure options 1 - 3
    [E] - Exit Menu

Enter configuration option:
```
Configure Samba as appropriate using the menu options provided. To generate a minimal basic configuration, select the A option and accept the defaults as you step through each submenu.
The TESTPARM utility should be used to review the final configuration.
For additional information about configuring Samba, refer to the documentation available at https://www.samba.org/samba/.
Supported Character Sets
Samba supports all character sets supported by the VSI OpenVMS internationalization data kit (VMSI18N), including ISO8859: ISO8859-1, ISO8859-2, ISO8859-5, ISO8859-7, ISO8859-8, ISO8859-9, ISO8859-15. The default character set is UTF-8. For example, to configure Samba to use the ISO8859-1 character set, perform the following steps:
1. Add the following line to the [global] section of SAMBA$ROOT:[LIB]SMB.CONF:
```
unix charset = iso8859-1
```
2. Add the following line to SAMBA$ROOT:[BIN]SAMBA$SETTINGS.COM:
```
$ DEASSIGN/NOLOG DECC$FILENAME_ENCODING_UTF8
```

Start the Samba server:

$ SMBSTART

Creating NMBD Process...
%RUN-S-PROC_ID, identification of created process is 000143A2

Enabling SMBD services...

    Successfully enabled TCPIP SMBD services

Add the following command to the system startup procedure to start Samba when the system is booted. Note that this command must be added after the command that starts TCP/IP.
```
$ @SYS$STARTUP:SAMBA$STARTUP.COM
```
Add the following command to the system shutdown procedure to stop Samba during system shutdown:
```
$ @SYS$STARTUP:SAMBA$SHUTDOWN.COM
```
Use the SMBMANAGE utility to manage Samba shares, users, groups, and account policies as necessary.
You may wish to run the following command to add a version limit on the subdirectories in SAMBA$ROOT:[VAR.CORES] to prevent unnoticed process dump files from consuming huge amounts of disk space. You may use an alternative value for the version limit as appropriate to your environment.
```
 $ set directory/version_limit=10 samba$root:[var.cores...]
```
By default, when the SMBCLIENT utility is connected to a share on a Samba for VSI OpenVMS host, it does not support paths using the VSI OpenVMS directory syntax. To enable the support of the VSI OpenVMS directory syntax for SMBCLIENT, add the following entry to the [global] section of SAMBA$ROOT:[LIB]SMB.CONF:
```
vms path allow = yes
```

8. Migrating CIFS for VSI OpenVMS

Run SAMBA$CONFIG.COM after installation to migrate an existing CIFS for OpenVMS configuration to Samba for OpenVMS. SAMBA$CONFIG.COM runs SAMBA$MIGRATION.COM, which renames the appropriate CIFS users/groups and their associated OpenVMS account and identifier names (changing CIFS to SAMBA) and updates references in .CONF and USERNAME.MAP files. SAMBA$CONFIG.COM also has routines to migrate obsolete, deprecated, and modified parameters from CIFS for OpenVMS to their equivalents in Samba for OpenVMS.

The Samba migration process saves the old CIFS for OpenVMS configuration files to a subdirectory in SAMBA$ROOT:[BACKUP_MIGRATION] and produces a log file named according to the following format: SAMBA$ROOT:[VAR]SAMBA$MIGRATION_date_time.LOG.

To undo or roll back the migration if problems occur, proceed as follows:

Run the migration procedure (SAMBA$MIGRATION.COM) and specify the path where the backup migration files are stored. In the following example, the backed up CIFS configuration files are stored in the SAMBA$ROOT:[BACKUP_MIGRATION.30APR2019_103511] directory:
```
$ @SAMBA$ROOT:[BIN]SAMBA$MIGRATION -
_$ SAMBA$ROOT:[BACKUP_MIGRATION.30APR2019_103511]
```
Reinstall CIFS for OpenVMS.

9. WINBIND Support

WINBIND is a component of Samba that provides user and group identity mapping. In Samba for OpenVMS, WINBIND is a separate daemon process with one to four subprocesses.

Note

In CIFS for OpenVMS, there is no separate WINBIND process. Instead, the WINBIND functionality is included in each SMBD process.

When deciding whether to enable or disable WINBIND, consider the following:

If Samba is configured in a standalone server role, WINBIND provides no useful purpose and would typically be disabled.
If Samba is configured as a member server, WINBIND is required and provides three main functions:
- WINBIND is used when authenticating domain users (including trusted domain users). If WINBIND is not running, domain users cannot be authenticated and will fail to connect.
- WINBIND allows for referencing domain user and group accounts when managing Samba. For example, to add or remove domain user and group accounts as members of local Samba groups.
- WINBIND allows system administrators to create OpenVMS user accounts dynamically. Each Samba user requires an OpenVMS account with a unique UIC in order to be distinguished from other users for security purposes. Administrators may create the necessary OpenVMS accounts manually or allow WINBIND to create OpenVMS accounts for Samba users dynamically, as they are needed. When properly configured, WINBIND creates a new OpenVMS account with a unique UIC for any domain user who successfully authenticates but does not already have an OpenVMS account mapped to their Windows account.

9.1. Configuring WINBIND

Before configuring WINBIND on a member server, determine what functionality is desired. If configured to dynamically create VSI OpenVMS user accounts, WINBIND requires a range of values (specified in decimal) to allocate as user identifiers and from which a unique VSI OpenVMS username and UIC are derived.

The range is specified in decimal using the format “low-value - high-value”, where the low-value must be less than high-value. Due to the OpenVMS UIC number restrictions, the low-value should not be less than 256 and the high-value cannot exceed 16382.

If WINBIND is configured to prevent dynamic creation of OpenVMS accounts for Samba users, the range can be a minimum of 1; for example, 10000 - 10001.

If WINBIND is configured to allow dynamic creation of OpenVMS accounts for Samba users, the range specified should be large enough to accommodate the expected number of user accounts that could possibly be created. However, the high value of the range can be increased at any time to provide additional user identifiers if necessary.

For example, a UIC number range of 5000 - 6000 allows WINBIND to create a total of 1001 OpenVMS user accounts.

When creating an OpenVMS user account, the ID number allocated by WINBIND is converted to hexadecimal and appended to the string SAMBA$ to produce an OpenVMS username. The allocated WINBIND ID number is also converted to octal and used as the UIC group and member number assigned to the OpenVMS account. For example, if WINBIND allocates ID 5200 to a new user, the OpenVMS account name will be SAMBA$1450 and its UIC will be [12120,12120].

To configure WINBIND, use the SAMBA$CONFIG utility. From the Main Configuration Options menu, option

3 - Core
                    environment

includes the following WINBIND configuration option:

4. Enable WINBIND:

To disable all WINBIND functionality, set option 4 to no. This will prevent the WINBIND process from starting.

To enable WINBIND, set option 4 to yes. Note that WINBIND is required on domain member servers. When WINBIND is initially enabled, SAMBA$CONFIG will prompt the user for the UIC number range. After specifying the range, SAMBA$CONFIG returns to the core configuration menu and displays the following WINBIND options:

4. Enable WINBIND: yes
    4A. UIC number range: 10000-10001
    4B. Allow Samba to create OpenVMS accounts on-the-fly: yes

To prevent WINBIND from dynamically creating OpenVMS user accounts, specify no for the 4B option.

9.2. Samba WINBIND Configuration Parameters

The Samba configuration parameter idmap config * : range = specifies the UIC number range that WINBIND uses when allocating user identifiers.

Note that the TESTPARM utility will display the following messages when no range is specified. These messages may be ignored:

idmap range not specified for domain '*'
ERROR: Invalid idmap range for domain *!

The Samba configuration parameter idmap config * : read only controls WINBIND ID allocation. If set to yes, WINBIND is prevented from allocating user IDs. If set to no (the default), WINBIND may allocate user IDs.

10. Systems Running TCPware TCP/IP

For systems running the TCPware TCP/IP stack, Samba is not able to auto-detect the active TCPware IP interface addresses. Therefore, the list of interfaces available for use by Samba must be manually configured. To do so, use SMB$CONFIG to configure Samba as a standalone server first, then edit SAMBA$ROOT:[LIB]SMB.CONF and add the appropriate parameters (explained below) to the [global] section. If desired, run SAMBA$CONFIG to reconfigure Samba as a member server.

To make all active interface addresses available to Samba, list those addresses and their subnet masks separating them with a comma or a space as values for the interfaces global parameter. Be sure to always include the localhost address (127.0.0.1) in the list of allowed interfaces.

For example, you may add an entry similar to the following to SMB.CONF (setting address details as appropriate to your environment and making sure to include localhost):

interfaces = 10.100.10.1/24, 127.0.0.1

To make only a subset of active interface addresses available to Samba, include just the addresses and the subnet masks of the allowed interfaces in the interfaces list and also specify bind interfaces only = yes.

For example, if the host has three interfaces: 10.10.1.1/24, 192.168.0.10/16, and 44.4.1.1/10 and Samba is to use only the 10.10.1.1/24 and 192.168.0.10/16 interfaces, then you would specify the following in SMB.CONF:

interfaces = 10.10.1.1/24, 192.168.0.10, 127.0.0.1
bind interfaces only = yes