Samba Server and Client FAQ

This page is a collection of tips and tricks around the setup and operation of the Samba Server and Client for eComStation and OS/2.

---

Installation and configuration

---

Connecting to Samba 3.3.x using IBM-LAN-Requester

Between Samba 3.0.x and Samba 3.2.x/3.3.x several default values were changed that affect LAN-Requester compatibility. Add the following options to smb.conf in order to restore compatibility:

lanman auth = true
client lanman auth = true
client plaintext auth = true

Note: Look at last Q for IBMLAN.INI modifications to resolve speed issues with Samba 3.2 or better and IBM-LAN-Requester.

---

Samba 3.3.x considerations

Samba 3.3.x builds currently come as drop-in replacements for a previous installation of any recent 3.0.x build.

You cannot go back from 3.3.x to 3.0.x easily, as the internal format of the tdb files has been changed between 3.0.x and 3.3.x. If you intend to go back, please backup all tdb files in \lock and \private directories before updating and restore from backup before going back.

While 3.3.x binaries have been tested for several weeks now and seem to work well in general, bear in mind that 3.3.x is still beta software and work in progress and therefore not ready for production use.

Currently 3.3.x offers exactly one benefit over 3.0.x: Ticket 59 is gone. GUI-Tools and scripts work with 3.3.x, but only make little use of new features found in Samba 3.3.x.

---

Samba 3.3.10 and 3.3.11 seem to be unworkable

A change of the default value in the wide links setting in smb.conf triggered a bug in our Samba that was not discovered before. In order to get 3.3.10 and 3.3.11 to work normally put the following into your smb.conf

wide links = Yes

Note: The default value for this was changed from Yes to No with 3.3.10. 3.3.10 and 11 only work normally on eCS if wide links is set to Yes (as it was with builds 3.3.9 and earlier). This issue has been resolved in 3.3.12 or better.

---

Samba Codepage support seems to be broken from 3.0.35 onward - why does this not work anymore?

Older Samba Server releases had the codepage settings hardwired to SYSTEM and later releases to IBM-850. This turned out to be the culprit for various problems regarding codepages with the Client. Therefore this was changed to a dynamic code page detection with changeset 307 for 3.0.x and 308 for 3.3.x.

However, while this solved the problems with the client, it turned out to be problematic on the server.

So the advice is to set the following settings manually in smb.conf:

[global]
   ...
   dos charset = ASCII
   unix charset = UTF-8
   display charset = UTF-8
   ...

The following codepage values have been tested with the following results:

UTF-8	works completely
IBM-850	works completely
IBM-437	works partly, 82 out of 128 characters work, 44 mismatches, 2 cannot be written
UTF-16	crashes Samba, do not try that
IBM-863	not tested, but we'd like to get results
IBM-866	not tested, but we'd like to get results

General advice: Enter IBM-850, even if your system is running on other codepages, this will most likely give you the best results. On systems running on IBM-850 no change is required).

Note: Characters below 128 work on any codepage. Issues are only seen when using characters between 128 and 255 in file and directory names.
Note: Recent sscc.exe knows about these issues and provides appropriate additions to smb.conf.

---

The Samba Client is really a mess, there is ndpsmb.dll, Netdrive, EVFS, EVFSGUI, the Samba client utilities - what is all this about and how do these go together?

The Samba Client has a layered approach:

Top layer (GUI and CLI)	EVFSGUI or Netdrive GUI and Samba Client Utilities
Middle layer (CIFS/SMB-Plugin)	ndpsmb.dll
Base layer (File System)	EVFS or Netdrive (both are equally suitable)

---

When I try to run Samba, nmbd.exe runs, but smbd.exe stops immediately. What's wrong here?

That usually means that the guest account has not been setup properly. Go to the command line and run usermod.cmd without any parameter. This will tell you what's wrong.

Note: The warning about the unknown root shell can safely be ignored.

---

The installer asks me for a password of the "root" account. I don't want a "root" account. Can I safely ignore that?

