I have researched this now recurring issue; and no root cause or permanent fix has been provided. If there HAS been a valid explanation and/or workaround, with instructions, I haven't seen it.

Problem Statement:
RCON is accessed from the local host by the Systemd agent, to perform graceful restarts and scheduled activities from a CRONTAB. There are also other tools which point to this host, and other hosts, for remote management to do its thing. Many of which are non-user-level, system-agents which access the RCON for various things.

These are required for situations such as graceful restart from failure, failure-detection hup for the server shell scripts, and also for triggering broadcasts for other maintenance and management activities from the Host these VMs run on. (many of which are non-server specific, so it doesn't make sense to try and do this custom for each instance; its much more scalable to do it for all instances from a cron or other external trigger, and send it out over RCON which is fast, quiet and easy to script against.

However,
Since updating to "forgeessentials-1.12.2-12.3.88-server.jar" RCON is broken from system level. I am ONLY using FE for a single Area and user commands for that one area. So, I don't need to set expansive permissions or default groups. I already have those needs fulfilled.

There should be ZERO reason why RCON should need to go through FEs permissions tree to execute system commands.

System doesn't "log in" as a named user, it's system which by definition should have highest privileges. So, FE is intercepting system level commands destined for server, and preventing them from being executed.

This is an issue for new server automations, because there are as of yet no named users in cache, so I can't even OP a user to go in and tweak perms. This is an issue. It's breaking several extremely simple solutions for remote server maintenance at my CoLo; and it needs to be fixed.

The RCON command(s) for things like STOP, OP, etc. should not be intercepted by FE; they are minimally necessary to return from failure and maintain the box. I can see no logical circumstance where your mod would need to stand in the way of console, or remote agent hitting the console from sending in a stop command to the box or for OP'ing an online admin who requests a temporary OP for some task through a ticket.

(yes, I could scribble up an ops.json for a sample user, and include it in my base image but that is a poor security practice, and isn't tenable in the environment I host from since i can't predict which user or UUID I'll need to OP...so, that's not a fix it's a band-aid). I also can't be bothered to log in as a user, to fix something that I invested time in automating.

As for researching the problem further; I have read all of what is previously documented on this issue (not a lot).

So, with respect, I don't need a recommendation for an alternate RCON agent that runs commands through an FE process or via the FE Perms tree. I need to know how to prevent FE from intercepting system level commands via RCON, so that my tried and true crons and maintenance automations can do their job; same as they have always done.

Thanks very much.

Steps to reproduce.

Spin up a Forge 2854 server, or a modpack such as PO3.
Add forgeessentials-1.12.2-12.3.88-server.jar to the Mods folder
Set an RCON port and PW in the server.properties
Start it up.
Edit the Eula.txt from False to =True
Restart the Server again
RCON in from command line
or
Trigger a restart from a method such as //systemctl restart po3_xyz.service\
view service status and see "You do not have permission to use this command"

Or RCON in directly and see the following:::
\--\
Logged in. Type "Q" to quit!

list
There are 0/10 players online:
stop
You do not have permission to use this command

So, now, with no users logged in, and no ability to assign someone OP, this server is now useless to me because my provisioning automation is completely broken by FE. So I begrudgingly paste a good users UUID into the ops.json, login and do what i need to do. Which isn't sustainable.

Either this gets fixed with a better default configuration, or I guess I will reluctantly search for an alternative.

What build were you on before? Nothing changed between build 88 and build 87 in relation to RCon!

Also, please ensure you are on the latest Jenkins version as per our rules on bug reports. Currently, that is build 91.

The RCON ident by default has all permissions allowed. However, I noticed that in the older builds, we were not setting the ident correctly for the vanilla RCon when using the forge permission api. This has been fixed in build 93.