New errors creating log files on long-running server

DE wrote:
> Michael Bell wrote:
>> DE wrote:
>>> I have a GW7.0.3 - Netware 6.5SP7 - server which had been running
>>> just fine until today, which is also the DHCP server for the (remote)
>>> site. The initial error today was "Cannot update NDS against an entry
>>> within subnet container: dhcp_subnet.Portland.Air." Users were unable
>>> to log in this morning & the primary server seemed hung, but
>>> restarting the primary server (not the GW/DHCP server) seemed to
>>> resolve things, and I thought perhaps just communications had been
>>> lost between the servers & was resolved.
>>>
>>> But now the POA and the MTA are showing errors creating the log
>>> files. Things seem to be running otherwise, and there are no errors
>>> in the error log & nothing flagged in the health log, but on the POA
>>> I get "Error creating log file" and then "Disk logging turned off",
>>> and on the MTA I get "LOG: Logging: File Create Error - Disk Logging
>>> Turned Off".
>>>
>>> Messages are being routed properly, and no disk errors are showing on
>>> the server, so I'm a bit at a loss as to where to start with this nor
>>> why the error has come up. Restarting the POA and MTA does not help,
>>> and I do plan to restart the server when someone is on-site tomorrow,
>>> but I'm not sure how this will help at all.
>>>
>>> Any insights or suggestions? The server got new memory about 8 days
>>> ago but was running without errors since, until this morning.
>>>
>>> Thanks.
>> If I had to guess, both issues are consistent with running out of disk
>> space or IO error errors.
>
>
> Yeah, but there's plenty of disk space, the only oddity I note (which
> was not changed, nor were any service packs added or anything else done
> to explicitly change GW configurations) is that when I go into C1, I see
> the log file for the MTA set as being to
> \\Air_tree\.AIRP_COMM_SYS2.Portland.Air\APPS\GRPWI SE\AIRP_DOM
> instead of
> \\AIRP_COMM\SYS2\APPS\GRPWISE\AIRP_DOM
>
> As I'm not the one who set this system up, I have no idea whether it
> always read that way or somehow changed when the NDS error above occurred.
>
> I'm also sure that rights & such have not changed on the disk, and
> there's no hint of any disk issues at all in the logs.
>
> I'm going to try changing it to the UNC-style path I've written here;
> can't make it any worse, can it??
>
> Thanks.

And, in fact, that did the trick -- created a log folder under the
domain folder, since I prefer to have logs go in their own spot, and
then pointed the MTA log to that UNC path in C1 -- and restarted the
MTA, and it re-enabled disk logging again but to the new sub-folder (aka
sub-directory).

I suspect that the path wasn't originally set as shown but somehow got
changed when the above error occurred w/NDS, or else something I can't
see has really gotten broken, but IAC everything certainly appears to be
working now.