No. Samba is a ported Unix software. It absolutely requires a "root" account. You ultimatively must create this account with an appropriate password. The same applies to the "guest" account. Without these 2 accounts Samba will not work properly.

---

My guest account should not be named "guest" but "nobody". Is this possible?

Because of Ticket #59, this is not possible at the moment (there is workaround code in several tools and scripts, that fails if the guest account is not named "guest"). A partly solution for this is in the works, however this limitation will only be completely removed if Ticket #59 is resolved.

---

I see a completely erratic behaviour, when I try to add users to groups - I always get NT_ACCESS_DENIED errors, although credentials should be sufficient. Sometimes the user appears magically after the next operation. What is wrong here?

The problem is located in the group file and in the (now deprecated) addusertogroup.cmd and deluserfromgroup.cmd scripts. The userlist MUST be terminated by a comma. Examples of the group file syntax floating around neglect this issue, and the scripts mentioned above do not provide the comma either (use the smbusers package published ​here to deal with users and groups ).

Each line of your group file should look like this:

ntadmin:*:3019:root,paul,herwig,master,administrator,

Note: For real Unix it seems that it does not matter whether the trailing comma is added or not. The OS/2 implementation in klibc however depends upon this trailing comma in order to work properly.

---

Does Samba really need this libc063x.dll, I have libc063.dll anyway? I want to get rid of one of these two files! This is the DLL hell!

Samba comes with an enhanced version of ​libc063.dll named libc063x.dll. In order to run Samba successfully you must have this file, the standard ​libc063.dll does not work for Samba. The two DLLs are not interchangeable and you cannot just rename one or the other. Please note that you also must not rename libc063x.dll to ​libc063.dll in order to use the enhanced DLL with other applications. This will not work either.

Note: Samba version 3.0.30 and later come with libc064x.dll. So libc063x.dll is obsolete and can safely be removed from your system. You must NOT delete ​libc063.dll however!

---

Prerequisites

---

I want to try Samba Server for eCS(OS/2), but I have installed NetBIOS over TCP/IP and I do not want to screw this machine. Anything I can do for a quick and painless test?

As also noted otherwise you MUST remove NetBIOS over TCP/IP before trying the Samba Server. Nevertheless you just have to backup 3 files in order to get back to you previous status.
So, for a quick try of the Samba Server, do the following:

1. Create backups of \ibmcom\protocol.ini, \ibmlan\ibmlan.ini and config.sys.
2. Run MPTS to remove NetBIOS over TCP/IP protocol. Note: Setting UNIXROOT now is a good idea!
3. Reboot.
4. Try Samba Server for eCS(OS/2)

In case you want to go back:

1. Uninstall Samba Server for eCS(OS/2)
2. Copy the backups of \ibmcom\protocol.ini, \ibmlan\ibmlan.ini and config.sys over the current versions.
3. Reboot. You are back where you were before trying Samba.

---

Will Samba Server for eCS also run on Warp 4?

Yes. There is nothing eCS specific in it. Make sure the prerequisites mentioned here are met. Warp 4 FP16 and OS/2 MCP2 have been tested to work. Pre-FP12 levels are unknown, but should work. Samba Server does NOT work with 16-bit-TCP/IP (Version 4.0x).

Note: baselayout.zip is not required anymore in case you install the WPI archive.

---

How should my protocol bindings look like in MPTS?

You must not have installed NetBIOS over TCP/IP. Samba server uses the same ports and thus cannot run at the same time as NetBIOS over TCP/IP. This is no bug and no limitation of the OS/2 version, this just the way Samba works.

The most simple protocol binding in MPTS would look like the following (in case no Virtual Machine solution such as VirtualPC, SVISTA or VirtualBox is installed):

Intel(R) Pro 1000 network connection....... (for example)
   0 - IBM TCP/IP

---

Feature set

---

The current utilities packaged with Samba server for eCS (OS/2) only have a limited feature set. How can I configure all the other features without messing with commandline utilities?

