Samba Server and Client FAQ

This page is a 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

---

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 UTF-8, 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 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)	EVFSGUI (or Netdrive GUI) and Samba Client Utilities
Middle layer (CIFS/SMB-Plugin)	ndpsmb.dll
Base layer (File System)	EVFS (or Netdrive)

---

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.

---

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.

---

Miscanellous

---

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).

---

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 CPU at 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