No subject

$ smbclient "-L" nostromo.physics
%DCL-W-ACTIMAGE, error activating image SAMBA_CRTL
-CLI-E-IMGNAME, image file BSUHEP$DKA100:[SAMBA.][BIN]DECC_CRTL.EXE;
-RMS-E-PRV, insufficient privilege or file protection violation

That is weird because, as far as I know, I have the correct definitions:

   "SAMBA_EXE" = "SAMBA_ROOT:[BIN.VAX]" (LNM$SYSTEM_TABLE)
        = "SAMBA_ROOT:[BIN]"

    SMBCLIENT == "$samba_exe:smbclient.exe"

I thought @INSTALL and @LINK would take care of these privilege issues.
What is wrong here ?

Thanks a lot in advance,
 Luiz Guilherme Regis

On Sat, 2 Nov 2002, John E. Malmberg wrote:

> > Today's Topics:
> >
> >    1. RE: Samba 2.0.3 on OpenVMS (Dr. Guilherme Regis)
> 
> 
> > "Dr. Guilherme Regis" wrote:
> > Dear Samba 2.0.3 experts,
> >
> > I guess my problem with Samba 2.0.3 on VAX OpenVMS
> > rely on NETMASK and BCAST definitions.
> > Entries in Multinet program seem to be correct, that is,
> > Sub Net Mask = 255.255.255.0 e gateway = 10.87.16.1
> > But, when I map my Linux machine from VAX and vice-versa I get
> > the following results:
> >
> > On VAX: (encryption = no)
> > BSUHEP::SYSTEM> smbclient "-L" nostromo.physics
> > Added interface ip=10.87.16.252 bcast=10.255.255.255 nmask=255.0.0.0
> > Password: Domain=[BSUHEP] OS=[Unix] Server=[Samba 2.0.10]
> >
> > On Linux: (encryption = yes)
> > [lgemedia at nostromo lgemedia]$ smbclient -L vaxstation
> > added interface ip=10.87.16.254 bcast=10.87.16.255 nmask=255.255.255.0
> > Got a positive name query response from 10.87.16.252 ( 10.87.16.252 )
> > Password:
> > *** Nothing happens then, even having GUEST account correctly defined
> > on VAX.
> >
> > Both machines should have the same NMASK because they are in the
> > same network segment. As I have no problem in connecting to my VAX, it
> > seems that all MULTINET parameters are correctly defined.
> >
> > Now, searching on GOOGLE I found a message saying that NMASK definition
> > in Samba 2.0.3 VAX is broken. Is that right ?
> > I appreciate any comments on this subject.
> 
> 
> I do not know specifically about 2.0.3.
> 
> If you do not provide the NMASK in the SMB.CONF file, SAMBA attempts to 
> get it from the ethernet interface through the socket library.
> 
> This requires that the underlying TCPIP program to support this call.
> 
> I would not put in the NMASK parameter in the SMB.CONF file unless the 
> TCP/IP program does not support returning it.  You can check your 
> documentation, or just use trial and error.
> 
> I did find in NMBD 2.0.6 that under certain conditions, the NMBD program 
> will terminate with an access violation, since one of the socket calls 
> returns either a positive count or a negative number, and NMBD does not 
> test it before using it.   This was fixed in the SAMBA 2.0.6 vms 
> release, but not fixed in the UNIX base until the 2.2.x stream.
> 
> -John
> wb8tyw at qsl.network
> Personal Opinion Only
> 
> 
>