While the feature set of the utilities will grow over time, you can use the ​Microsoft Windows Server 2003 Resource Kit Tools in order to configure options presently not found in the OS/2 utilities. Both SRVMGR.EXE and USRMGR.EXE work very well with the Samba Server for eCS (OS/2) when run from a Windows NT/2000/XP workstation.

Another possibility is the ​Microsoft Nexus package. This package comes with functionally equivalent versions of SRVMGR.EXE and USRMGR.EXE, but designed to run on Windows 95/98/ME machines.

Note: Unfortunately none of utilities cannot be run using Odin/InnoWin.

---

Can Samba Server for eCS (OS/2) operate as a Primary Domain Controller?

Yes, that is possible. The sscc.exe installer utility version 0.5.7 or better that comes with the 3.0.31 WPI package is able to create a smb.conf suitable for a Primary Domain Controller, however it cannot migrate an existing smb.conf.

Note: It is strongly recommended to use tdbsam backend instead of standard smbpasswd backend if you intend to run a Primary Domain Controller. Use pdbedit in order to migrate users and groups from smbpasswd backend to tdbsam backend.

Commandline to migrate backend from smbpasswd to tdbsam:

 pdbedit -i smbpasswd -e tdbsam

Afterwards edit smb.conf and add the following line to the [global] section and restart Samba:

[global]
   ...
   passdb backend = tdbsam
   ...

---

Which OS/2 components are replaced by Samba?

The following table provides an overview:

Samba component	Original eCS (OS/2) component	Remarks
Samba Server	IBM Peer/LAN Server/WSeB	Samba cannot share serial devices, but is much faster on the same hardware
Netdrive + Samba client plugin	IBM LAN Requester	Used to access files/directories on a Samba server from an eCS (OS/2) client
eVFS + Samba client plugin	IBM LAN Requester	Used to access files/directories on a Samba server from an (OS/2) client
Samba smbspool.exe + smb.pdr	IBM LAN Requester	Used to print from OS/2 on a printer shared by a Samba server

Note: EVFS comes with eComStation 2.x
Note: smb.pdr can be found ​here.
Note: The Samba Client is only a client, it cannot (unlike IBM Peer) share files and directories, you need the Samba server in order to do this.

---

Is the Samba Server for eCS (OS/2) able to store OS/2 extended attributes properly?

Yes, extended attributes work nicely. You have to add the following statement to your smb.conf in order to enable extended attributes:

[global]
   ...
   ea support = Yes
   ...

During history of our Samba port, there were several issues with extended attributes, but all of these have been resolved successfully over time.

Currently (13.10.2009) there are no confirmed issues with extended attributes.

