MineOS cannot manage manually-launched servers. Or at least, it cannot manage any servers that are not contained within a screen instance that follows the pattern “mc-[servername]”.
Since you launched it without screen, it’s invisible to MineOS.
So it’s a bit of a misnomer to say that it is down, but as far as the webui is concerned, it’s fairly accurate. Of course, if you tried running it also from the webui, then you’d just get the error saying it’s trying to run two servers on the same port.
That said, I have no idea what synology is, but FreeNAS has a long-standing issue of the Java version causing issues (often the JDK isn’t up to date, etc.).
Since you’ve provided the logs, we can see that MineOS has gone as far as accepting the ‘start’ command, so the best way to trace it is:
- create a new server
- go through all the steps up to ‘start’
- Attempt to start it.
- Go to the server’s file directory:
- is the eula present, and do the contents say it is accepted? (checking that that part worked)
- did it generate logs, e.g., logs/latest.log
If there are no logs generated, the webui is likely having a Java issue.
But this time, it might be that the environmental variables for the user cannot find Java, which is different from the exact same user being able to run it manually (because interactive login prompts source variables that won’t happen in non-login prompts). This is actually only my second guess, while my best guess is:
The issue might be something related to the GID/UID ownership of the files. I don’t do much with containerization, but it’s very possible this is related, since
This might indicate that MineOS definitely sees these files get created, but cannot access them, as the webui’s user UID/GID may not actually match the ownership of the files on the containerized FS.