GW8 POA Repairs Database every time it starts

Question

I have Groupwise 8 (fully patched) running on a Netware 6.5 server (fully patched). Every time the POA restarts at midnight, it checks the Guardian database. Then at 26 seconds past midnight, it gives me a data base repaired message.
When I attempt to do an analyze/fix using the standalone GWCHECK, I get an 8201 on Guardian. Here is the exact error:
STRUCTURAL VERIFICATION of system databases
STRUCTURAL VERIFICATION of database ngwguard.db
- Error checking file Guardian, IO_ACCESS_DENIED (0x8201)
- Guardian was successfully recovered from backup
This process takes 1 1/2 hours to recover the database. I abort the process as soon as I get the 8201, but it takes 1 hours to stop.
I do know some things which are incorrect. My ngwguard.fbk is dated some time in 2004. My ngwguard.rfl is 24 meg. And my GUARDBAK ngwguard.fbk is also 2004. I know these things are wrong. When I investigated the 8201 error, it indicated that it could be because the owner does not exist. Well, that was true. The owner of some of my files was .[supervisor], this system is very old & has been updated thru many versions of netware & groupwise. I changed everything to .admin from .[supervisor] across the entire mail volume. I was hoping that this would solve the problem, but it does not. Something is still putting out messages owned by .[supervisor]. I have recently upgraded all of my nlm's to be owned by .admin as well as the groupwise software directory & the public directory. And yet, the new messages are arriving owned by .[supervisor].
I am not sure what the sequence of events is in GWCHECK. So, I am not sure where the analyze/fix is getting an error or what is causing the error. I see no other errors other than the one above.
I have several other NGWGUARD files which I am not sure of their usage. Following is a copy of the directory.
11/22/2003 03:45 PM <DIR> .
11/22/2003 03:45 PM <DIR> ..
04/13/2013 10:57 PM 1,798 0413CHK.LOG
04/14/2013 06:55 AM 1,020 0414CHK.LOG
04/15/2013 03:43 PM 766 0415chk.log
12/17/2008 02:46 AM 6,108 1130CHK.LOG
04/13/2013 03:02 AM 71,680 dmdd0108.db
04/13/2013 03:02 AM 38,912 dmdd0208.db
04/13/2013 03:02 AM 38,912 dmdd0308.db
04/13/2013 03:02 AM 77,824 dmdd0408.db
04/13/2013 03:02 AM 43,008 dmdd0508.db
04/13/2013 03:02 AM 45,056 dmdd0608.db
04/13/2013 03:02 AM 32,768 dmdl0108.db
04/13/2013 03:02 AM 32,768 dmdl0208.db
04/13/2013 03:02 AM 32,768 dmdl0308.db
04/13/2013 03:02 AM 36,864 dmdl0408.db
04/13/2013 03:02 AM 32,768 dmdl0508.db
04/13/2013 03:02 AM 38,912 dmdl0608.db
04/13/2013 09:58 PM 28,672 DMSD0008.DB
04/13/2013 03:00 AM 225,280 guard.DB
08/20/2005 07:18 PM 18,001 GWPO.BAK
03/23/2009 10:30 AM 19,122 gwpo.dc
03/21/1998 12:36 PM 15,828 Gwpo.dco
04/15/2013 04:03 PM 90,112 ngwcheck.db
01/31/2012 02:19 AM 86,016 NGWCHECK.old
03/08/2008 09:03 PM 113,209 NGWGUARD.BAK
04/15/2013 03:54 PM 225,280 ngwguard.db
04/15/2013 03:53 PM 225,280 NGWGUARD.DBA
04/04/2009 02:30 AM 102,648 ngwguard.dc
03/15/1998 06:22 AM 68,126 Ngwguard.dco
03/13/2004 09:00 PM 159,744 NGWGUARD.fbk
04/15/2013 03:53 PM 225,280 NGWGUARD.FBN
01/01/2004 10:00 AM 159,744 NGWGUARD.FBO
01/31/2012 07:45 AM 225,280 NGWGUARD.new
04/15/2013 03:53 PM 25,661,085 NGWGUARD.RFL
04/15/2013 03:53 PM 290,816 wphost.db
08/18/2004 10:23 PM 231,424 wphost.dbold
03/08/2008 09:03 PM 10,942 wphost.dc
As you can see. I have a .FBN & a .FBO file. The .FBN seems to be used during the GWCHECK.
Following is a copy of the flag for this volume:
Files DOS Attr NetWare Attr Status Owner Mode
0413CHK.LOG [Rw---A] [-----------------] .Admin.tci N/A
0414CHK.LOG [Rw---A] [-----------------] .Admin.tci N/A
0415CHK.LOG [Rw---A] [-----------------] .Maureen.tci N/A
1130CHK.LOG [Rw----] [--P--Di----Dc----] .Admin.tci N/A
DMDD0108.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDD0208.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDD0308.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDD0408.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDD0508.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDD0608.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDL0108.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDL0208.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDL0308.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDL0408.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDL0508.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDL0608.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMSD0008.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
GUARD.DB [Rw---A] [--P--Di----Dc----] .Admin.tci N/A
GWPO.BAK [Rw----] [--P--Di----Dc----] .Admin.tci N/A
GWPO.DC [Rw----] [-----------------] .Admin.tci N/A
GWPO.DCO [Ro----] [--P--Di--RiDc----] .Admin.tci N/A
NGWCHECK.DB [Rw---A] [-----------------] .Admin.tci N/A
NGWCHECK.OLD [Rw---A] [--P--Di----Dc--Ds] .Admin.tci N/A
NGWGUARD.BAK [Rw----] [-----------Dc----] .Admin.tci N/A
NGWGUARD.DB [Rw---A] [-----------------] .Admin.tci N/A
NGWGUARD.DBA [Rw---A] [--P--Di----Dc----] .Admin.tci N/A
NGWGUARD.DC [Rw----] [-----------------] .Admin.tci N/A
NGWGUARD.DCO [Ro----] [--P--Di--RiDc----] .Admin.tci N/A
NGWGUARD.FBK [Rw----] [-----------------] .Admin.tci N/A
NGWGUARD.FBN [Rw---A] [-----------------] .Admin.tci N/A
NGWGUARD.FBO [Rw----] [--P--Di----Dc----] .Admin.tci N/A
NGWGUARD.NEW [Rw----] [-----------------] .Admin.tci N/A
NGWGUARD.RFL [Rw---A] [--P--Di----Dc----] .Admin.tci N/A
WPHOST.DB [Rw---A] [-----------------] .Admin.tci N/A
WPHOST~1.DBO [Rw----] [--P--Di----Dc----] .Admin.tci N/A
WPHOST.DC [Rw----] [-----------------] .Admin.tci N/A
I dont know if the ownership by TCI_COMM.tci (server name) is causing the problem or not. So, I changed the ownership to .admin.tci & I ran another GWCHECK. Still an 8201 error as above. So, it did not help. The files owned by Maureen.tci are a result of the GWCHECK.
Any help would be greatly appreciated. I am attempting to solve these problems in anticipation of moving to a windows server.

