Could not lock user prefs unix error code 2

@Chinthor , since I have several images in this repo I just wanted to double check you’re trying the minecraft-server, right?

…and tell me a little more about the procedure that corresponded with the problem starting.

Thanks for the reply. Yes, it is the minecraft-server image. I’ve been trying to improve the main server I am running and eliminate some problems. Thought I’d duplicate the server and the world and then experiment on the copy. I copied the contents of the working directory to another folder, then used the same command as before to make a new container. This server will run, but gets the above errors. I get no errors if I make a «vanilla» forge server. But now if I try to dump mod files into a virgin container, the same errors come back.

Unrelated, I’m having issues between my server world and my own client. This despite installing a fresh instance and copying the mods and configs directly from the server itself. My fault for changing things to hastily, but I can’t find where I done goofed. My friends can play but I can’t. Frustrating. I’d create a completely fresh world and start testing from there, except for the Unix error business. This combination of errors that refuse to be analyzed is giving me a migraine.

Currently working on rebuilding A) a cloned server that works and can be tested upon, and B) my own client to match. Each done one mod at a time. I’ll repost if I find where the problem creeps in, but any thoughts you have would be great.

Well, that was quick. Kinda. Found the mod with the problem. It begins with this line:
[bspkrsCore]: Initializing ModVersionChecker for mod bspkrsCore

And then tries to do this:
java.util.prefs.FileSystemPreferences$1 run

Followed by warnings that the file it wants to create cannot be created. Followed by the above errors every half minute. The problem is, this mod file is copied directly from a server directory that is working with no such errors. How can two containers made by the same user and running the same image run into different permissions problems? Especially if, as my googling suggests, it is caused when a user or user agent doesn’t have a /home directory. If I’m reading the documentation right, that user would be «minecraft» right? With the same image in both containers, both should have the same issue. Grrrr.

Sorry to vent. I’m sure you understand such frustration. I’m learning a lot, but having the same inputs give me different outputs is not conducive to learning. Only to head pain.

I was just earlier today struggling with directory permissions with non-root container users…so, yeah, I totally understand.

I think you’re onto something with the /home directory permissions. The /data attach point is being managed by the startup script but I’ll have to see if I do anything with /home.

Thanks again. I’ll also take this to the author of that mod. At the very least, there’s a chance that he doesn’t need to be writing to anyone’s /home directory. But since I’m completely new to the workings of docker, you’d be the expert on why this is happening so selectively. Cheers.

Since my day job is Java development I happen to know that the preferences system on UNIXy systems uses the home directory structure for its backing store. (On Windows it uses the registry.)

So…if the mod developer is using Java preferences then that’s legit. I should be able to look at this more tonight.

Ooooh! Nice. So, will I have to edit the image? Rebuild one using your files? Or does this post indicate that you’ve stuck that in and I just have to delete my image and download again. Still new. Still learning.

FYI, ran into another bug. Will post as separate issue.

The approach I use for ongoing development will probably work for you too:

• Clone the dockerfiles repo (creating the fork first and cloning that is easier knowing that you’ll aim for a pull request)
• Go into the minecraft-server directory and make your tweaks
• Run docker build -t mc . to build an image with the current directory’s context and tag that image as «mc» (or whatever you want)
• Now you can start a new container with your built image by replacing itzg/minecraft-server with mc

Nice. Problem solution and a learning opportunity. Perfect.

Thanks again for all the help.

And thank you.

BTW, if you need to debug the script execution you can add an --entrypoint=/bin/sh along with -it to drop into an interactive shell. Sometimes I’ll even tweak the script inside the container, run /start, tweak, repeat and then just bring the changes out to the checked out copy.

Did you get a chance to look at this? I took a quick look just now and yep, the /home/minecraft directory doesn’t even exist:

# cd ~minecraft
/bin/sh: 8: cd: can't cd to /home/minecraft

I went ahead and merged the fix and pushed to Hub. Its image ID is sha256:2ee91313cb28cb2037b32dad283f082b9bbff4860c521f6b884b01f84a01ddc9. Please give that a try @Chinthor and feel free to re-open the issue if you’re still seeing the problem.