From: John E. Malmberg [wb8tyw@qsl.net] Sent: Friday, August 04, 2000 9:00 AM To: Info-VAX@Mvb.Saic.Com Subject: Re: Can't map to drive with SAMBA [Also posting to SAMBA-VMS@SAMBA.ORGanization (remove anti-spam device) Even though the SAMBA-VMS mailing list is not fully functional, it is being archived, and it is easier to look up things in the archive then find it in DEJA. For those on the SAMBA-VMS still receiving this, please cross post any replies to comp.os.vms or info-vax@mvb.saic.comPANY (remove anti-spam device) so that all can see the reply. Thank you.] "Drew Shelton" wrote in message news:01JSJCHR2WUS001V90@SEMATECH.Org... > "John E. Malmberg" wrote... > > >Windows NT in my case was requiring a valid guest > >account to be configured. For some reason it was > >connecting as guest first, before logging in as the > >user. If you do not have a guest account configured > >in your SYSUAF file, it would fail. > > I have a guest account. I even set it up with > /NOPASSWORD just to see, and set > "guest ok = yes", but I still can't connect. The name of the account is not "GUEST". The name is determined by a default name hardcoded into the SAMBA-VMS source in one of the source files, and can be overidden in the smb.conf file. For existing versions of SAMBA-VMS the default name of the guest account seems to be "UCX$NOBODY". > [snip] > >You can try enabling a higher debug level for the > >server process to see if it will give you some > >more information. > > I've never used SAMBA at all before, so I don't know > what a "good" value is for the debug level. I've tried it > at 10, and I've got a lot of information that I don't know > how to interpret. It seems that it can't find "/dev/null", > which isn't surprising. I don't know how to give it what it > wants. There is documentation available from links from http://www.samba.org for setting some of the debug options that can be specified in smb.conf. One that is of interest to you right now, (If it is in 2.0.3) is: debug uid = Yes This will put the uid that the SMBD is currently running in (decimal format) on every message in the log file. That will help you determine if and when that the SMBD process changed user context. Since it is working to connect to the SMBD context from SMBCLIENT (assumed different user than SYSTEM) you can get a debug log from that session and see how the validation messages look. I would generally start at Debug Level 4, and then move higher if more information is needed. At about debug level 8 or higher SAMBA starts showing the data that is coming and going down the wire. You should see a sequence where the maximum acceptable protocol is negotiated, and then calls to become user and change the default directory. For an NT client on 2.0.6, I see a sequence to become the guest user, remember the uid will be given in decimal, not the normal split octal you are use to. This is followed by setting the default directory to be /tmp. After this is sucessfull and some other transaction(), it then logs in as the user logged into the client. The debug messages generally always have the routine name that is causing them to be issued, and many times that name is either very close to the same name as a documented unix function, or is descriptive of what is happening. It is then followed by a longer text that sometimes explains what is happening. At higher debug levels, there is less explaination, and more raw data. Unfortunately I will not be able to put together a sample log with anotations to post for comparison purposes for at least another week. You will see error messages about having no /dev/nul and other /dev/mumble that do not exist on OpenVMS. The /dev/nul is essentially some code that supresses messages to SYS$INPUT, SYS$OUTPUT, SYS$ERROR that apparently some versions of UN*X may generate from routine calls that the SAMBA team apparently thought were distracting and misleading. In other cases SAMBA is simply probing the operating environment to determine what algorithm to use for calculating a random number. In one version that I was running under test, the fall back for OpenVMS when the test for /dev/random failed was to attempt to do a stat() on every file in the all subdirectories under the one where the SMBD was running. -John wb8tyw@qsl.network