Answer 1

Yes. I am looking at 4 files only. This may be a mistake. But it is all that I can glean thru TIDS, Forums, White papers etc.
NGWGUARD.DB - was open by no one. Now it is open by connection 0 which is the server & it isn't locked. But when I did your test, no one had it open. My Virus protecion is set not to scan DB files.
NGWGUARD.FBK - not opened.
NGWGUARD.RFL - not opened
NGWCHECK.DB - not opened
What I really need to know is what file is GWCHECK complaining about. It just says Guardian. This isn't helpful. I interpret Guardian to be NGWGUARD.DB. This file is being updated every day. My gut says this is the .FBK which is a problem or the backup FBK on GUARDBAK. This is the file which is not being updated. The FBK should have the DB at its last known 'safe' state. I would assume that this means that it should have a date of this morning at midnight. Other mail systems have both the .DB and .FBK set to midnight of the same day. The RFL is being updated on my system. I can't find any documentation on what the GWCHECK process is. The error occurs immediately. If I were doing the structural analyze/fix, I would try to create a new FBK file (this may be my FBN file as it is updated as GWCHECK is processing). I would then read the RFL file and update the new FBK file. At the end of this process, I should have a new FBK file which would be copied into a new DB file making both of these files in sync. My RFL should be purged/reduced/recreated as all of the messages have been incorporated into the FBK file. I don't think it is my RFL file because the error happens immediately. I would think that the 8201 would not happen immediately if the problem were the RFL file. It would happen at the end of the process when it was trying to empty the file. I do have an FBO file. This file is dated 1/1/2004. Maybe gwcheck it trying to purge this file & is getting the 8201 & when it can't, it creates the FBN file. I will try to rename this file & then rerun the gwcheck analyze/fix for my po. This file happens to have delete inhibit & purge immediate attributes set. I have cleared them will try again. Will update after the result.