Welcome to the webpage dedicated to Samba/2, the OS/2 port of Samba.
Please note: in the following I use the notation Samba/2
wherever I specifically mean the OS/2 version of Samba. Where I just
write Samba, I mean any port of Samba, including the OS/2
version. Also, please note that the Samba/2 specific information below
overrides the documentation for Samba in general (except where I'm
patch for the v1.9.18 series still needs some more work, especially on
cleaning up lock files and timestamps.
18-aug-1997: OS/2 patch to get Samba
1.9.17alpha5 compiled under OS/2 (no binaries yet),
20-jul-1997: OS/2 patch to get Samba 1.9.16p11
compiled under OS/2.
This port is largely based on Jason
Rumney's work. Since he's now doing other things, I've started
working on some issues which were still open. Samba/2 could not have
been possible without the work of Eberhard Mattes,
the author of EMX. EMX allows you to port Unix applications to OS/2
with relatively little effort. Which is quite a feat, IMHO... Many GNU
programs have been ported with EMX. EMX itself uses GNU software
extensively: GCC, GAS, GDB, etc. etc.
Back to the "Using Samba with DOS or OS/2"
Back to Jacco's homepage
- What is Samba?
- Using Samba/2
- Hints and tips on using Samba/2
- Known bugs/limitations
- Compiling Samba/2
- Hint and tips on compiling Samba/2
- Using Warp 4 and Warp Connect together with
- Porting issues
This is version 1.9 of Samba, the free SMB client and server for
Unix and other operating systems, including now also OS/2. Samba is
maintained by the Samba Team, who support the original author and
principal maintainer, Andrew Tridgell. See also the Samba homepage, http://www.samba.org
What is Samba?
SMB is the protocol by which a lot of PC-related machines
share files and printers and other informatiuon such as lists of
available files and printers. Operating systems that support this
natively include Windows NT, Warp 4, Warp Connect, Linux and add on
packages that achieve the same thing are available for DOS, Windows,
OS/2 (Microsoft LAN Manager Client), VMS, Unix of all kinds, MVS, and
more. There is no reason why Apple Macs and indeed any Web browser
should not be able to speak this protocol, and current development (in
which the Samba team is heavily involved) is aimed at exactly that.
Alternatives to SMB include Netware, NFS, Appletalk, Banyan Vines,
Decnet etc; many of these have advantages but none are both public
specifications and widely implemented in desktop machines by default.
The Common Internet Filesystem is what the new SMB initiative is
called. For details watch http://www.samba.org/cifs/.
Microsoft has submitted CIFS to the Internet Task Force. It could well
be that Samba/2 is the first OS/2 network software conforming to this
Back to top
Here is a very short list of what Samba includes, and what it does.
And all this is free and comes with full source code. But here's what
it doesn't do:
- an SMB server, to provide Windows NT and LAN Manager-style file
and print services to SMB clients such as Windows 95, Warp 4, Warp
Connect, smbfs and others.
- a Netbios (rfc1001/1002) nameserver, which among other things
gives browsing support. Samba can be the master browser on your LAN if
- an ftp-like SMB client (smbclient/SMBCLNT.EXE) so you can access
PC resources (disks and printers) from unix, Netware and other
So, compared with Warp 4 and Connect, Samba/2 isn't as user friendly.
But what are its main advantages?
- The OS/2 port of Samba is perhaps a bit of a toy, since serious
users will probably buy proven and tested software such as Warp 4 or
Connect. It's still great fun if you're interested in networking or you
really need a specific feature.
- It doesn't have a nice point-and-click user interface such as
Windows95 and Warp 4. Instead, you configure it using an ASCII textfile.
- The Samba client is very basic. It isn't integrated with the OS/2
system as Warp 4 is or even the LAN Manager Client.
- Samba only supports SMB running over the TCP/IP protocol, not
over the NetBEUI protocol. Most systems such as Windows95 and Warp 4
support both so this should not be a real limitation.
- Extended Attributes (EAs) are not supported.
I have already had reports about unsuspected uses of Samba/2. For
instance, someone is using it as a WINS server and someone else is
using it as a server for a CD-"carrousel" because other networking
software seems to change the CD when it is not needed. Another
application would be using SMBCLNT.EXE for retrieving a whole
bunch of files without losing their long file names.
- A DOS or Windows 3.x network client can connect to your OS/2
machine and access files on a partition which supports long filenames.
However, when you do a DIR (for example) on that machine, it
will only show the filenames conforming to the 8.3 limitation. Samba
has a feature called 'name mangling' (Windows 95 and NT support it as
well). The server will scramble long filenames into a similar looking
8.3 filename. The file still has its long filename but now also the
DOS/Windows 3.x client will be able to access it. Example: "My
Graduation Thesis.DOC" is turned into "MY_GR~01.DOC".
Other clients who do support long filenames can still access the file
by its full name.
- It has a smaller memory footprint than Warp 4 and Connect's File
and Print Client. So it should work with smaller machines, such as OS/2
2.x box with only IBM TCP/IP 2.0 and 8 MB RAM. Samba/2 has also been
tested on Warp non-Connect with FreeTCP running the WPS or alternative
shells such as PC/2 and Tshell (runs in 4 Mb?).
- When two machines want to communicate with each other, they both
have to speak a common SMB protocol, or 'dialect'. Windows 95 and NT
both come with a new dialect (yet another one..) which Warp 4 and
Connect don't speak. That should not be a problem because they have
older dialects in common with Windows 95 and NT. The most advanced of
those older dialects that Windows 95/NT and Warp support is called
LANMAN2. However, Microsoft in its infinite wisdom decided to cripple
that LANMAN2 implementation in one direction. This means that Windows 95
can see the long filenames on a Warp 4 or Connect machine, but the
other way around is not true. Warp 4 and Connect cannot see the long
filenames on a Windows 95 machine. The result? Warp looks bad and gets
blamed, while in reality Windows 95 is to be blamed! Samba does
support Microsoft's latest SMB dialect, so you will be able to see
Windows 95's long filenames from SMBCLNT.EXE.
For a much better overview of Samba have a look at the Samba website. By the way, did you
know that Microsoft even mentions Samba/2 on their website?
Back to top
If you are only interested in using Samba/2, and not
(re)compiling, adding new features, etc. then read on. If you do
have too much time on your hands :-), read the section "Compiling Samba/2" instead.
Shopping list for using Samba/2:
This new version of Samba/2 should work fine from a FAT partition. I
haven't tested all options though, so if you encounter a problem with
long filenames (see log.smb and log.nmd for error messages, among
others) please mail me.
- The Samba/2 binaries.
- The Samba/2 support files.
- EMX 0.9c runtime software. Available as EMXRT.ZIP
Europeans might prefer to download it closer to home, such as ftp.leo.org
- OS/2 version 2.x or greater (but I haven't actually tested it
with anything less than Warp 3)
- One of the following TCP/IP packages for OS/2.
- IBM TCP/IP 4.0 included with OS/2 Warp 4 ('Merlin')
- IBM TCP/IP 3.0 included with OS/2 Warp Connect
- IBM TCP/IP 2.0 Base Kit with CSD64092
or greater applied
- The Internet Access Kit (IAK) from the BonusPak (OS/2 Warp 3
- The IAK with FreeTCP (allows you
to use a network card with Warp 3.0 Red or Blue spine)
- Any OS/2 accessible partition for Samba/2 to install in and run
from. The files should take about 4 MB.
As you can see in the list above, you need some TCP/IP networking
software since Samba uses it to run the SMB protocol over it. TCP/IP is
built-in in Warp 4 and Connect. If you want to run Samba over a modem
(not very likely since there aren't many Internet servers which support
SMB yet; CIFS may change that), you can do with the older Warp
versions. If you have an older version of OS/2 before Warp Connect, you
have to use IBM TCP/IP 2.0 if you want to use Samba with a network
card. An alternative to IBM TCP/IP 2.0 is FreeTCP,
which costs nothing but has some other disadvantages.
How to install Samba/2:
- Unzip the Samba/2 binaries archive file to a directory, say C:\SAMBA.
- Unzip the Samba/2 support files to the same directory.
- Next, unzip EMXRT.ZIP. It creates the EMX tree itself, so if you
want install all EMX stuff in, say, C:\EMX, goto the root of
C: and do a UNZIP EMXRT.ZIP.
- Install the EMX runtime files per the included instructions in
I also added the following lines to my CONFIG.SYS:
- Edit your CONFIG.SYS and add C:\EMX\DLL to your LIBPATH
- Add C:\EMX\BIN to your PATH.
- It is highly likely that you need to add SET
EMXSHELL=C:\OS2\CMD.EXE so that when one of the Samba/2 binaries
shells out to OS/2 (e.g. SMBCLNT.EXE with an mput) a shell is started
which is known to work. There might be problems if you use 4OS/2 or
other shells. By default, EMX uses the shell from COMSPEC when
it shells out, unless you override that with EMXSHELL.
The first line says to use the local HOSTS file first to look
up the IP address of a host before consulting a Domain Name Server. In
most cases this is useful if the DNS has no knowledge of a host, for
instance if it isn't an official host or there is no DNS present on the
network (just your own little LAN). See below for
more information on working with timezones. The other lines set the
default user for SMBCLNT.EXE, the user's home directory, etc. (although
OS/2 is of course not a multi-user operating system).
Add a line SET HOSTNAME=myPCname to your CONFIG.SYS if
there isn't already one. myPCname is whatever hostname you
like for your own machine.
Configure a "localhost" for your machine, so you will be able to
test the Samba server with the Samba client on the same machine, i.e.
without a real network. Under Warp 4 and Connect (and probably TCP/IP
v2.0 too), you do this by starting the "TCP/IP Configuration Notebook",
clicking on the "Hostnames" tab, and checking the entry "Localhost".
Under FreeTCP, you just add an IFCONFIG LO 127.0.0.1 to your LANSTART.CMD.
(These two ways are actually equivalent...)
Execute the following command: ECHO %ETC%
This will show you to which directory the environment variable ETC
has been set. In most cases this will be \TCPIP\ETC or \MPTN\ETC.
Now edit the file HOSTS in that directory. You need to add an
entry for your own PC to the HOSTS file if you want to run or
test Samba/2 and you want to access the server from that PC itself
through the loopback device. Let's assume in the following that your
OS/2 PC has the following IP address: 192.168.0.2. With the HOSTS
...you can use the name localhost instead of the loopback IP
address 127.0.0.1. The next line contains the IP address of
your PC, plus the symbolic name you made up for it. With Warp 4 and
Connect it should already be there in the file. Please note: the last
line of the HOSTS and RESOLV files need to end with a
Carriage Return/Line Feed, otherwise that line will not be recognized!
Samba/2 needs a directory to store some temporary files, e.g. for
"lock files". I mostly use the temp directory pointed to by the
environment variable TMP. Check in your CONFIG.SYS that it is
set to a directory. Normally, it points to a directory C:\TCPIP\TMP
or so. Preferably use a directory on a filesystem that supports long
filenames, such as HPFS.
Finally, edit the file SMB.CFG. This is the one file
that Samba is all about. You may want to postpone editting it to a
later time (see "Using Samba/2"). Anyway, SMB.CFG
works the same as the Unix versions of Samba, although it is called smb.conf
there. I included an example in the Samba/2 support files. I won't
explain all the settings there, that has been done already in the general Samba documentation.
Please use full paths as much as possible in that SMB.CFG (i.e. specify
the paths with drive letter and subdirectories). That's because the
current dir could change to another drive during the execution of the
Samba/2 server. Also, use the Unix notation with forward slashes as
much as possible. So use f:/tmp/samba instead of f:\tmp\samba.
With one exception: use the normal OS/2 notation with backward slashes
when the path is to be used by an external (OS/2) program. For instance:
the configuration options message command, preexec, postexec
etc. See the Samba configuration manual for these commands that shell
out to the OS/2 command line interpreter.
Back to top
If all these tests worked: congratulations, you seem to have installed
- It's always a good idea to test the stuff without a real network
first. You do this by using the loopback device. Issue the command:
This should result in something like:
If you don't get a similar output, recheck your loopback device. Also
try pinging your real IP address (in the example above I assumed 192.168.0.2):
PING 127.0.0.1: 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0. time=0. ms
64 bytes from 127.0.0.1: icmp_seq=1. time=0. ms
64 bytes from 127.0.0.1: icmp_seq=2. time=0. ms
External process cancelled by a Ctrl+Break or another process
Now to the last check: try pinging the hostname you gave to your
machine. In the example above I used myPCname. That name,
which you specified in both the HOSTS file and on the SET
HOSTNAME= line in your CONFIG.SYS, is a local name for your PC.
That means that only TCP/IP applications running on your own PC will be
able to use it. If you want other people across the network to be able
to use the same name to reach your PC, ask them to add this name plus
your IP address to their HOSTS file. Or ask your network administrator
to include this name on the Domain Name Server. Now to the final check,
at this moment:
If that also works, great.
SMB.CFG should be in the directory SMBD.EXE is
started from. The path to SMB.CFG is a compile time option, so
if you are compiling from source code you can set this to an absolute
path to remove this restriction.
I'll give a couple of hints on how to edit SMB.CFG in
the next couple of points in the list. Definitely check the path for
the "lock dir". It contains information on locked files. If
you don't specify a path, the standard path is used: the directory "locks"
in the current directory from which you run the Samba/2 executables.
Samba/2 won't work without a valid lock directory. I myself prefer a
special "SAMBA" directory in the directory pointed to by the
environment variable TMP (see my example SMB.CFG in SMB2_SUP.ZIP).
- Set the "debug level". Level 1 gives almost no (error)
messages. You might want to set it to 5 or so for the first try.
- In the line "server string" you specify the text that
Windows and OS/2 get to see when they "browse" (scan the network) your
machine. Put something cool there :-)
- The default value for the workgroup parameter in SMB.CFG
is WORKGROUP. This is also what the English versions of
Windows use. Warp 4 and Connect default to IBMPEERS. If you
have a network with a lot of Microsoft LAN Manager clients and no NT or
LAN Manager servers, you might want to use the workgroup STANDALONE.
This allows the clients to start up faster.
- Check the line "printcap line" if you want to use Warp's
lp printer commands. I have only used printing with the standard PRINT
command though, so I don't know much about it.
- Don't make things too difficult the first time you want to use
Samba/2: create shares with public access (i.e. no password). See the
example SMB.CFG in the Samba/2 support files.
- Start NMDB.EXE (the nameserver; it will respond to
browsing requests from other clients on the network). If it returns to
the command prompt immediately or after 10 seconds or so, there's
something wrong. In that case, check the file LOG.NMB for any
messages. If it runs OK, open a new OS/2 window and start SMBD.EXE,
the Samba/2 server. It creates a logfile LOG.SMB. Both NMDB.EXE
and SMBD.EXE should run until you hit Ctrl-C.
- From yet another OS/2 window, use the Samba client to see if you
can get the shares from the Samba server listed:
SMBCLNT.EXE -L myPCname
- Now to something even more advanced: set up a connection to
a share of the Samba server and copy some files, list them on screen
If you use a public share, the password you enter should not matter.
Once you are in, cd and dir around as you please. It
works more or less like OS/2's command line FTP client (FTP.EXE).
- Another thing you can try is to send a message ('WinPopUp') with:
SMBCLNT.EXE -M myPCname
Or you can print to a network printer (if you have a printer share
defined in your SMB.CFG with:
SMBCLNT.EXE \\myPCname\faxprn -P
and then use the "print" command on the command line.
Back to top
Hints and tips on using Samba/2
- If you connect with the Samba client to a Warp 4 or Connect
machine and you use unencrypted passwords, be sure to specify the
password in CAPITALS!
- If you get messages "Warning - chroot(/) not done" or "Running
with no EID" in LOG.SMB: no problem. OS/2 is a
single-user system, it just doesn't have chroot or user IDs. If you
really want to get rid of these messages, you could set the debuglevel
in your SMB.CFG a bit lower.
- If you edit SMB.CFG with E.EXE, it will probably add
Ctrl-Z to the end of the file. This confuses the configuration reader
of Samba a bit. You'll get the warning "Ignoring badly formed line:
<Ctrl-Z>". Just ignore it.
- See my SMB.CFG example for setting up an entry for the
faxprinter (FaxWorks). If you want to print from another machine (e.g.
Windows for Workgroups) to this remote printer you have to install the
IBM Proprinter X24 printerdriver. This example isn't really useful
since you still have to go to the machine with the modem to enter the
faxnumber and dial out :-)
- I tried to make sure that the names of all files (temporary /
configuration / binaries etc.) conform to the 8.3 restriction. This
should allow Samba/2 to run on FAT partitions as well as on any other
file system. Files affected are:
smb.conf -> SMB.CFG smbclient -> SMBCLNT.EXE
Take these name changes into account when you read the Samba
documentation. As far as I know, Samba/2 seems to work OK on FAT but
should you bump into a problem, please mail me.
OS/2's and Unix' command interpreters work a bit differently. Under OS/2
you don't have to 'escape' most special characters. An example: under
Unix you browse a network with the command:
smbstatus -> SMBSTAT.EXE nmblookup -> NMBLOOK.EXE
nmblookup -S -d2 '*'
The asterix has to be escaped because otherwise Unix expands it to the
list of all files in the current directory. Under OS/2, you can just
NMBLOOK.EXE -S -d2 *
Another example is:
smbclient \\\\myPCname\\fdrive or: smbclient
SMBCLNT.EXE \\myPCname\fdrive SMBSTAT.EXE
checks and cleans up the list of connections. It uses the function kill(pid,0)
to see if the process pid exists. However, kill() works only
for direct child processes (OS/2 limitation). I made a workaround in
REXX which processes the output of PSTAT.EXE. This is really
slow, I know, but it works. (I have tried to use OS/2's native API but
it seems an undocumented function has to be used. So far I couldn't get
it to work).
Samba does not support Extended Attributes (EAs). This typically
includes creation date, last revision date, author, file description,
and icon associations, things you mainly specify in
"Settings"/"Properties". Extended attributes can also contain other
application-specific data. For instance, PMView can create thumbnail
icons for pictures and stores these in the EAs. OS/2 and many of its
applications warn the user whether data is being stored on a drive that
does not support extended attributes. I don't know how difficult it
would be to implement EA support. It doesn't seem to be a very big
limitation though. A simple workaround would be to use OS/2's standard EAUTIL
command. You can use it to extract the EAs from a file and store it in a
seperate file which can be stored on filesystems that don't support
EAs, such as Samba's. And vice versa. Type HELP EAUTIL for
more on this. A problem is that EAUTIL only works on one file at a
time. You might want to check out utilities such as EABACKUP,
which can process a whole batch of files.
I haven't really looked at the password stuff yet. I noticed that
I couldn't connect to a server if the password was typed incorrectly.
Encrypted passwords are now supported in the Samba/2 client only. If
you want to recompile the client, you will need to download the libdes
package. I had to modify the sources of libdes a bit to get it compiled
OS/2 doesn't have multi-user support (yet?), and a lot of
functions in the EMX libraries to do with passwd files don't actually
do anything. I'm not quite sure what doesn't work because of that
limitation, but it seems to me that this is the cause of the home
directories not working. I haven't actually disabled anything, so if
you try setting this up, behaviour is undefined. I admit that this
limits the usuability because it seems to me that you can only have
public shares where the only protection will be 'read-only' etc. (Is
this correct?). I'm looking into stealing the password functions of
wu-ftpd (OS/2 version) for this...
After startup, SMBD.EXE and NSMBD.EXE do not
return to the command prompt as the Unix versions do. If that's a
problem to you, you can always use "detach" the process. You can kill
it with Ctrl-C. However, I noticed that sometimes I had to press Ctrl-C twice.
Timezone support (environment variable TZ) may
be a bit confusing. It seems the user has to reverse its sign. E.g. if
you live in Berlin your timezone is GMT+2 but according to Eberhard
Mattes you have to specify it in the CONFIG.SYS as SET TZ=GMT-2.
for a program which calculates your timezone variable and which can also
set your system clock automatically using an Internet time server.
Although I do have TCP/IP v2.0 for OS/2 and even Warp 4, I
haven't really bothered to test the lp printing support. So I'm not
sure if it works, with the right print commands. According to Jason
Rumney, OS/2's lpq uses a format different from the versions of lpq
already supported by Samba but it should be "easy" to accomodate the
In the sample OS/2 SMB.CFG I've used some simple command lines
which allow people to use OS/2's standard print system. It works
reasonably well, i.e. you can print to a Samba/2 server, but deleting a
printjob or showing the printqueue is difficult. HELP PRINT
will show some information on how to use the PRINT options for the lpq,
lprm and print command lines in the Samba config file. I had a
hard time getting the "message command" working for SMBD.EXE
('WinPopUp messages'). I did some braindead hacking and finally got it
working, using a dummy executable (DUMMY.EXE) which does
nothing but executing the program given as an argument. If you have a
better idea, please tell. Please note that you have to specify path in
the OS/2 notation with backslashes, and not in the Unix notation with
Configuration lines similar to the "message command"
that run external programs have the same problem. Take for example "preexec"
and "postexec". In contract with the the "message command"
you need to specify the full paths. That's because when a user logs in,
Samba goes to the root directory. I'm not sure if you can use ECHO
or similar OS/2 commands that print to the OS/2 command window. That's
because in the Samba source, the output of the complete statement is
sent to /dev/null. So in the OS/2 version I do the same. The reason (I
think) is that Samba is intended to be run as a daemon and not from the
command line, so you are not supposed to see messages from the daemon
on the command window. All messages should be sent to a file. It might
be that if you specifiy an output file in the preexec line that it will
not be sent to /dev/null. Haven't tried that yet. Here's an example for
the "preexec" command:
The OS/2 version of smbtar (for automatically backing up a client
machine using smbclient) hasn't been tested.
FAT and HPFS don't support (symbolic) links. This means setting
the configuration option "follow symlinks" to No doesn't have the
Due to a limitation in the implementation of the stat() call
under EMX, you should not set "getwd cache = Yes". Leave it to the
Back to top
comment = Jacco's D: drive (OS2/HPFS)
path = d:/
read only = no
public = yes
preexec = detach d:\samba\dummy.exe d:\samba\knocknock.cmd
Somebody logged in!!!!
So far, I can't really find an outright Samba/2 specific bug for which
I am personally accountable (patting my own back :-). However, I haven't
tested all of Samba's features since I don't really need them or don't
have the big network required for serious testing. There are also some
annoying things which need some more work (see "Hints
and tips on using Samba/2").
- EMX does not support file locking through the flock()
and fcntl() calls. I decided to not let these calls fail
because that would make the port unusable (not reading/writing any
files). So be sure to not access a file with more than 1 client at the
same time. Perhaps it works anyway because then the OS/2 file locking
might kick in, but I don't know.
- EMX does not have support for password files. This probably means
that you can run Samba/2 only in "share level", not "user level"
(perhaps "server level"?). I need to steal source code for the getpwnam(),getpwent()
etc. calls somewhere...
- Copying a WPS folder on the remote Samba server to another
location on that same server is not supported. This is a generic Samba
limitation because "SMBcopy tree copy" is not (yet) implemented. Ugly
workaround: you can copy the folder first to your local disk and then
move/copy it the new location.
- SMBSTAT.EXE scans all *.SHR files in the locks
directory. However, it seems that it also thinks some other files in
that directory are share files. You then get a warning share file
X has incorrect locking version. This is only an esthetic problem,
it doesn't cause any harm. Could be a bug in EMX.
- I noticed a serious bug in Warp 4 and Warp Connect: they can be
crashed by the Samba client (smbclient/SMBCLNT.EXE) over the
network. Fortunately, I managed to find a workaround. Click here for more information.
- Warp 4 and Connect have problems browsing the current version of
Samba. NET VIEW doesn't detect Samba servers but NET VIEW
\\machine if you know the specific name of a Samba server works OK.
In the folder "LAN Resources" Warp 4 and Connect do not seem to find
shared disks, but I think it did find my shared printer.
All this is caused by Samba not supporting LAN Manager announcements.
However, a patch has been made which supports these announcements but it
hasn't been included in the standard Samba distribution (yet). Samba/2
already has this fix. Read this page for more
- If you get a "secondary writebraw failed" error or a
SIGPIPE (see log.smb) you probably need a (newer) update of OS/2's
TCP/IP stack: ftp://ftp.software.ibm.com/ps/products/tcpip/fixes/v2.0os2/lateststack/,
assuming you have TCP/IP v2.0 or FreeTCP. I'm not sure if Warp
Connect's TCP/IP v3.0 stack has the same problem, if so, you'll need
- EMX's terminal interface support (for the keyboard) can be put in
OS/2 or Unix mode. I tried to use the best mode for different actions
(the normal SMBCLNT.EXE command prompt resp. the SMBCLNT.EXE
-M message body entering). If you have a problem with any of these,
please tell and I'll see what I can do.
Back to top
If you are only interested in using Samba/2, and not programming
or (re)compiling it, just skip the following part and jump right to the Todo list!
Shopping list for (re)compiling Samba/2:
- The Samba source
- My OS/2 patch for v1.9.16p11. If you want,
you can also click here for extensive
comments on this patch.
- The Samba/2 support files.
- OS/2 Version 2.x or greater (but I haven't actually tested
anything less than Warp 3)
- One of the following TCP/IP packages for OS/2.
- IBM TCP/IP 4.0 included in OS/2 Warp 4
- IBM TCP/IP 3.0 included in OS/2 Warp Connect
- IBM TCP/IP 2.0 Base Kit with CSD64092 or greater applied
- The Internet Access Kit (IAK) from OS/2 Warp's BonusPak
- The IAK with FreeTCP added
(allows you to use a network card with Warp 3.0 Red or Blue spine)
- EMX 0.9c development system: EMXRT.ZIP, EMXDEV1.ZIP, EMXDEV2.ZIP, GNUDEV1.ZIP, GNUDEV2.ZIP
Recommended is EMXVIEW.ZIP,
because it contains the same documentation as in the \EMX\DOC directory
but in OS/2's native INF form. Be sure to get the latest version of EMX,
you also need to install the update EMXFIX02.ZIP.
All these files are quite big, so take your time to download them.
Europeans might want to check out the mirror sites ftp.leo.org
- The OS/2 ports of GNU tar, GNU zip, GNU make, GNU diff, GNU patch
and GNU awk. Available as resp. GTAR251.ZIP,GZ124_32.ZIP,GNUMAKE.ZIP, GNUDIFF.ZIP,GNUPATCH.ZIP
- An OS/2 accessible partition which supports long filenames (such
as HPFS). The Samba/2 and EMX files should take about 17 MB, but you'll
probably need more for the swapfile. Samba/2 must be compiled on
a filesystem with long filenames because many of the original Unix
source files have long names. If you take yourself seriously as a
programmer, this requirement shouldn't be too much of a problem.
- Enough memory. I could compile Samba/2 on a DX2-66 with 8 MB RAM,
but I think it took more than an hour. Not something you would enjoy if
you're in a creative mood. A Pentium-100 with 32 MB is what I use right
Back to top
- Read \EMX\DOC\INSTALL.DOC on how to install the EMX
development stuff. I won't reiterate what is being said there (sorry,
no handholding :-). I'll give one hint though. Here's what my
CONFIG.SYS looks like. Adjust the paths and driveletters to your setup.
The last two lines make sure that pipes are used instead of temporary
files, and that the compiler remains in memory for 5 minutes (see EMX
docs). Use these two lines only if you have enough memory.
SET PATH=F:\OS2APPS\EMX\BIN; ...etc...
- Unzip GNU tar, GNU zip, GNU make, GNU diff, GNU patch and GNU awk
to an empty directory. Throw away everything but the executables (the
source code is not needed): TAR.EXE, GZIP.EXE, GNUMAKE.EXE,
DIFF.EXE, PATCH.EXE, GAWK.EXE. Then move these executables to a
directory in your path, for example \EMX\BIN. Also rename the
GNU Patch executable PATCH.EXE to GNUPATCH.EXE,
because OS/2 already comes with a program called PATCH.EXE.
- Unarchive the Samba source code:
tar xfvz samba-1.9.16p11.tar.gz
- Copy the OS/2 patch to
Samba's source directory samba-1.9.16p11\source, go to that
directory and apply the OS/2 patch:
gnupatch < os2.pat >& patch.out
patch.out will contain the messages generated during the
patch process. Check that everything "succeeded" and that nothing
- Unzip the Samba/2 support files to source directory.
- Note: I edit the C source code with EPM.EXE, and the
Makefile with E.EXE. The thing to watch out for is that your
editor doesn't convert tabs into spaces. This is especially bad for the
Makefile because otherwise GNU make won't be able to parse it. TEDIT.EXE
and older (Warp 3) versions of EPM.EXE are a very bad example
of this... If you have Warp 3, you might want to download the latest
version of EPM from ftp.cdrom.com.
- Now edit the Makefile. Search for the keyword OS/2 in
the Makefile. Read the comments I wrote there. Most of the OS/2 related
configuration options have been put together in one big section.
Uncomment the whole section (except for the real comments in English of
course!).I just like to have the stuff together in one section because
it's easier to comment, uncomment and edit. Unfortunately, it also
means there are some duplicate lines. If you edit one line in the
Makefile (say, BASEDIR =/usr/local/samba), the line in the
OS/2 section will override it. So watch out you don't make a change and
then wonder why nothing happened...
- If you have added new function calls to the source code, do a MAKE
PROTO to generate a new prototype file PROTO.H
- Encrypted passwords are now supported by Samba/2 but password
files not (yet?). This means effectively that only SMBCLNT.EXE
can use encrypted passwords and not SMBD.EXE. Anyway, for
encrypted passwords you need to download libdes, the DES
encryption library. I used version 4.01. Untar the file, e.g. with:
tar xfvz libdes-4.01.tar.gz
There are also some minor changes needed in the libdes Makefile. After
compilation you need to rename the resulting file LIBDES.A to DES.A
before OS/2+EMX will be able to use it (I don't know why). Working
on this! Mail me if you want them! Uncomment the 4 DES lines in the
Samba Makefile (DES_BASE, DES_FLAGS, DES_LIB
and PASSWD_FLAGS). If you had installed libdes into \USR\LOCAL\LIBDES
you don't have to change the path in the DES_BASE line.
Now you can execute MAKE and the executables will be built.
- Unlike the normal Unix instructions, do not use MAKE INSTALL
or MAKE INSTALLBIN etc. to install the executables to their
final destination. These haven't been tested. They might work with
alternative shells, such as KSH.
Hints and tips compiling Samba/2
Back to top
- Some of the executables generated by the Makefile do not conform
to the 8.3 restriction. At first, I changed the Makefile so that it
resulted in 8.3 names for OS/2 and full names for Unix, but I changed
my mind. I wanted to change as little as possible to the original
Makefile, so I decided to make a seperate command file (83COMPAT.CMD,
in SMB2_SUP.ZIP) which you can use to rename the long
filenames to shorter 8.3 FAT compatible names.
- Keep copies of the original Samba files. I copy them as *.orig.
You could even keep a completely seperate source tree of the original
- If a new version of Samba comes out, you don't have to download
the complete source code. You can download the patch file instead.
Patches, say from version 1.9.16p11 to 1.9.16p12, have to be applied as
gnupatch -p1 < samba-1.9.16p11-samba-1.9.16p12 > patch.out
while the current directory is samba-1.9.16p11.
- Do not use DMAKE
because it seems to have a bug in handling long command lines or so. The
problem was solved immediately when I switched over to GNU make.
- Compiling leaves empty files (nmblookup, nmbd, smbd, smbclient
etc.) in the directory. I don't know how to prevent them but they don't
seem to be a problem.
- After compiling the executables, I strip the symbols from them so
that their size is reduced. I do that with the following command under
for %i in (*.exe) do emxbind -s %i
- I maintain the
original files as *.org files. Then I create diffs under 4OS/2 with:
for %i in (Makefile *.h *.c) do diff -u %i.orig %i >>
Using Warp 4 and Warp Connect together with Samba/2
You can't run the Samba/2 server (SMBD.EXE and NMBD.EXE)
on Warp 4 or Connect if you have installed the "NetBIOS over TCP/IP"
protocol using MPTS.EXE. That's because both want to listen to the
NetBIOS ports for incoming connections (137/138/139). So either:
There are no problems when you use the Samba/2 client SMBCLNT.EXE
in an OS/2 window to access other machines. Of course, Warp's support is
much more comfortable (drive letters, etc.) so you'll probably prefer it
over SMBCLNT.EXE. One exception would probably be if you want
to access a Windows 95 machine and copy files with long filenames.
- Use the Samba/2 server, but don't install Warp's File and Print
- Use Warp's File and Print Client and install its "NetBIOS over
TCP/IP" protocol, but don't install the Samba server
- Use Warp's File and Print Client and install the Samba/2 server,
but don't install the "NetBIOS over TCP/IP" protocol
Back to top
Back to top
- EMX doesn't have statfs() yet, which meant that I
couldn't get the free and total disk space. At first I turned to REXX
but that turned out to be very slow. I then wrote a partial
implementation of statfs() using OS/2's native API. If you
have a better idea, rewrite the statfs() code or use a custom
"dfree command" in SMB.CFG.
- EMX's terminal interface support (for the keyboard) can be put in
OS/2 or Unix mode. I found that OS/2 mode works best for the normal
smbclient CLI, but when you enter a network message with smbclient -M
the Unix interface is better. That's because Ctrl-D's (to end the
message) will be detected then. Another difference between the two
modes is the handling of the '\' key. Anyway, if you want to change it,
search for IDEFAULT in client.c and recompile.
- I decided to use str_checksum() instead of the inode
number in the name of a lock file. This is because EMX returns a
different value for st_ino on each call. It is mentioned in the docs so
it seems to be a feature. By the way, does the output of str_checksum
remain within 8 digits (to keep the filename within 8.3 specs)? As far
as my mathematical knowledge goes, it does, if hex notation is used.
- According to the EMX docs, fork() now works with a
dynamically linked C library (-Zcrtdll). This should save some memory,
for instance when multiple users log on to the Samba server.
Back to top
- Add support for redirected serial ports? Windows doesn't support
them out of the box but most OS/2 networking software (Warp Connect,
Warp 4 and the free Microsoft OS/2 LanManager client) and some third
party DOS and Windows programs do.
- Support for NET WHO command? I know that at least the LanManager
Client has it. It lists the users on a server.
- Support for Extended Attributes (EAs). I don't know how difficult
it would be to implement this.
- Make the Samba client an Installable File System using the OS/2 ext2fs
filesystem driver as an example? This could be one heck of a job,
basically writing a freeware implementation of "IBM File and Print
- Samba/2 uses fork(), just as the Unix version. However,
according to the EMX author, fork() is very ineffecient and
should be replaced by spawn(). Perhaps later. I don't assume
Samba/2 will be hosting tens or hundreds of clients anyway...
- Would it be beneficial to use OS/2's filelocking instead of the
- Implement support for password file (and thus home directories?).
Perhaps the password functions of wu-ftpd (OS/2 version) can be used
- Support for serial numbers and other characteristics of drives.
- Steal source code of some FTP client and hang smbclient code in
it. Or even better, integrate the client code with a webbrowser, for
instance as a plug-in or a proxy server. Consider it a SMB <->
HTML interface of some sort... (Surprise! Somebody has done exactly
this! See smb2www).
- Instructions on how to connect to/from servers + LanMan
- Fix up OS2.txt and Warp.txt (i.e. include my LanMan.txt).
Back to "Using Samba with DOS or OS/2"
Back to Jacco's homepage