GroupWise 4.x 8200 Errors
(Last modified: 10Feb2003)
This document (10050656) is provided subject to the disclaimer at the end of this document.
goal
GroupWise 4.x 8200 Errors
This document addresses common causes and resolutions to many 8200-series errors in GroupWise.
fact
RDS #64
GroupWise 4.1
8200 Errors
Formerly TID 1202657
fix
Solutions for most "8200" Errors
Most "8200" errors can be solved by verifying network permissions or rights, checking file flags, using the OFCHECK utility, deleting bad
damaged Notify files, and/or verifying file ownership when using NetWare.
Network Permissions/Rights
Verify that the user has appropriate network rights according to what is listed in the GroupWise Administration Guide and the README.AD file. If
there are any doubts, temporarily grant supervisory rights to the user or Message Server that is having problems, or log in as supervisor and use
the /@u-userid on the command line to launch GroupWise; either one of theses is a good troubleshooting option.
File Flags
On a NetWare network, the contents of the OFMSG, OFNOTIFY, and OFUSER directories should be flagged as Shareable. Other networks may
need to emulate these settings. In some cases, flagging the contents of the OFDOS40 and/or the OFWIN40 and WPC20 directories has resolved
8201 errors, as well.
OFCHECK
Many "8200" errors are caused by damaged User or Message databases. Performing database maintenance at regular intervals with the
OFCHECK utility is the key to preventing these errors. Use of the High Performance Message Servers will also keep the majority of these errors
to a minimum as they have the ability to correct database errors on-the-fly. When running OFCHECK, set the options as follows:
1. Action: Analyze/Fix
2. Parameters: Structure including Index Check, Contents, and Fix Problems
3. Files: User/Msg Databases
4. Logging: Enable Verbose Logging if desired
5. Execution: Local
Error Descriptions and Possible Solutions
If the solutions listed above do not resolve the problem, check this section. Information about the error itself and any additional solutions, if
applicable, are given.
8200 Generic file I/O error
1. Situations in which a sender or the Message Server receives an "8200" error, but the message itself is delivered, are usually the result of
damaged Notify files. These files are monitored by the Notify program and contain a copy of some message information such as who sent the
message, what type of message it is, the priority level, and the subject line. The files are stored in the <post office>\OFNOTIFY directory and are
named NOTxxx.FIL, where xxx is the user's initials or FID as shown in the AD.EXE program. The recipient's notify file can be deleted and will be
regenerated when a new message is delivered to the user. If errors still occur after the notify file has been deleted, there may be a problem with
the recipient's USERxxx.DB. Run OFCHECK against the user and then delete the notify file again.
2. An 8200 (generic I/o) error displays when a user tries to accept appointments. After the error, the appointment is accepted. The user has a rule
that automatically accepts some appointments. The problem occurs only when the rule is disabled. When the rule is disabled, the error displays
when the user accepts the appointments the rule would normally affect.
3. When the problem was a result of database damage for specific user. To correct the problem, the user ran OFCHECK.
The probable cause of this database damage was an unstable network connection for that particular user. The user complained of being
intermittently dropped from the network. The subtle damage to the user's database(s) might have resulted from a bent cable, a failing NIC
(Network Information Card), an improper setting to the NET.CFG, etc., and the ultimate solution will lay in fixing the network connection so that it
is solid. When the message server polls any directory, it makes a simple request from the operation system. It asks for the first file in that
directory. The operating system yields up the file with the oldest creation date. This customer had some files in the <post
office>\WPCSOUT\OFS\4 directory that had a year-old creation date. To resolve this problem, the customer deleted files that had a date older
than those messages that seemed to be not going through. After deleting those files, the message server started again without any problems.
The user's rights to the WPMail volume had been limited to 3 Meg. When the user removed the restriction, the user could send mail messages to
users on other post offices. Renaming a user database should only be used as a troubleshooting option to narrow down the source of the
problem. If renaming a USERxxx.DB to USERxxx.OLD fixes a problem, rename USERxxx.OLD to USERxxx.DB and use OFCHECK to fix it.The
connection to the File server where the Post Office exists has been lost by the server running the NLM. Exit the OFS NLM and reload it.
8201 Access denied. Caller is not allowed access to a file.
Message: Access to a file has been denied (8201).
Conditions: Caller tried accessing/opening a file that did not have or allow sharing. Caller may also have tried to create a file that already exists.
Possible Solutions:
A tape backup system may be holding a message database open.
Attempting to attach a document that is still open in another application.
Use of the /d switch pointing to the root of a local drive that already had 492 of the 512 maximum files allowed in the root.
After the user marked the files USER.DB and MSG.DB shareable, this problem no longer occurred.
When pressing F7 to exit the DOS client. The Archive directory listed in Setup specified the correct directory; however, the user had only Read
and File Scan rights in that directory. After the user adjusted the rights in that directory, the error no longer occurred. To correct the problem, the
user made sure that all users were out of the system, and that the message server (if it existed) was down. Then the user brought down the
LANtastic server where the Office system resided. When the user then brought the LANtastic server back up, the administrator could
successfully run OFCHECK without errors. Also, logging out of the station being used may clear any files being held open. To correct the error,
the user added F (File Scan) rights to the OFUSER and OFMSG directories.
Delete the files in the \PO\OFNOTIFY directory and then send a message to all users.
Tape backup program may be holding a MSGxx.DB file open on the server and thus was Read-Only. To eliminate the error, the user had the tape
backup program release the .DB file.
The user did not have enough room in the Office 4.x archive directory to complete the conversion. Increasing the volume limit solved the problem.
Also, make sure the user has sufficient rights in the directory
The 8201 error also displayed when another user tried to convert archive mail from 3.1 to 4.0. The client specified an invalid path for the archive
directory in Location Of Files. Entering the 4.0 client and specifying a valid path for location of the archive directory corrected the problem. The
error occurred because there was no directory in which to place the converted files. The user did not have enough room in the Office 4.0x archive
directory to complete the conversion. Increasing the volume limit solved the problem. Also, make sure the user has sufficient rights in the
directory.
The 8201 error also displayed when another user tried to convert archive mail from 3.1 to 4.0. The client specified an invalid path for the archive
directory in Location Of Files. Entering the 4.0 client and specifying a valid path for location of the archive directory corrected the problem. The
error occurred because there was no directory in which to place the converted files. There are a few possible solutions to this problem:
Use a block size larger than 4K when configuring a volume over 2 gigabytes
Configure your server to include only volumes that do not exceed 2 gigabytes in size.
To avoid all questions of this nature, volume sizes should not exceed 1.3 gigabytes.
The user was attaching a file to the appointment that was still opened by another program. To eliminate the error, the user closed the file in
the other program, then Office could access the attachment to send it.
The /D switch was pointing to the root directory of the C: drive. There were 497 files there. That was the source of the problem.
How/Why:
There is a DOS limit of 512 files that can be created in the root directory of a physical hard disk. With the files created on startup and the file
created to read the messages, the customer was exceeding that limit. The client was running and accessing the archive on another machine.
The other client could be on another platform (i.e., DOS, Windows, MAC, or UNIX)The gateway must be started by a user that has permissions
equal to or greater than the account that starts SMTPRCV. To execute the gateway as a user other than root, do the following:
- Change to the <DOMAIN>/WPGATE/<SMTP> directory.
- Change the ownership of the SMTPRCV executable to a user other than root (WPOADMIN is used in this example). Type 'chown wpoadmin
smtprcv'.
- Set the uid or sticky bit for SMTPRCV. This is done by typing 'chmod 4110 smtprcv'. After changing the sticky bit, type 'Lan Server -al' to
verify your changes. You should see an entry for SMTPRCV that looks like this:
---s--x--- wpoadmin some_group file_size date smptrcv
Notice the "s" and wpoadmin. The "s" is the sticky bit and wpoadmin is the new owner. When Sendmail executes smtprcv, it will execute it
as the owner, in this case wpoadmin. Incoming SMTP messages will be placed in the receive directory with a wpoadmin ownership. It is
important that the Message Server is also executing as wpoadmin.
How/Why:
Sendmail normally executes its mailers (i.e., smtprcv) as the owner of sendmail. The sticky bit allows sendmail to execute smtprcv as a different
owner. This error message is built in to Office 4.0. The error can occur if the file does not have or allow sharing. The error can also occur if the
customer tries to create a file that already exists. To correct the problem, open the file with the correct sharing flags.
The WPDOMAIN.DB file, the MSGxx.DB file, or the WPHOST.DB file had a Novell file ownership of N/A. To correct the problem, the
administrators in each case changed the ownership of the database file to a valid Novell user through the Novell Filer program.
NOTE: Microsoft LAN Manager requires valid file ownership as well as NetWare. Have the Mac client user exit the program and rename the
GroupWise Preferences file in System Folder|Preferences|GroupWise. Or, in the case of the second user, remove the Stuffit SpaceSaver control
panel from the Control Panels folder inside the System Folder.
How/Why:
When GroupWise is launched with SpaceSaver loaded, a "Deny Write" status is placed on the WPHOST.DB file which prevents ADS from
updating the post office database.
There were files in the OFMSG and OFUSER directory without an owner. Assigning owners to those files fixed the problem. The typical answer
(run ADMSETUP from the post office directory) did not work in this case. The user had installed the domain under an APPS directory and the
post office under the Domain directory (F:\APPS\WPDOMAIN\POST1). The section in the OFWIN.INI file for the location of views was incorrect.
The user renamed the OFWIN.INI file and it still wrote the location incorrectly. The user had to change the location of views in the OFWIN.INI file
manually. In order to correct some 8204 errors given because of file not having a NetWare owner, he used a command that also inadvertently
flagged those same files as execute only (attribute shows as X). The OFS process was then unable to modify those databases.
How/Why:
He is unsure how the files were flagged as execute only. However, that is the only flag that cannot be removed. The files must be deleted and
restored, or recreated.
The sending user's message database on the target post office did not have sufficient file permissions. The message database is always
associated with the sender of the mail item. The administrator had run OFCHECK.EXE of the user in their own post office, but did not check the
message database on the target post office.
- The target message database is determined by running OFCHECK.EXE on the sender's database.
- The OFCHECK log file will display a DiskID, the disk id number is the user's message database number.
- Check the message database on the target post office with the information you got from the OFCHECK.EXE log files on the sender's post
office.
- Make sure the permissions give read and write access to the user, or run OFCHECK for a structural rebuild on the target message database.
Message server is running as a normal user. /ETC/INETD.CONF oftcprx is being launched as root. To solve the problem, We changed the user in
INETD.CONF to the message server user.
How/Why:
Since root was receiving files and putting them in the WPCSIN directory, the files were created with rights that the message server users could
not access.
Try doing a ScanDisk. There may be a problem with the hard drive, i.e., lost cluster(s), cross-links, etc.
8202 Bad file handle.
Message: WP Office is no longer able to access a required file. Please exit and then restart WP Office (8202).
Conditions: An invalid or old (that is, closed) file handle was passed to a file I/O function.
Solution:
Pass valid file handles to functions.
Check memory. Make sure that the correct amount of memory is available to run the application.
8203 Copy error.
Message: File copy error. Make sure you have access rights to the file or directory (8203).
Conditions: Errors occurring during an explicit file copy function will be returned as this error value.
Solutions:
Check user access rights to the file or directory;
Check the validity for the directory location.
8204 Disk full.
Message: Disk is full (8204).
Conditions: No space left on a disk when writing and/or creating a file or files have lost their owner assignment. This message can surface if a
user has a disk quota or volume space limit, or if a limit has been imposed on a particular directory on a volume.
Solutions: Create space on disk by deleting unwanted files or assign an owner to the file. On intraNetWare or its predecessors, directory size
limits can be checked in NWADMIN.EXE by double-clicking a volume object, right clicking a directory for the details, clicking the Facts tab and
looking at the "Restrict size" check box.
On NetWare networks, an "8204" error is often the result of database files that do not have valid NetWare owners assigned to them. When a
database needs to increase in size to hold new messages, GroupWise requests the necessary space from NetWare. So long as the owner of the
file is a valid user, and the user has not exceeded any Volume Restrictions that may be in place, the request is granted. If these conditions are
not met, NetWare returns a "Disk Full" error which GroupWise translates as error "8204." Files lose their owner when the owner is deleted from
NetWare.
Check the OFMSG, OFUSER, and OFNOTIFY directories with the NDIR command for files that list the owner as "N/A" or "No Owner." It's also a
good idea to examine the domain and post office directories for such files. To find files without owners in the current directory, type:
NDIR /OW LE *
To search the current directory its subdirectories, use:
NDIR /OW LE * /SUB
Once the files without owners are identified, use NetWare's Filer utility to assign a valid owner to them.
Make sure the network login ID has sufficient Server and Volume rights.
8205 End of file.
Conditions: End of the file has been encountered during a read operation.
Possible Solution:
Check for and delete 0-byte files in any of the post office subdirectories, especially the <post office>\OFWORK\OFPEND directory.
8206 Error opening file.
Message: Error opening file (8206).
Conditions: During an explicit file copy function, failure to create the destination file will generate this error.
Possible Solutions:
If using Software Management to copy the client software to a post office, make sure that all users have exited GroupWise
If while executing the Windows client, the user's private BIF file may be open on the network.
8207 File seek error.
Message: Generic error message #5.
Conditions: During an explicit file copy function, failures that occur when positioning file pointers will generate this error.
Solutions:
Check user access rights to the file or directory.
If a task activator is line in the NET.CFG file of a user who was not getting the error. When the customer added this line to the Net Config
file for users with the problem, the error no longer displayed.
8208 File modify error.
Message: File modify error. An error occurred when renaming or moving a file to another location (8208).
Conditions: An error occurred when renaming or moving a file to another location (name).
Possible Solutions:
- Check the directory rights of the directory where the modified file exists.
- Try the /D-C:\<directory path> to a valid directory.
8209 Path not found.
Message: The path to the specified file is invalid or the file does not exist. Specify a valid path and file name (8209).
Conditions: Path to a file is invalid or file does not exist when trying to open a file.
Possible Solutions:
Will happen if during Proxy, a user attempts to print without having Write permission
If it occurs when archiving messages, either manually or upon exiting, check that a valid Archive directory is specified in Preferences.
Attempting to change the Archive directory in Preferences of the Windows client (WordPerfect Office 4.0 and 4.0a versions) from a directory
that nothing has been archived to yet, to another directory will generate the error.
Starting the Remote client without a /PS switch, or with the switch pointing to something other than the ROFDATA directory.
Will happen if directories are missing from the post office directory structure. Look in the GroupWise Administration Guide Index under
"Directory structure" for a diagram.
Verify that drive letters are not map rooted to the post office directory.
Users who get error 8209 when clicking on the read mail message, try doing a 'Structural Rebuild' on the User and MSG databases.
820A Too many files open.
Message: Unable to open additional files (820A).
Conditions: All available file handles have been used. The operating system has no more file handles to give to the caller.
Possible Solution:
Configure the operating system to allocate more file handles and/or close files that do not need to be opened.
820B Path too long.
Message: Generic error message #5.
Conditions: File system cannot build or modify a path due to a passed path that is too long.
Possible Solutions:
Change the path name to valid length (include space for a filename if applicable).
820C No more files in directory.
Conditions: The directory being searched has been exhausted of file names.
Solutions: None; this is an informational message.
Possible Solutions:
Check for sufficient rights in the working directory or directory specified with the /d switch.
820D File size is too large.
Message: Generic error message #5.
Conditions: When truncating a file, the passed size of the file is greater than the actual size of the file.
Solutions: None; this is an informational message.
820E File lock error.
Message: Generic error message #5.
Conditions: Attempt to lock a file has failed. File is probably locked by another user or caller who does not have proper access rights to the file.
Possible Solutions:
On LANtastic, verify that SHARE.EXE is loaded on the server.
If the user was running the Performance pack (beta) for OS/2:
- Once the Performance pack was disabled, the 820E errors were eliminated.
Errors with OS/2 2.11/Warp 3.0 various file locking problems can occur in the administration, client, and DOS Message Server programs. The
AD.EXE program may give file lock errors when trying to update the domain database, WPDOMAIN.DB. GroupWise client software may display
820E errors when sending or deleting mail.
Patches are available from IBM for both OS/2 2.11 (named Fixpack 80) and for Warp 3.0. The APAR number referenced by IBM for Warp is
PJ16094. Additionally, the GroupWise 4.1a Windows client addresses the 820E errors.
If the customer was currently being proxied by another user:
- The other person was using the DOS client in the Windows environment (with a .PIF file). The user had minimized the DOS client while it was
in the process of completing a reply to a message for the person being proxied. As soon as the user closed the DOS client session in Windows,
the 820E error no longer occurred. By having the DOS session minimized in Windows, the reply was running very slowly and locking out the main
user.
If the error occurs while trying to send an item, attribing the user's Notify file as Sharable may correct the problem.
If running the SMTP gateway, loaded Share before the SMTP Gateway.
820F File unlock error.
Message: Generic error message #5.
Conditions: Attempt to unlock a file has failed.
8210 Path create failed.
Message: Generic error message #5.
Conditions: Attempt by the file system to create a unique file failed.
Possible Solutions:
With the NLM Message Server, implement the /USER and /PASSWORD switches if they are not being used
Will happen if a user sends a Delayed Delivery message when a Message Server is not present.
Check for sufficient file handles if this happens on a particular work station.
In one instance, a driver for a PCMCIA hard drive caused the error. The driver ATADRIVE.DRV was causing an invalid file creation error to
occur when the attachment was created.
Will happen if directories are missing from the post office directory structure. Look in the GroupWise Administration Guide Index under
"Directory structure" for a diagram.
If the error 8210 occurs when an Office 4.0a user sends a message to the group ALL (containing approximately 50 users):
- Increase the rights' in the <post office>\OFNOTIFY directory. The rights should be RWCF, not RWCE.
If the error 8210 occurred when sending a message:
- with an attachment of any type or size. The customer did not have the FDO through FDF subdirectories beneath the OFFILES subdirectory of
the post office. After manually creating these 16 subdirectories, everything worked fine. The post office had been moved to a different location on
the server, probably with the DOS XCOPY command and the /S switch. This command will copy all files and directories except empty ones. If the
XCOPY command is used with the /E switch, all files and directories (including empty ones) will be copied. If the 'rights' seem ok, but files cannot
be created in the OFFILES directory structure, BINDFIX or DSREPAIR may need to be run.
- The users had insufficient rights in the WPCSIN directory.
- The MSG.DB file did not have an owner.
- Running OFCHECK DOSMENU individually for each of the Mac users and choosing Recreate USER.DB from the message database (DB)
fixed the problem. OFCHECK Analyze and Fix as well as Structural Rebuild did not have any effect on the damaged databases.
- Add the File Scan' right (F) to the <post office>\OFUSER directory.
8211 File rename failed.
Message: Generic error message #5.
Conditions: Failure by the file system to rename a file with a unique file name.
Solutions: Check if new name passed to rename function already exists on disk.
Possible Solutions:
Check for and delete 0-byte files in the post office subdirectories.
Give each user full rights to all subdirectories off the Post Office directory, the users did not receive the error and could successfully enter
Office. If users do not have sufficient rights, the error will occur in both Office for DOS and Office for Windows.
Another customer was getting the error message "File Rename Failed" when trying to send a mail message. This problem was solved by
granting full rights in the OFS directories.
Make sure that all the user and message databases have owners. NDIR of the OFUSER and OFMSG directories. The customer found
several files without an owner (listed as N/A or Unknown). The customer renamed the files and then copied them back with their original names.
This gave the files an owner and corrected the "Error 8204 (Disk Full)" error when sending mail messages.
Delete the WPCSOUT\OFS\4 directory and recreate it to correct the problem. (This is for Normal' priority items. For other priorities the 2 or
6 directories may have be deleted then recreated.)
8212 Invalid file password.
Message: Generic error message #5.
Conditions: The password stored in an encrypted file does not match the password supplied by the caller when opening the file.
Possible Solutions:
In one instance, the error was being generated when attempting to archive a damaged message. Use OFCHECK /PS-<drive:\directory path>
to the OFxxxARC directory.
8213 Invalid file operation.
Message: Generic error message #5.
Conditions: An illegal file operation on an encrypted file was requested.
8214 Unsupported encryption level in file.
Message: Generic error message #5.
Conditions: The file to be decrypted was encrypted with an encryption level that is no longer supported.
8215 Currently positioned at the path root level.
Conditions: Repeated calls to the path reduction function will eventually return this value when the path has been reduced to the root level.
Solutions: None; this is an informational message.
8216 Encryption/decryption error.
Message: Generic error message #5.
Conditions: An error occurred when encrypting or decrypting the contents of a file..
document
| Document Title: | GroupWise 4.x 8200 Errors |
| Document ID: | 10050656 |
| Solution ID: | NOVL1980 |
| Creation Date: | 21Mar2000 |
| Modified Date: | 10Feb2003 |
| Novell Product Class: | Groupware |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.