|
HP OpenVMS Systems |
|
HP Advanced Server V7.3B for OpenVMS
|
| Previous | Contents | Index |
Problem:
The server might crash with an access violation (ACCVIO) in module ODS2$FIDCACHE, routine FIDGetCache. A traceback similar to the following would be seen in the PWRK$LMSRV log file:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000010 %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine line rel PC PWRK$FSLIB_ODS2 ODS2$FIDCACHE FIDGetCache 32276 ...01C94 PWRK$FSLIB_ODS2 ODS2$FIDCACHE ODS2GetFIDCache 33962 ...06714 PWRK$FSLIB_ODS2 ODS2$FILE ODS2LookupFile 30532 ...00DC8 PWRK$FSLIB_ODS2 ODS2$FILELIB ODS2GetDirectory 27678 ...00AF4 PWRK$FSLIB_ODS2 ODS2$FILE ODS2LookupPath 30408 ...00AB0 PWRK$FSLIB_ODS2 ODS2$FILE ODS2LookupFile 30506 ...00D2C PWRK$FSLIB_ODS2 ODS2$LIB ODS2Stat 34009 ...02AEC |
In addition, the log file would contain many informational messages from the FID cache and ThreadLock/Unlock routines.
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS. The crash and the extraneous
informational messages should no longer occur.
4.1.31 SAM Database Becomes Corrupted After Shutdown
Problem:
If the server shuts down while updates to the SAM database are in progress, the SAM database might become corrupted, especially when update activity is high, such as during a full replication or when using scripts to add or remove a large number of users.
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS. Various ECOs, patch kits,
and recommendations for earlier releases of the Advanced Server,
provided a fix for this problem that interlocked the PWRK$SHUTDOWN.COM
procedure with stopping the NetLogon service. The new fix provided with
the Advanced Server V7.3 for OpenVMS does not include the interlocking of NetLogon in
PWRK$SHUTDOWN.COM. It is no longer necessary to interlock stopping the
NetLogon Service with PWRK$SHUTDOWN.COM. Any such customized changes
can be removed.
4.1.32 SAM Corruption Issues Addressed
Problem:
Previously, it was possible for the SAM database to become corrupt. The causes were many and various, but always resulted in similar symptoms, which included the following:
image module routine . . . rel PC abs PC
PWRK$LMRPCAPISHR SERTL RtlLengthSecurityDescriptor
. . . 0000000000000BD8 0000000000730978
PWRK$LMSRV SECDESCR PegSamrSetSecurityObject
. . . 0000000000001904 00000000001FDF24
PWRK$LMSRV SAMRPC SamrSetSecurityObject
. . . 00000000000000F8 00000000000D9AD8
.
.
.
|
$ SAMCHECK -s No corruption was detected in the SAM database. |
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS. Note that it is still
possible for SAM corruption to occur. The most common cause is
improperly shutting down the Advanced Server. To avoid SAM corruption,
always use the SYS$STARTUP:PWRK$SHUTDOWN.COM shutdown procedure
whenever stopping the Advanced Server and also prior to shutting down
the OpenVMS system.
4.1.33 PWRK$LMSRV Crashes in Module PFS$OPS, Routine PFS_setextattr
Problem:
Under some circumstances, when the file server is attempting to create ACEs (access control entries) for a file or directory, the server crashes due to an ACCVIO in the PFS$OPS module, routine PFS_setextattr. A traceback similar to the following would be seen in the PWRK$LMSRV log file:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=000000000000
0003, PC=0000000000438EE8, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine . . . rel PC abs PC
PWRK$CSSHR_V7 PFS$OPS PFS_setextattr
0000000000011708 0000000000438EE8
PWRK$CSSHR_V7 PFS$OPS PFS_copyfile 00000000000044C8 000000000042BCA8
PWRK$LMSRV MVCP treecopy 0000000000000624 000000000012E8B4
.
.
.
|
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
4.1.34 BDC Servers Experience High CPU Utilization and Replication Traffic, or ADMINISTER Commands Fail with "RPC Server Is Unavailable" Errors
Problem:
One or both of two problems might occur:
-LM-E-RPC_S_SERVER_UN, The RPC server is unavailable |
Solution:
These problems are resolved in Advanced Server V7.3 for OpenVMS.
4.1.35 Server Crashes with Access Violation in DirRecycleDirectory
Problem:
The file server might crash due to an ACCVIO while a directory is being accessed by more than one client. For example, it might crash in the DIRRecycleDirectory routine of the ODS2$DIRCACHE module. A traceback similar to the following would be seen in the PWRK$LMSRV log file:
image module routine . . . rel PC abs PC
PWRK$FSLIB_ODS2 ODS2$DIRCACHE DIRRecycleDirectory
0000000000002928 000000000A9A9F8
PWRK$FSLIB_ODS2 ODS2$DIRCACHE DIRMaintenance
0000000000003F40 0000000000A9C010
.
.
.
|
In addition, one or more "dce on purgatory queue without bit lit" messages might be logged in the PWRK$LMSRV log file.
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
4.1.36 Server Crashes in ODS2NewASUSecurityAce
Problem:
The server might crash due to an ACCVIO in module ODS2$LIB, in routine ODS2NewASUSecurityAce. A traceback similar to the following would be seen in the PWRK$LMSRV log file:
image module routine . . . rel PC abs PC
PWRK$FSLIB_ODS2 ODS2$LIB ODS2NewASUSecurityAce
00000000000026AC 0000000000A0AF7C
PWRK$FSLIB_ODS2 ODS2$LIB ODS2SetASUSecurity
000000000000294C 0000000000A0B21C
.
.
.
|
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
4.1.37 "release_secure_channel_lock failed" Error Occurs, with Replication Failure
Problem:
The following error message is recorded in the PWRK$LMSRV log file:
release_secure_channel_lock failed , R0 status 00002124 |
This error typically occurs during replication of the SAM databases and is followed by SAM database replication failures.
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
4.1.38 PWRK$LMSRV Process crash in RPCBIND/rpc__binding_free
Problem:
The PWRK$LMSRV process might crash in image PWRK$LMRPCSHR with a process traceback that shows an ACCVIO in RPCBIND/rpc__binding_free, called from CNSRV AbortAssociation, following a series of IPC error messages regarding a full or closing pipe such as:
IPCerr\RPC-56B8\CLOSE.3129 :#373717 [invalid pipe end) failure writing EOF Status = 2264 (0x8D8), %SYSTEM-W-MBFULL, mailbox is full IPCerr\RPC-56B8\freepd.3332 can't free write IOSB 0x081CCC18 IPCerr\RPC-3778\SEND.2320 }#2929674 [invalid pipe end) sendmsg error |
These error messages might also be seen without a corresponding PWRK$LMSRV crash.
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
4.1.39 PWRK$LMSRV Crashes with "Buffer Insane" Messages
Problem:
The PWRK$LMSRV process might crash with error messages similar to the following in the PWRK$LMSRV log file:
14-JUL-2000 10:11:59.38 20200268:03B55A40 Data in buffer insane! PANIC: aborting from module AS$BLD_ROOT:[AS.UTIL.SRC]GC.C;1 at line 437! |
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
4.1.40 Interdomain Trust Stops Working
Problem:
In earlier releases of the Advanced Server, secure channels for interdomain trust relationships would stop functioning during periods of heavy channel traffic. In addition, during server startup, if no domain controllers were available on the trusted side of the channel, the communication channel would not be initialized, and the trusts would not work as expected.
Solution:
These problems are resolved in Advanced Server V7.3 for OpenVMS. When a channel stops
functioning because of heavy traffic, the server software will reopen
the communication channel. When a channel does not get initialized
because domain controllers in the trusted domain are not available, the
server software will initialize the channel when the domain controllers
become available.
4.1.41 PWRK$LMSRV Crashes in Routine ssignon_gethostmap
Problem:
When using external authentication with the Advanced Server, the PWRK$LMSRV.EXE crashes. A traceback similar to the following would be seen in the PWRK$LMSRV log file:
image module routine line abs PC
PWRK$LMSRV SSIGNON_PROC ssignon_gethostmap
88482 0000000000000984
PWRK$LMSRV SSIGNON_PROC process_acme_message
88828 00000000000019DC
PWRK$LMSRV SSIGNON_COM receive_comp_handler
23651 0000000000000A58
PWRK$LMSRV SSIGNON_COM ssignon_work 24150 0000000000001828
.
.
.
|
Solution:
These problems are resolved in Advanced Server V7.3 for OpenVMS.
4.1.42 PWRK$LMSRV Process Crashes in Routine CheckMsgAuthenticator
Problem:
The server might crash with an ACCVIO in routine CheckMsgAuthenticator. A traceback similar to the following would be seen in the PWRK$LMSRV log file:
image module routine line . . . abs PC
PWRK$LMSRV SSIGNON_PROC CheckMsgAuthenticator
108897 0000000000004698
PWRK$LMSRV SSIGNON_PROC process_acme_message
106887 0000000000001490
PWRK$LMSRV SSIGNON_COM receive_comp_handler
23651 0000000000000A58
PWRK$LMSRV SSIGNON_COM ssignon_work 24150 0000000000001828
.
.
.
|
Solution:
These problems are resolved in Advanced Server V7.3 for OpenVMS.
4.2 File Access/Printing Problems
This section describes file access and printing problems corrected in
Advanced Server V7.3 for OpenVMS.
4.2.1 Files Inherit Wrong or Inappropriate ACEs
Problem:
When creating a subdirectory, OpenVMS copies both the parent directory's access control permissions (A) and inheritable permissions (B) correctly. However, when creating a nondirectory file, OpenVMS also copies the parent directory's access permissions (A) (along with its inheritable permissions (B)) to the new file. Hence, the parent's directory access control permissions (A) are erroneously interpreted as the new file's access control permissions. The correct behavior is to have the parent's inheritable permissions interpreted as the file's access control permissions.
For an overview on file security information and the handling of directory permissions and ACEs by the Advanced Server, OpenVMS, and Windows NT systems, refer to the HP Advanced Server for OpenVMS Server Administrator's Guide.
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS. Directory access control permissions (A) are no longer propagated to the created file's access control permissions. In the case of files created by the Advanced Server, only the parent directory's inheritable permissions (B) are propagated as the file's access control permissions.
In the case of files created by other OpenVMS applications, neither the parent directory's inheritable permissions nor its access control permissions are propagated to the file. Instead, the parent's inheritable permissions are propagated to the file at the time the file is accessed by the Advanced Server.
Furthermore, when the Advanced Server accesses a file with access permissions wrongly propagated from the parent directory, the server ignores those access permissions. Instead, the server interprets the proper access permissions --- those that were propagated to the file as inheritable permissions. These permissions become the file's access control permissions.
To fix existing ACEs that have incorrect security information, use the
utility PWRK$FIXACE.EXE. To delete ACEs, you can use the PWRK$DELETEACE
utility. For more information, refer to the HP Advanced Server for OpenVMS Server Administrator's Guide.
4.2.2 Cannot Create File on Disk Because of Insufficient Space for Index Header Blocks
Problem:
An attempt to create a new file in a shared directory can fail because not enough index header blocks are available to store "PATHWORKS" ACEs. Disk space on the disk volume appears sufficient for creating the file, but the file creation fails because the disk volume's index file is full. This problem can be exacerbated by the OpenVMS-related problem reported in Section 4.2.1, Files Inherit Wrong or Inappropriate ACEs. For example, when directory-specific and inherit-only ACEs are propagated inappropriately to a new file's descriptor, these ACEs consume more index blocks and disk space.
Solution:
While attempts to create shared files on disk volumes that have
insufficient space for creating index header blocks will still fail,
the fixes reported in Section 4.2.1, Files Inherit Wrong or Inappropriate ACEs, significantly reduce the frequency
and likelihood of such failures in Advanced Server V7.3 for OpenVMS.
4.2.3 Creators of Files in Shared Directories Do Not Inherit Ownership and Might Lose Access to the Created File
Problem:
Ownership of a file created by the Advanced Server was set to the parent directory's owner instead of the file's creator. This is caused when the Advanced Server requests that OpenVMS propagate the parent directory's ownership and other security information to the created file.
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS. Advanced Server file servers
no longer rely on OpenVMS for propagating ownership information to
newly created files. The file server always writes explicit ownership
information for a new file (or directory) at creation, so that the file
creator is guaranteed ownership.
4.2.4 File Name Prompt Does Not Appear When Printing to a Windows NT Shared Printer That Is Set to Print to Port FILE:
Problem:
When printing to a print share that is set up on a Windows NT print server that has "FILE:" enabled as the printer port (the FILE: property is located under the Ports tab for the printer's properties), the file server does not always prompt for a file name, as it should.
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
4.2.5 Attempts to Copy a Read-Only File onto an Existing Shared File Results in "Access Denied" Error
Problem:
In versions of the Advanced Server prior to V7.3, an attempt to copy a read-only file onto a share to replace an existing file that is not read-only produces the following results:
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS. The file is copied
correctly. To maintain compatibility with Microsoft operating systems,
the read-only attribute is not applied to the resulting file.
4.2.6 Users with Logons Restricted to One Workstation Cannot Print to Shared Printers on Other Workstations
Problem:
If a user is restricted to logon to a domain from only one workstation, the user cannot print to a shared printer on another workstation.
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
4.2.7 Unlocked User Account Denied Access, Event 1909 Logged: "Account Locked Out"
Problem:
After a user account has been locked out and then is unlocked again (for example, when the account lockout duration is exceeded or the system administrator manually unlocks the account), the user should once again be allowed to log on to the domain in question. However, the user might be denied access, with event log message 1909 stating that the account is locked out.
This problem occurs when the Advanced Server is a backup domain controller (BDC) and is unable to detect that the account had been unlocked again. After the account was unlocked, if a partial synchronization occurs, but not a full synchronization, the Advanced Server still does not receive the status change information as it should. The problem is resolved after a full synchronization.
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
4.2.8 "Access Denied" Error Messages Received Sporadically
Problem:
When clients attempt to access Advanced Server resources, they might sporadically receive "Access Denied" errors, but still acquire access. In certain circumstances, the "Access Denied" errors could also result in the Advanced Server stalling. For example, an excessive number of "Access Denied" errors occur, and the Alerter service is unable to send alert messages to one or more alert recipients (user accounts listed by the AlertNames parameter), causing the Advanced Server to stall.
Solution:
This problem of receiving sporadic "Access Denied" messages
is resolved in Advanced Server V7.3 for OpenVMS. To avoid the problem of the Advanced Server
stalling because of the Alerter service, keep the number of user
accounts receiving alerts to a minimum, and make sure that those user
accounts that should receive alerts are always logged onto the domain.
4.2.9 Clients Cannot Access Files with Long File Names Containing Multiple Periods
Problem:
Certain files on ODS-2 disk volumes are not accessible by clients on an Advanced Server V7.2 for OpenVMS server if these files were created on a PATHWORKS V6 server and have long file names containing multiple periods. On ODS-2 volumes, file names are restricted to 39 characters in the file name and 39 in the extension. The Advanced Server V7.2 for OpenVMS incorrectly changed the way it encodes file names. The Advanced Server V7.3 for OpenVMS now encodes file names the same way that PATHWORKS V6 servers do.
Solution:
This problem is addressed in Advanced Server V7.3 for OpenVMS. The PWRENAME utility was
made available to rename such files to make them accessible by Advanced
Server V7.2 for OpenVMS clients, as described in Section 3.26, File Renaming Utility for Long File Names with Multiple Periods.
(Because the Advanced Server V7.3 for OpenVMS encodes file names in the same way as does
PATHWORKS V6 servers, V7.3 server clients can access the files with no
problem.) Note that you can also solve this problem by converting your
disk to ODS-5 (for instructions, refer to the HP Advanced Server for OpenVMS Server Administrator's Guide).
4.2.10 Certain Applications Might Fail When Attempting to Display Files on ODS-5 Disk Volumes
Problem:
Certain MS-DOS applications attempting to enumerate files in an Advanced Server share directory residing on an ODS-5 volume will fail if the file names are in lowercase. These same applications work fine on an ODS-2 volume.
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
4.2.11 Directory Might Appear Empty Even When It Is Not
Problem:
When a client attempts to display the contents of a directory that contains a file with no file name and extension, such as ".;1", the directory will appear empty although it does contain files.
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
4.3 ADMINISTER Command Problems
This section describes ADMINISTER command problems corrected in
Advanced Server V7.3 for OpenVMS.
4.3.1 REMOVE SHARE Command Fails with Share Name That Has Trailing Spaces
Problem:
Attempts to remove a share whose name has one or more trailing spaces fail. For example, a user adds a share, specifying a space as the last character of the share name, such as in the following example:
LANDOFOZ\\TINMAN> ADD SHARE "TORNADO " USER1:[TORNADO_FILES] |
Attempts to remove that share fail with either of the following commands:
REMOVE SHARE "TORNADO " REMOVE SHARE TORNADO |
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
4.3.2 OpenVMS Users Not Logged on to the Network Cannot Use the ADMINISTER SEND Command
Problem:
The SEND command should not require network logon if specified in the following format, without qualifiers (one exception is the /SERVER=server-name qualifier, if server-name is the local server):
SEND computer-name message |
However, attempts to use the SEND command in this way without network logon produce the following message:
%PWRK-E-LOGONREQUIRED, you must be logged on to perform the requested operation |
Solution:
This problem is resolved in Advanced Server V7.3 for OpenVMS.
| Previous | Next | Contents | Index |