Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

Re: Samba v1.2 NMBD crash

Go to solution

Samba v1.2 NMBD crash

I get a crash of Samba program  NMBD  when attempting to start

Samba v1.2 on either IA64 or AXP, both running OpenVMS v8.3.


System patches are generally current to early 2010, including

Update-v1200, Sys-v1500, and ACRTL-v0800 (nov-2009) on IA64;

and Update-v1200, Sys-v1600, and ACRTL-v0600 (nov-2009) on AXP.


Neither Samba installation showed any problems, using 

HP-I64VMS-SAMBA-V0102--1, and HP-AXPVMS-SAMBA-V0102--1.


When starting Samba, the samba$Startup and samba$common_Startup

processes complete OK, and the NMBD process is begun, but then crashes.


The samba$Log:samba$nmbd_SDPHI0.log file on IA64 shows:

$ nmbd "-d1"

%SYSTEM-F-ACCVIO, access violation, reason mask=00,

virtual address=0000000000000008, PC=00000000007434C1, PS=0000001B

%TRACE-F-TRACEBACK, symbolic stack dump follows

image     module    routine               line      rel PC           abs PC

SAMBA$SHR   0 00000000007014C1 00000000007434C1

SAMBA$SHR   0 000000000016FED2 00000000001B1ED2

SAMBA$NMBD  0 0000000000020132 0000000000020132

SAMBA$NMBD  0 00000000000200D2 00000000000200D2

SAMBA$NMBD  0 0000000000021332 0000000000021332

SAMBA$NMBD  0 00000000000221E2 00000000000221E2


There is a dump file, SAMBA$ROOT:[BIN]SAMBA$NMBD.DMP;2 size 50675.


Similarly, on AXP the samba$Log:SAMBA$NMBD_SDPHA6.LOG file shows

%SYSTEM-F-ACCVIO, access violation, reason mask=00,

virtual address=0000000000000004, PC=0000000000467ECC, PS=0000001B

%TRACE-F-TRACEBACK, symbolic stack dump follows

  image    module    routine             line      rel PC           abs PC

 SAMBA$SHR                                  0 0000000000415ECC 0000000000467ECC

 SAMBA$SHR                                  0 00000000001E072C 000000000023272C

 SAMBA$NMBD                                 0 00000000000300D4 00000000000300D4

 SAMBA$NMBD                                 0 000000000003006C 000000000003006C

 SAMBA$NMBD                                 0 00000000000303B4 00000000000303B4


IA64$ Analyze/Obj on samba$Shr.exe shows no obvious Match Control problems,

including DECC$Shr.exe (Less/Equal 1.,1., v8.3-01 0080070038 9-oct-2009).


I had previously been running Samba v1.1 on the VMS8.3 Alpha.  After installing

Samba v1.2 on the IA64, I noticed UAF account oddities involving samba_root versus

samba$root, so I removed all Samba accounts and then re-installed Samba.  All

accounts appear normal now, on a cluster-common SYSUAF.


Any suggestions would be welcome, especially regarding ACRTL viability.

I have no HP support, and am now unable to access Patch Kits, since HP recently

removed access for Campus Software Licensing Grant licensees.


Fred Driscoll

UCSD Physics

Respected Contributor

Re: Samba v1.2 NMBD crash

Hi Fred,


Check samba$root:[var]log_<hostname>.log for errors.   One common cause is the account used to start CIFS doesn't have a unique UIC identifier associated with it:


UAF> SHOW /IDENT <username>





Re: Samba v1.2 NMBD crash



You are right on target as to the error, but I still haven't got to a fix.


 The log file in samba$Log is confusingly called "log_<nodeName>.nmbd",  and it identifies the error as

 "[2011/07/31 08:04:11, 0] SAMBA$SRC:[SOURCE.VMS]VMS_SECURITY.C;1:(513)
  get_uai: The UIC value of the identifier system is not the same as UIC of the user account system"


I chose non-standard UIC=360 on installation, giving

UAF> show/br samba$* 

 Owner         Username           UIC       Account  Privs Pri Directory

SAMBA$NMBD    SAMBA$NMBD      [360,2]      SYSUSR   All         4  SAMBA$ROOT:[USERS]

SAMBA$SMBD     SAMBA$SMBD      [360,1]      SYSUSR   All         4 SAMBA$ROOT:[USERS]


CIFSADMIN            CIFSADMIN           [360,5]      SYSUSR   All          4 SAMBA$ROOT:[USERS]

UAF>UAF> show/ident samba$guest ...

Name                          Value                       Attributes

SAMBA$GUEST       [000360,000003]

SAMBA$NMBD         [000360,000002]

 SAMBA$SMBD        [000360,000001]

 SAMBA$TMPLT       [000360,000004]

 CIFSADMIN               [000360,000005]


Do these "values"  constitute a match, or a mis-match ?


BTW,  the samba$root:[Users] directory is valid, but empty.


Also, Kerberos was newly installed and started with Role= No_KDC;

but I have no prior experience with it, so it may require adjustment.


Thanks in advance,






Honored Contributor

Re: Samba v1.2 NMBD crash

Here, I'd deinstall, clean up anything left over, and re-install with only the installation defaults selected.


For the recent open-source stuff, I'd only diverge from the installation defaults if there was a very specific reason, and then only with local testing.    The default installation is what sees the most testing.   This recommendation based on experience with attempts to diverge from both Samba and GNV environments.  Non-default installation settings can cause the packages to become unstable or unpredictable.


