Server ownership

Hopefully this is the correct category. I am running MineOS on Ubuntu in a VM hosted on another Ubuntu machine.On my VM, the admin user/group is minecraft/minecraft that is supposed to be used for creating minecraft servers. The first server I created has as server owner: minecraft, group owner: minecraft. The second server has as server owner: user1 and group owner: minecraft. The second server is causing problems now by opening up a gnu screen session pointing to the console, and when I close that session the server stops (but is reported as running with -1/10 users logged in) and is effectively hung until I force close the server. How do I change the owner back to minecraft without losing the world?

Please forgive the rambling, and let me know if something is not clear. Awaiting assistance with bated breath. Thanks

-Joel

I’ve noticed on my server when it is still starting up that the user count is -1 / 10 (odd that we have the same user limit but w/e).

Then once the server has completed its startup the count changes to 0 / 10.

Now you said you have user1 as the owner, and the group owner as minecraft.

The default configuration is that Root is the owner of everything, and that MC is a elevated user.

I’d check your user1 and minecraft accounts against your other working server, and duplicate the permissions accordingly.

I have not installed or used Turnkey MineOS, so I cannot compare. On my system, root owns / has access to everything. I created an account/group called minecraft to administer MineOS, then a normal user account to create/administer individual servers in MineOS. The difference between the two servers is that minecraft is the owner of Xanadu, and user1 is the owner of Utopia. Both servers are in the minecraft group. User1 also runs screen, so when Utopia starts up it launches a new screen session and creates a window where Utopia launches from. This behavior is not seen with Xanadu. This also means that user1 cannot see restore points for Xanadu but can see them for Utopia while minecraft can see Xanadu’s restore points but not Utopia’s. I have to use minecraft to configure profiles as user1 does not have permission to do so.

To me this sounds as if your user permissions are mixed up.

Just because you don’t use MineOS Turnkey doesn’t mean that you can’t compare the permission levels from one account (jot them down into notepad) and then compare them against your other account.

You said “user1 does not have permission to do so”

That right there to me, means you have to confirm and properly configure the permissions for User1.

Both users have been set up the same with user1 also being in the minecraft group. In the servers folder, the permissions are 664 (-rw-rw-r–) for the respective owners. The Xanadu folder structure is owned by minecraft/minecraft and the Utopia folder structure is owned by user1/minecraft. Is ownership as simple as changing user1 to minecraft? The permissions of the backup and archive folders were created with the same permissions, however the Utopia folder in each has the permissions set to user1/user1.

The user permissions need to be matching (from what I can tell from your post).

You can change owner with chown (use chown --help so you know the exact verbage)

Based on what your saying it sounds like you need to set Xanadu folder structure from user1/minecraft to minecraft/minecraft.

I am able to reproduce this issue and I have written up a fix I plan on deploying tomorrow. It appears that all screen instances are started with the users primary gid rather than the chosen (non-primary) gid and this is causing the problem.

Incidentally, in allllllllll the time of this iteration of the MineOS webui, this apparently went unnoticed!

I’ll do more testing tomorrow on my buildbox and should all go well I’ll make the fix live in the master branch.

chown -R user1:minecraft /var/games/minecraft/{backup,servers,archive}/servername

You can sub out user1 with minecraft, or any user; there isn’t any risk of world loss with it.

Incidentally, this line should actually fix it so that you can see backups and archives, but the shared screen thing will have to wait for the next commits.

Thanks Jarli and hexparrot. Good to know I was able to help with the screen issue. I have already changed ownership of the folders to minecraft:minecraft, and I can see that the ownership changed it the gui and screen no longer launches an extra session. I can still see the archives for both servers, but now that the ownership has changed user1 cannot see any of the backups for Utopia. The solution last time I brought this up was to log in as minecraft and then I can manage backups.

Thanks for your help. I am really liking MineOS!

Alright, so here’s where we stand: let’s reiterate the issues brought up in this thread:

Originally I thought the issue here was that each time a backup was made it was made with the user’s primary group. So a user “minecraft:minecraft” would create servers and processes owned by “minecraft:minecraft”.

Secondly, a user “user1:user1” with supplementary group “minecraftshould have made a server/process with “user1:minecraft” but instead made it with “user1:user1”.

This second issue was fixed in a commit I made today. However, it doesn’t solve the issue for two new, different reasons.

  1. It turns out that the backup mechanism rdiff-backup makes all backups and increment information readable with permissions 600 (read and write for owner, none for everybody else). This actually is why backups appear absent except for the original server owner.

  2. screens have their own authorization mechanism. While the screen itself is being started with the proper user UID and the proper group GID, screen itself ignores this process ownership and expects sharing screens to be done explicitly through commands like : multiuser on, : acladd user1.

Thus the nice system that Linux provides in terms of groups and membership is ignored and would have to be redundantly repeated for each user in the group, for each server that gets started.

While both of these problems have attainable solutions, they also are a lot more complicated than initially hoped, so it also will have to go through more rigorous testing channels to make sure I’m not doing something really dumb in using screen ACL. Understand that since this web-ui’s inception, this is apparently the first time it’s been brought to my attention of this issue, so making large design changes that positively affects so few people must be done with care.

I’ll continue to look at this in a new development branch and when I feel comfy it’s done right, I’ll reach out and let you guys know how it turned out.

That sounds like what is going on. thank you for your hard work hexparrot!