|
|
Table of Contents
This chapter contains client-specific information.
Yes. Thursby has a CIFS client/server called DAVE. They test it against Windows 95, Windows NT/200x/XP, and Samba for compatibility issues. At the time of this writing, DAVE was at version 5.1. Please refer to Thursby's Web site for more information regarding this product.
Alternatives include two free implementations of AppleTalk for several kinds of UNIX machines and several more commercial ones. These products allow you to run file services and print services natively to Macintosh users, with no additional support required on the Macintosh. The two free implementations are Netatalk and CAP. What Samba offers MS Windows users, these packages offer to Macs. For more info on these packages, Samba, and Linux (and other UNIX-based systems), see http://www.eats.com/linux_mac_win.html.
Newer versions of the Macintosh (Mac OS X) include Samba.
Basically, you need three components:
The File and Print Client (IBM peer)
TCP/IP (Internet support)
The “NetBIOS over TCP/IP” driver (TCPBEUI)
Installing the first two together with the base operating system on a blank system is explained in the Warp manual. If Warp has already been installed, but you now want to install the networking support, use the “Selective Install for Networking” object in the “System Setup” folder.
Adding the “NetBIOS over TCP/IP” driver is not described in the manual and just barely in the online documentation. Start MPTS.EXE, click on OK, click on , and click on in Protocols. This line is then moved to Current Configuration. Select that line, click on , and increase it from 0 to 1. Save this configuration.
If the Samba server is not on your local subnet, you
can optionally add IP names and addresses of these servers
to the IBM Peer
to bring it on
the same level as Warp 4. See the IBM OS/2 Warp Web page
This sections deals with configuring OS/2 Warp 3 (not Connect), OS/2 1.2, 1.3 or 2.x.
You can use the free Microsoft LAN Manager 2.2c Client for OS/2 that is
available from
ftp://ftp.microsoft.com/BusSys/Clients/LANMAN.OS2/. In a nutshell, edit
the file \OS2VER
in the root directory of the OS/2 boot partition and add the lines:
20=setup.exe 20=netwksta.sys 20=netvdd.sys
before you install the client. Also, do not use the included NE2000 driver because it is buggy. Try the NE2000 or NS2000 driver from ftp://ftp.cdrom.com/pub/os2/network/ndis/ instead.
Create a share called [PRINTDRV]
that is
world-readable. Copy your OS/2 driver files there. The .EA_
files must still be separate, so you will need to use the original install files
and not copy an installed driver from an OS/2 system.
Install the NT driver first for that printer. Then, add to your smb.conf
a parameter,
os2 driver map.
Next, in the file specified by filename
, map the
name of the NT driver name to the OS/2 driver name as follows:
, e.g.,nt driver name
= os2 driver name
.device name
HP LaserJet 5L = LASERJET.HP LaserJet 5L
You can have multiple drivers mapped in this file.
If you only specify the OS/2 driver name, and not the device name, the first attempt to download the driver will actually download the files, but the OS/2 client will tell you the driver is not available. On the second attempt, it will work. This is fixed simply by adding the device name to the mapping, after which it will work on the first attempt.
Use the latest TCP/IP stack from Microsoft if you use Windows for Workgroups. The early TCP/IP stacks had lots of bugs.
Microsoft has released an incremental upgrade to its TCP/IP 32-bit VxD drivers. The latest release can be
found at ftp.microsoft.com, located in /Softlib/MSLFILES/TCP32B.EXE
. There is an
update.txt file there that describes the problems that were fixed. New files include
WINSOCK.DLL
, TELNET.EXE
, WSOCK.386
,
VNBT.386
, WSTCP.386
, TRACERT.EXE
,
NETSTAT.EXE
, and NBTSTAT.EXE
.
More information about this patch is available in Knowledge Base article 99891.
Windows for Workgroups does a lousy job with passwords. When you change passwords on either the UNIX box or the PC, the safest thing to do is delete the .pwl files in the Windows directory. The PC will complain about not finding the files, but will soon get over it, allowing you to enter the new password.
If you do not do this, you may find that Windows for Workgroups remembers and uses the old password, even if you told it a new one.
Often Windows for Workgroups will totally ignore a password you give it in a dialog box.
There is a program call admincfg.exe
on the last disk (disk 8) of the WFW 3.11 disk set.
To install it, type EXPAND A:\ADMINCFG.EX_ C:\WINDOWS\ADMINCFG.EXE
. Then add an icon
for it via the Program Manager menu. This program allows
you to control how WFW handles passwords, Disable Password Caching and so on, for use with security = user.
Windows for Workgroups uppercases the password before sending it to the server.
UNIX passwords can be case-sensitive though. Check the smb.conf
information on
password level to specify what characters
Samba should try to uppercase when checking.
To support print queue reporting, you may find that you have to use TCP/IP as the default protocol under Windows for Workgroups. For some reason, if you leave NetBEUI as the default, it may break the print queue reporting on some systems. It is presumably a Windows for Workgroups bug.
Note that some people have found that setting DefaultRcvWindow
in
the [MSTCP]
section of the
SYSTEM.INI
file under Windows for Workgroups to 3072 gives a
big improvement.
My own experience with DefaultRcvWindow is that I get a much better performance with a large value (16384 or larger). Other people have reported that anything over 3072 slows things down enormously. One person even reported a speed drop of a factor of 30 when he went from 3072 to 8192.
When using Windows 95 OEM SR2, the following updates are recommended where Samba is being used. Please note that the changes documented in Speed Improvement will affect you once these updates have been installed.
There are more updates than the ones mentioned here. Refer to the Microsoft Web site for all currently available updates to your specific version of Windows 95.
Kernel Update: KRNLUPD.EXE |
Ping Fix: PINGUPD.EXE |
RPC Update: RPCRTUPD.EXE |
TCP/IP Update: VIPUPD.EXE |
Redirector Update: VRDRUPD.EXE |
Also, if using MS Outlook, it is desirable to install the OLEUPD.EXE fix. This fix may stop your machine from hanging for an extended period when exiting Outlook, and you may notice a significant speedup when accessing network neighborhood services.
There are several annoyances with Windows 2000 SP2, one of which only appears when using a Samba server to host user profiles to Windows 2000 SP2 clients in a Windows domain. This assumes that Samba is a member of the domain, but the problem will most likely occur if it is not.
In order to serve profiles successfully to Windows 2000 SP2
clients (when not operating as a PDC), Samba must have
nt acl support = no
added to the file share that houses the roaming profiles.
If this is not done, then the Windows 2000 SP2 client will
complain about not being able to access the profile (Access
Denied) and create multiple copies of it on disk (DOMAIN.user.001,
DOMAIN.user.002, and so on). See the smb.conf
man page
for more details on this option. Also note that the
nt acl support parameter was formally a global parameter in
releases prior to Samba 2.2.2.
Following example provides a minimal profile share.
Example 42.1. Minimal Profile Share
[profile] |
path = /export/profile |
create mask = 0600 |
directory mask = 0700 |
nt acl support = no |
read only = no |
The reason for this bug is that the Windows 200x SP2 client copies the security descriptor for the profile that contains the Samba server's SID, and not the domain SID. The client compares the SID for SAMBA\user and realizes it is different from the one assigned to DOMAIN\user; hence, access denied message.
When the nt acl support parameter is disabled, Samba will send the Windows 200x client a response to the QuerySecurityDescriptor trans2 call, which causes the client to set a default ACL for the profile. This default ACL includes:
DOMAIN\user “Full Control”>
This bug does not occur when using Winbind to create accounts on the Samba host for Domain users.
If you have problems communicating across routers with Windows NT 3.1 workstations, read this Microsoft Knowledge Base article:.