B4J Question [jServer] Occasional "Access denied" on /log/ folder requestlog files


Active Member
Licensed User
Longtime User
Hello folks
I have this odd phenomenon with jServer/jetty in which the server startup occasionally fails with a messages that the log folder/files are inaccessible.
The way to get it working again is to delete the folder entirely.
Now unfortunately it is very sporadic and I accidently closed the log output before I saved it and then decided to ask on the forums.
It is a bit annoying in production and I wondered if I could turn of these requestlogs entirely.
In general it just says something like

2023-04-20 08:28:21.295:INFO :eek:ejs.RequestLogWriter:main: Opened C:\KBL\UnifiedReporting\logs\b4j-2023_04_20.request.log

But with "Access Denied" at the end.

The java(11) -jar process is running as a windows service installed with nssm. It usually happens when my program crashes for a reason and gets restarted, but it also happens if I try it for debugging manually, so I don't suspect the "old process" blocking file access while a new one is already spawned.
I hope this helps, sorry for not being able to supply actual log output for this one right now.

I had a similar issue with jOkHttpUtils2 where it was creating a weird folder in the temp dir with a number as a name for every download job and at some point needed to be removed to be accessible again.



Active Member
Licensed User
Longtime User
I've never encountered such issue though my servers run mostly on Linux. You cannot disable the logs. You can however change Server.LogsFileFolder.

Does the server crash or stop when the folder is inaccessible?
Sorry for replying so late, notification mails of this forum apparently ended up in my spam...

Yes, it crashes on a repeated startup, but never while running.
Usually my application crashes for some other reason and when it restarts (most of my servers run as a windows service) it goes into a crash loop because the folder is inaccessible.

I have had this, check your folder permissions, and user account permissions.

I will try next time as it is hard to reproduce the issue. Does the crash somehow scramble access permissions? Is it connected to the windows service host running the whole thing with System privileges?
Upvote 0