Previously, Mike Davies wrote in qdn.public.sysadmin:
I am trying to get Samba up on QNX 6, and it all works OK so long as I
don’t have password encryption switched on.
User logons and passwords are
the same for both Windows machines and the QNX machine.
Doesn’t matter, but OK.
( the user must have a valid entry in /etc/passwd for the smbpasswd
program to accept them, but the user does NOT have to have any valid
password, nor any password at all, on the *nx box )
It’s NOT necessary for the user to be allowed to log into the *nx machine
as a *nx user AT ALL, which is easily accomplished by removing the encrypted
password string from the shadow file.
Clients are Win98
and Win2k. When I switch encryption back on on the Clients and server I get
the endless “Resource \qnx_server_name\IPC$ Password required” dialog box
scenario. None of the passwords work, neither root nor User.
That would be correct !
You will need the latest version of SAMBA for Win2K to work, in non-NT modes.
Microsoft made a rather deliberate attempt to break samba and make Win2K not work
with it. They broke NT compatibility in the process, so if the Win2K machine
will work with a real NT server without the Win2K compatibility patch on it, then
it should work with older versions of SAMBA and NTserver in NT compatibility mode.
Since SAMBA makes a better NT server than NTServer does…
I made the
smbpasswd file by using the command “cat /etc/passwd | mksmbpasswd.sh
smbpasswd” and this seems to have worked OK (except that encrypted passwords
still don’t work :-/ )
Well, it made “a” file, but not a correct file.
the passwd file doesn’t contain passwords, encrypted or otherwise.
Anyone who knows the magic trick will earn my undying gratitude, this has
cost me 3 days so far !
( but it’s not magic )
A typical line from the smbpassword file is :
XXX:> :LCT-00000000:Test User
[u]Yup. Nuthin’ there !
You’ve basicly copied a file telling the system that the user exists, but
nothing else. Whatever the system gets when it decrypts XXXXXXXXXXXXX is what the
windows client needs to supply. Obviously, we can’t know what that might be, and
know it before it’s encrypted.
Here’s what you need to do…
delete the /opt/etc/samba/smbpasswd file if it exists ( that’s where it should be ).
Now, AFTER you’ve enabled password encryption in smb.conf and re-started the smbd
daemon ( so it knows to encrypt/decrypt using the correct algorythms ) then you
smbpasswd -a testuser
to create the proper encrypted smbpasswd entry for the user testuser,
adding the user testuser if he/she does not already exist.
If that user does already exist, it won’t matter, and you need to do this
anyway so that the proper encryption/decryption is applied.
Although testuser must have an entry in the /etc/passwd file, to show as
a valid user on the system, that user does NOT have to have a password entry
in /etc/shadow which is where the real unix encrypted ( but not windows
encrypted ) passwords are kept.
Hope this helps…
A mushroom cloud has no silver lining.[/u]