And though it is not likely the immediate trigger here, recognize that "HP reserves group 1 and groups 300--377 for its own use."  This per various of the OpenVMS manuals, including the security manual.


Given your lack of HP patch access, I'd also investigate either adding that access, or the commencement of discussions around a migration to a platform that can meet your cost and features requirements.  Whether that's a new OpenVMS I64 box with its initial support, or a ProLiant running, well, whatever, or something else.

Honored Contributor

Re: Samba v1.2 NMBD crash



if you carefully read the error message:


get_uai: The UIC value of the identifier system is not the same as UIC of the user account system


it may indicate, that there is some unexpected anomaly with your SYSTEM account and not the SAMBA accounts.

Please check UAF> SHOW SYSTEM for a correct identifier name (i.e. SYSTEM) for the UIC of the SYSTEM account.



Re: Samba v1.2 NMBD crash




Both of your remarks were correct and helpful.

The crash apparently occurs because the UIC of the SYSTEM account is [1,4] (per DEC default);

whereas the identifier SYSTEM is [000001,000003].  


The faulty identifier apparently arose because there are two other group 1 accounts with user

number 3, e.g. BKPSYS = [1,3].  Of course, this violates Hoff's noted "HP reserves group 1...." rule.


As a test, I tried a clean, "default" installation of Samba using BKPSYS [1,3], but this did not eliminate

the crash.  Apparently, Samba knows that SYSTEM is [1,4].


Unfortunately, the UAF file (and some accounts) have been continuous since about 1986, and

some software (e.g. Apache) was installed using the [1,3] system account.  That is, some software probably relies on the erroneous SYSTEM identifier, so changing it could be problematical.


I intend to update to VMS8.4, and I would probably re-start with a clean UAF and new software installs.

However, a newly-purchased 8.4 distribution kit would probably come without even the "critical" patches which already exist.  Here, I agree with Hoff's 2nd suggestion, that it's pretty difficult to proceed without patch support.

Deep down, I hope that HP will reverse it's patch support policy.


Hoff's 3rd suggestion, to bail out of VMS, has merit also.  I have 25 years of home-brew laboratory data acquisition software which relies heavily on VMS system services, so a port to Unix would be costly.

However, I notice that new VMS keyboards are almost unobtainable,  Radeon 7500s are selling for $1200,

and  the HP sales reps know nothing of VMS.  Perhaps HP is trying to tell us something.


But, thanks for your incisive technical advice.  Given a few re-installs, I suspect that I can get Samba

on stable VMS systems, even without updates.










Honored Contributor

Re: Samba v1.2 NMBD crash

If the SYSTEM user is [1,4], that's entirely as expected.  If something has altered the identifier for SYSTEM and has somehow changed the SYSTEM identifier to [1,3], that's unexpected.  Issuing:




(or something close to that) should sort out that SYSTEM identifier problem.  See the help text in AUTHORIZE for command details.  (What else that change might break that was erroneously expecting SYSTEM to be [1,3] or why this identifier was changed, I don't know.)


Now why Samba is even looking at any of this stuff and tossing diagnostics, I don't know.  It seems quite odd, though there's probably a reason for it.


If you do decide to upgrade to VMS V8.4, then VMS V8.4 should be patched to UPDATE V5, or potentially later.  (UPDATE V4 had 60-some fixes, and unfortunately also introduced a few bugs.)  If you're purchasing a new VMS license (for V8.4) or a new server with an OpenVMS license, it's typical to receive support for some specified interval.


And yes, porting application code with entrenched dependencies on or endemic usages of system services and other VMS features isn't going to be "fun".  In the least.  (But then neither is having a critical box tip over without some form of support; whether having the source code for whatever failed, or having some form of formal or paid support.)


Respected Contributor

Re: Samba v1.2 NMBD crash

You can also use an account other than SYSTEM to get around the problem.  


As for patches and ECOs, the CIFS patches are still available via FTP from:



Username: pathwork

Password: Support9


cd cifs-v12


Patch Set PS003 is the most recent.


If you're going to use Kerberos, be sure to get the latest (3.2?) kit from the OpenVMS Kerberos web site - there's a fix that is critical to CIFS (when configured with security=ads).


CIFS also uses the CRTL extensively and there have been many, many important CRTL fixes to address CIFS issues.   Most of these involve issues reading files with VFC record formats.    But the ACRTL ECOs are only available from the HP Support Center.  







Re: Samba v1.2 NMBD crash

Samba v1.2 now works fine on both IA64 and AXP with VMS8.3.


The core problem was that identifier [1,4] was associated with [SYSMGR,FIELD]

rather than with [SYSMGR,SYSTEM], both having UIC [1,4].  This was probably left over

from the cluster's VAXen days; and (per HP documentation) I have removed the FIELD account

and performed  UAF>Modify /ident  SYSTEM /value=uic:[1,4] .


So Volker, your incisive advice might be re-phrased as "carefully read the error message, at

least TWICE, once for each possible interpretation of the word SYSTEM."  


The existence of [SYSMGR,BKPSYS] account with UIC [1,3] may have been irrelevant.

I note that Hoff correctly quotes  the System Manager's Manual as "HP reserves UIC group 1 and

groups 300-377".  But I also note the Guide to System Security's example 6-1 for Administrator:

UAF> Add RIronwood /UIC=[001,100].  Nonetheless, I plan to remove [1,3], and "stick to the defaults"

wherever possible.


And Paul, thanks for the pointer to patch set PS003.