How to install Samba/2: 1.Unzip the Samba/2 binaries archive file to a directory, say C:\SAMBA. 2.Unzip the Samba/2 support files to the same directory. 3.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. 4.Install the EMX runtime files per the included instructions in EMXRT.DOC: 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. 5.I also added the following lines to my CONFIG.SYS: SET USE_HOSTS_FIRST=1 SET USER=jacco SET LOGNAME=jacco SET HOME=C:\USR\JACCO SET TZ=CET-1CED,3,-1,0,7200,10,-1,0,10800,3600 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). 6.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. 7.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...) 8.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 lines: 127.0.0.1 localhost 192.168.0.2 myPCname ...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! 9.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. 10.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 Using Samba/2 1.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: ping 127.0.0.1 This should result in something like: [e:\tcpip\etc]ping 127.0.0.1 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 ^C External process cancelled by a Ctrl+Break or another process 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 192.168.0.2 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: ping myPCname If that also works, great. 2.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. 3.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). 4.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. 5.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 :-) 6.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. 7.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. 8.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. 9.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. 10.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 11.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 etc.: SMBCLNT.EXE \\myPCname\fdrive 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). 12.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. If all these tests worked: congratulations, you seem to have installed Samba/2! 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: ". 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 smbstatus -> SMBSTAT.EXE nmblookup -> NMBLOOK.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: 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 use: NMBLOOK.EXE -S -d2 * Another example is: smbclient \\\\myPCname\\fdrive or: smbclient "\\myPCname\fdrive" compared with: 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 under OS/2. 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. Download TIME868.ZIP 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 OS/2 version. 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 forward slashes! 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: smb.cfg: [os2drive] comment = Jacco's D: drive (OS2/HPFS) path = d:/ read only = no public = yes preexec = detach d:\samba\dummy.exe d:\samba\knocknock.cmd knocknock.cmd: e.exe d:\samba\whoisthere.txt whoisthere.txt: Somebody logged in!!!! 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 desired effect. Due to a limitation in the implementation of the stat() call under EMX, you should not set "getwd cache = Yes". Leave it to the default, "No".