MineOS Odd Button/Pressureplate behavior after update to 1.17

See issue I posted here as well: https://bugs.mojang.com/browse/MC-228061

I started with the Mojang forum until I narrowed it down to a potential MineOS issue – everything works if I run the server without using MineOS.

The issue:
After updating to the 1.17 JAR, buttons and pressure plates stay depressed when pressed.

impulse/unconditional/needs redstone command blocks with tp @p ... and give @p ... also do nothing, even when levers are pressed.

The server also has to be killed hard with a kill -9 on java’s process ID.


  1. start server from MineOS webUI or with mineos_console.js (the server starts just fine with either)
  2. place command block
  3. enter command tp @p 1 1 1
  4. place button or pressure plate on adjacent block
  5. press button
  6. attempt to stop server with either webUI or mineos_console.js

Expected Result
player who pressed button or pressure plate gets teleported to x:1 y:1 z:1
server stops gracefully when attempted

Actual Result
Nothing happens to player and the button, or pressure plate stays depressed, even though you hear the button-click sound
When you bring up text console with either t or /, the last output that shows is Command set: tp @p 1 1 1

Attempts to stop the server gracefully, either with webUI or mineos_console.js fail and the server can only be stopped by issuing a kill -9 <java PID> from the servers bash.

Server OS: CentOS Linux release 8.4.2105
JAVA: java version “16.0.1” 2021-04-20
Minecraft Version: minecraft_server.1.17.jar
PC OS: Linux Mint 20.1
JAVA: openjdk version “11.0.11” 2021-04-20
Launcher: 2.2.3103 Minecraft: 1.17

The reason I think it’s MineOS
Upon further testing, I found that this issue only occurs when I run the server with MineOS (git commit b2ce276). When I run manually with the following, everything works as expected:

java -Xmx4096M -Xms4096M -server -jar minecraft_server.1.17.jar nogui

The only difference between when MineOS starts the server, and when you do it manually, is that MineOS starts the server wrapped in a sceen session.

Try to start your server using the screen utility:

screen java -Xmx4096M -Xms4096M -server -jar minecraft_server.1.17.jar nogui

If your error do not pop up while running this add the following:

screen  -m -d  java -Xmx4096M -Xms4096M -server -jar minecraft_server.1.17.jar nogui

This starts your server just as mineos would. To enter the screen session:

screen -ls

(lists all screen sessions active)

screen -r PID/Sessionname

To connect to a running screen session

I suspect the new server jar may have trouble running as a screen service in the background, not being in the foreground like it is when you start up manually without screen.

This is then one of the following:

  • a java bug that must be updated in the java binaries
  • a screen bug that must be updated by the screen team
  • a minecraft bug that Mojang needs to fix.

This was exactly what I needed – to see what the issue really was – A permissions issue.

The first time I ran Minecraft on the new 1.17 jar was as root (the elevated, or admin user on linux/unix systems) from the command line, so new entities were created with root as the owner. The screen command itself isn’t what really made the difference, but in the spirit of running it as the GUI would, I logged into the command line as the user that owns the server for the first time while troubleshooting this and started it with your command. The result was a flood of permission errors for entity files.

Essentially, every time I ran it in the GUI before, this was the user it was running the new JAR as. Java was failing to interact with certain entities that were new, and owned by root because that user didn’t have the permission. When I tried to shut the server down, too, as that user, it couldn’t write to those files either. All I had to do from there was search for files in the server directory that were owned by root and change ownership to that user.

root@minecraft01 Creative_council # find . -uid 0 -exec chown that_user: {} +

So simple, even I overlooked it. Needless to say, it works as expected now. This issue is resolved.

1 Like