Print

Print


I want to tell you what RobtWahl <[log in to unmask]> said
about "Error 5/5, PMail for DOS v3.40" on 18 May 98, at 9:36
 
> We've been running Pegasus for DOS on a Novell Netware 4.10
> server for approximately a year with no problems.  Pegasus
> is strictly for internal mail and does not communicate outside
> of the in-house network.  Within the past two weeks, two users
> who were able to send mail suddenly cannot.  The error messages
> they receive are shown below.  Also, any new user added to the
> network gets the same error.
>
> The suggestions given in the error messages do not help:
>   - we do not use disk quotas
>   - we have plenty of HD space
>   - we are nowhere close to maxing out directory entries
>   - SYS:MAIL is set for CW
>   - BINDFIX doesn't apply to NW4.10 (?)
>   - we are not delivering across servers
>
> In the bottom left corner of the screen, both error messages say
> "Errors 5/5".  Any info on what the problem might be is greatly
> appreciated.
>
>
> Here are the error messages: [snipped for brevity]
 
A clue may lie in your use of NW4.10 -- make sure that a mail
directory actually exists for your users.  The SYS:MAIL
directory is not automatically generated when new users are
created -- it's a leftover from Bindery days.
 
If this is the case you have two options:  1) make your users
login using Bindery emulation (ie. "LOGIN /B bjonkman"), or 2)
 use the MAKEMBOX.EXE utility to create mail directories in
users' home directores in bulk, along with the PMUSER.NLM to
create these directories on the fly as new user IDs are
created.  Check out the documentation for these utilities
carefully -- you don't want to muck up your production
environment!
 
I don't know why mail delivery would spontaneously stop
working, though.  Using DSREPAIR will delete mailbox
directories for users that no longer exist, or people that log
into a different context (and server) will get a different
server context that doesn't contain their mail directories.
It could just be that a different server (in a different
context) is responding to the "Get Nearest Server" request,
and running a different container login script, and so not
making the right SYS:MAIL directory available.  I've seen this
happen in multi-server environments where container login
scripts are similar, but not identical.  A modification made
to one container login script but not to others can have
deleterious effects.
 
=====
Bob Jonkman                         SOBAC Microcomputer Services
4 Gold Pine Court                      mailto:[log in to unmask]
Brampton  ON  L6S 2K6  Canada                Voice: 905-793-4537
Networking   --   Office & Business Automation   --   Consulting
Key fingerprint: 9F AF A6 AC B5 67 BC 10 89 73 7C F0 CB 27 03 17
Key ID: AE33E989      mailto:[log in to unmask]