by I am definitely a linux newbie and only sort of expert with
Windows NT, but I have run into a stumper that still has the Cobalt
Networks technical support people stumped (and they've been working on
this for several days, with over a week inserted in the middle for
both them and me to think about it). Previously determined
information is first in this message, followed by new information.
Previously determined information (mostly -- new items have a *)
----------------------------------------------------------------
At the places I work -- San Luis Obispo, CA and
Emeryville, CA -- we have a Cobalt Qube 2 at each site acting as a
web/ftp/e-mail/file/DNS/DHCP/WINS server and network address
translator, with several Windows NT 4.0 clients (and in the case
of San Luis Obispo, also Windows 95 and Windows 98 clients). The
problem we are having is that when I try to do the following at our
San Luis Obispo site, it always gives the error message "incorrect
password or unknown username for:" / {Qube 2 network name}, even
though I just put in my correct user name and password. I can confirm
that my user name nd password are correct because I am able to use FTP
to get to my files. In contrast, if I log in as "admin" with the
appropriate password, I can get to "admin"-accessible files without a
hitch. Not only that, but at our Emeryville site, I have no such
problem with user files either. It makes no difference what my
Windows NT user name and password are. The same thing happens with
Windows NT 4.0 SP3, SP4, and SP5, and with Windows 95 SP1 (with the
difference that the Windows 95 user name has to be the same as the
Qube user name, because when attempting to access a shared volume, it
only asks for a password, and not a user name). I checked all of the
Qube 2 services in the web-based configuration interface to confirm
that nothing was left out of or set incorrectly set in the
configuration for Windows file sharing, FTP, DNS, and DHCP -- if
something is incorrectly set for one of these services, it must be set
in a part of a configuration file that does not show up in the
web-based interface. I also manually looked inside of /etc/smb.conf,
and although I am not familiar with what does what in this file, I
didn't notice anything obviously strange when comparing these files
from the two systems; however, I don't think it is anything in here,
because the only difference between the files (according to diff) is
the line which specifies the workgroup/domain for the Cobalt Qube 2).
I didn't experiment with manually editing any configuration files,
because this might void the Cobalt warranty, and I am not sufficiently
familiar with linux to know what is safe to edit and what isn't.
To summarize:
Case 1:
1. Log in on Windows NT 4.0 (SP3 -- I may have also tried this
on a machine with SP4, but I'm not sure) in our Emeryville
office.
2. Double-click Network Neighborhood.
3. Navigate until the Cobalt Qube 2 is shown; double-click on it.
4. Enter any valid Cobalt Qube 2 user name (except "root", which
is specifically forbidden) and password combination.
Result: It works -- the files for the user you selected are now
accessible just as if they were on a Windows NT file server.
Case 2:
1. Log in on Windows NT 4.0 (SP3, SP4, or SP5) or Windows 95 SP1
in our San Luis Obispo office. If logging in on Windows 95,
log in as "admin".
2. Double-click Network Neighborhood.
3. Navigate until the Cobalt Qube 2 is shown; double-click on it.
4. Enter "admin" and the Cobalt Qube 2 password for this account
(Windows 95 does not give the opportunity to enter the user
name).
Result: It works -- the files accessible to the "admin" account are
now accessible just as if they were on a Windows NT file
server.
Case 3:
1. Log in on Windows NT 4.0 (SP3, SP4, or SP5) or Windows 95 SP1
in our San Luis Obispo office. If logging in on Windows 95,
log in as a valid Cobalt Qube 2 user other than "admin".
2. Double-click Network Neighborhood.
3. Navigate until the Cobalt Qube 2 is shown; double-click on it.
4. Enter any valid Cobalt Qube 2 user name except "root" or
"admin", and the appropriate password (if using Windows 95,
enter only the password for the Cobalt Qube 2 user name you
used to log into Windows 95).
Result: It never works -- it always claims the user name and password
are incorrect.
Variations I have tried (under Windows NT 4.0 SP4 at our San
Luis Obispo office), with absolutely no effect:
A. Make a Windows NT account with the same name and password as
the Cobalt Qube 2 account.
B. Change the Windows NT machine's workgroup to be the same as
the workgroup/domain that the Cobalt Qube 2 is in.
C. Different Windows NT 4.0 service packs as noted above (not on
the same computer).
D. Different computers with the same Windows NT 4.0 service pack.
E. Change what (if any) accounts are permitted telnet access into
the Cobalt Qube 2.
*F. Change a San Luis Obispo office Windows NT machine's name to
be the same as the unix user name (except for the case -- it
won't let me make it lower case).
*G. Enable plain text password negotiation on a San Luis Obispo
office Windows NT machine -- not acceptable for long-term
use, but it didn't even help in the short run.
I also confirmed that every Windows 95/NT computer I used is
capable of correctly accessing files on a Windows NT 4.0 SP3 server.
On the subset of these computers that I also tried pinging the Cobalt
Qube 2 or accessing it via FTP, ping and FTP also work correctly.
Our networks are configured very similarly, with the following
differences:
1. The domain/workgroup names are different.
2. The outside IP addresses (on the secondary ethernet interfaces
of the Cobalt Qube 2's) are different.
3. The Emeryville office only has 1 Windows NT workgroup, whereas
the San Luis Obispo office has multiple Windows NT workgroups.
4. The Emeryville office has its connection to the outside world
(from the secondary ethernet port of the Cobalt Qube 2)
through an Alcatel DSL 1000 "modem" over DSL service provided
by Pacific Bell; the San Luis Obispo office has its connection
to the outside world (also from the secondary ethernet port of
the Cobalt Qube 2) via an ethernet cable to a hub and/or
router in the office of our local ISP next door.
5. Something unknown in the configuration of the Emeryville
office connection to the outside world causes a reverse DNS
lookup by a remote site to return a CNAME record instead of a
PTR record (according to the sysadmin of the remote site) --
see my accompanying post (about resulting problem) only in
comp.os.linux.networking.
*6. In the Emeryville office, the Windows NT machines have the
same name (except for case) as the unix user name of the
person who normally uses it. On the other hand, this doesn't
seem to make a difference (see F above).
7. The Cobalt Qube 2's differ very slightly as detailed below.
The Cobalt Qube 2 in our Emeryville office (on which things
seem to work properly) is configured with the following software:
Cobalt OS Release 4.0 (original install)
Cobalt Qube2 Update Release 1.0 (original install)
Shell History Patch Release 1.1 (original install)
"RUNNING MFG TESTS" minor bug (original install -- a patch is
available, but not installed here)
The Cobalt Qube 2 in our San Luis Obispo office (on which
Windows file sharing doesn't work right) is configured with the
following software:
Cobalt OS Release 4.0 (original install)
Cobalt Qube2 Update Release 1.0 (added as patch from manufacturer)
Shell History Patch Release 1.1 (added as patch from manufacturer)
Doesn't have "RUNNING MFG TESTS" bug
Note: Cobalt OS 4.0 on the Cobalt Qube 2 identifies itself (before it
gives the login prompt) as "Cobalt Linux release 4.0 (Fargo)" /
"Kernel 2.0.34 on a mips".
New information
---------------
Our /etc/smb.conf as it came from the manufacturer (including
the incorrect server string) follows. Note that the Emeryville and
San Luis Obispo versions are identical except for the workgroup name.
[BEGIN /etc/smb.conf]
; Samba Configuration
; Revision 1.0 for the 2700RJ, jdbl...@cobaltnet.com 17.oct.98
;
; DO NOT USE THE \ CONTINUATION! THE QUBE PARSING CODE WILL CHOKE ON
IT!
;
[global]
alternate permissions = no
case sensitive = no
dead time = 5
debug level = 0
default case = upper
delete readonly = yes
delete veto files = yes
dns proxy = no
domain logons = yes
domain master = no
encrypt passwords = yes
follow symlinks = yes
guest account = ftp
local master = yes
lock directory = /var/lock/samba
locking = yes
log file = /var/log/samba
mangle case = no
map hidden = yes
map system = yes
max log size = 5000
oplocks = yes
os level = 1
preferred master = yes
preserve case = yes
security = user
server string = Cobalt Qube 2800WG
share modes = yes
short preserve case = yes
socket options = TCP_NODELAY
strict locking = yes
veto files = /Network Trash Folder/
wide links = yes
wins support = yes
workgroup = acmppi
;
[homes]
comment = Home Directories
browseable = no
read only = no
create mask = 0755
;
;home BEGIN (do not delete this line)
[home]
path = /home/groups/home
public = no
browseable = yes
writable = yes
printable = no
create mask = 0775
valid users = admin @home
force create mode = 0664
force directory mode = 0775
hide dot files = yes
;home END (do not delete this line)
;allusers BEGIN (do not delete this line)
[allusers]
path = /home/groups/allusers
public = no
browseable = yes
writable = yes
printable = no
create mask = 0775
valid users = admin @allusers
force create mode = 0664
force directory mode = 0775
hide dot files = yes
;allusers END (do not delete this line)
[END /etc/smb.conf]
Note: The Samba version included in Cobalt OS 4.0 is a release of
1.9.18p10
...
read more »