Please note, that Samba (or better: The kLIBC runtime library creates several extended attributes of its own (most notably UID, GID, MODE and several others) for every file and directory it accesses. These are used to store several specific information (normally not found on eCS (OS/2)) required by Samba to manage privilegues.

---

Miscellaneous

---

What is faster, Samba Server for eCS (OS/2), IBM Peer, LAN Server or WarpServer for eBusiness?

The Samba Server provides a much better performance than all the older IBM products on a given hardware. The Samba Client is slower than the IBM LAN Requester. Speedwise the order of possible combination is the following:

1. Samba Server plus IBM LAN Requester (fastest)
2. Samba Server plus Samba Client
3. IBM Peer/LAN Server/WSeB plus IBM LAN Requester (slowest)

Note: The combination IBM Peer/LAN Server/WSeB plus Samba Client is untested. It is probably the slowest and least stable combination anyway.

Note: Recent experiments showed that Samba Server for eCS(OS/2) behaves extremely asymmetric when it comes to compare read and write speeds. While read speed is very fast (typically 16.000 to 26.000 KB/sec.), write speed is very slow (typically 150 KB/sec.). The problem is the very same that directly leads to Ticket #69 and Ticket #71. This problem has existed for every Samba build (tested back to version 3.0.25pre1). With Revision 170 Samba now writes with speeds of around 11.000 Kb/sec.

---

What about stability? Is Samba for eCS (OS/2) stable enough to run my company's network?

There are several case studies where Samba Server for eCS (OS/2) is already used in a real life office environment successfully for approximately a year, without real problems. Nevertheless Samba still has quirks and in its current status is more difficult to handle than the older IBM products (which definitely also have quirks and limitations, especially when it comes to newer Windows clients).

---

Bad performance using IBM Peer/LAN-Requester as client for a Samba 3.2 server (or better)

Marcel Müller wrote:

since I switched my Linux server with a 3.0.2x build of Samba to Debian Lenny with Samba 3.2.5, the throughput from OS/2 clients using IBM peer dramatically degraded. I get at most 2.5 MB/s when writing from the OS/2 client to the samba server. The CPU load is low on both systems.

Further analysis showed that the OS/2 chooses sometimes Read/Write RAW and sometimes Read/Write MPX at the connection setup. The MPX modes were normally intended to use simultaneous parallel connections over connectionless transports which does not apply to TCPBEUI.
The issue might be quite old without much noticeable effect, since Samba 3.0.x supported at least Write MPX by default and no windows server will ever accept the MPX modes over TCPBEUI. Samba 3.2 only made the problem to show up.

Most likely there is some kind of issue during the negotiation. Maybe samba returns some wrong error code that made the client to choose the MPX modes, maybe something else. However, there seems to be a much easier solution. Since I disabled the MPX modes in the requester configuration, I was no longer able to reproduce the problem. OS/2 now always uses the Read/Write RAW modes, that provide similar performance that the multiplexed mode. There should be no really drawback unless you use IPX transport.

Solution:
=======

Disable the MPX modes in the IBM peer requester configuration:

• Edit bootdrive:\IBMLAN\IBMLAN.INI

• Reset bit 14/15 in the wrkheuristics setting:

  ;                           1         2         3         4
  ;                 012345678901234567890123456789012345678901
  ; wrkheuristics = 1111111121311111110001011120111221001111100
  ;                               ^^  (old)
    wrkheuristics = 1111111121311100110001011120111221001111100
  ;                               ^^  (new)
  

• Restart the requester.

Now the client does no longer try to use the multiplexed modes (without success). The RAW mode is used instead.

Marcel

Connecting an eCS Client to Windows 7 Professional

Gene Alexander from ERACC Computing provided an article on that topic. It can be found ​here

bww bitwise works did some tests on this an can confirm, that is is workable with a plugin version 2.2 or better.

Which environment variables does Samba for eCS use?

The following list of environment variables is used/evaluated by various Samba components and purposes, they should therefore be set wisely and with consideration:

AUTH_PASSWORD
AUTH_USERNAME
CLASS
CLI_FORCE_ASCII
CLI_FORCE_DOSERR
CLI_FORCE_INTERACTIVE
CLI_NO_READLINE
COLUMNS
CONTENT_LENGTH
DEBUG
DEVICE_URI
EDITOR
ETC
HOME
HTTP_ACCEPT_LANGUAGE
KRB5CCNAME
KRB5_CONFIG
LDB_SPECIALS
LDB_URL
LD_LDB_MODULE_PATH
LIBSMB_PROG
LOGNAME
NSS_WRAPPER_GROUP
NSS_WRAPPER_PASSWD
PAGER
PASSWD
PASSWD_FD
PASSWD_FILE
PASSWORD
PATH
PATH_INFO
POSIXLY_CORRECT
QUERY_STRING
REMOTE_ADDR
REMOTE_HOST
REMOTE_USER
REQUEST_METHOD
SCRIPT_NAME
SHELL
SMBW_DIR
SMB_CONF_PATH
SMB_EXE
SOCKET_WRAPPER_DEFAULT_IFACE
SOCKET_WRAPPER_DIR
SOCKET_WRAPPER_PCAP_FILE
TEMP
TESTDIR
TEST_WORKGROUP
TMPDIR
UNIXROOT
USER
VISUAL
WORKGROUP