I have one instance of Minecraft server running as one user on Linux, and when I try to run a test instance as another user, I get a permission issue for a directory outside of my Minecraft instance tree:

Caused by: java.io.FileNotFoundException: /tmp/mc_libs/0/calc-0.2.jar (Permission denied)
	at java.io.RandomAccessFile.open0(Native Method) ~[?:1.8.0_144]
	at java.io.RandomAccessFile.open(RandomAccessFile.java:316) ~[?:1.8.0_144]
	at java.io.RandomAccessFile.<init>(RandomAccessFile.java:243) ~[?:1.8.0_144]
	at openmods.utils.io.Locks.tryExclusiveLock(Locks.java:101) ~[Locks.class:?]
	at openmods.core.BundledJarUnpacker.findLockableFile(BundledJarUnpacker.java:35) ~[OpenModsLib-1.11.2-0.11.2.jar:?]
	at openmods.core.BundledJarUnpacker.setup(BundledJarUnpacker.java:63) ~[OpenModsLib-1.11.2-0.11.2.jar:?]
	at openmods.core.OpenModsHook.injectData(OpenModsHook.java:15) ~[OpenModsLib-1.11.2-0.11.2.jar:?]
	at net.minecraftforge.fml.relauncher.CoreModManager$FMLPluginWrapper.injectIntoClassLoader(CoreModManager.java:165) ~[forge-1.11.2-13.20.1.2454-universal.jar:?]
	... 8 more

If I remove /tmp/mc_libs (as the current user) and then re-run this modpack (https://minecraft.curseforge.com/projects/nst-unofficial-exploration) as the new user, this error goes away.

Someone else ran across this and posted this log: https://pastebin.com/h6XN3hLk

Forge Mod Loader: 1.11.2-13.20.1.2454
OpenModsLib: 1.11.2-0.11.2

Thank you for the quick response @boq . :) If I understand the commit correctly, you're just now reporting what the issue is when we run across it, but not fixing the issue, correct?

e.g.
User1 runs a Minecraft server and OpenModsLib creates/writes to /tmp/mc_libs/0/calc.jar
User2 tries to run a Minecraft server and OpenModsLib fails, but now has a logged error of the reason, because they cannot write to /tmp/mc_libs/0/calc.jar

Fixing for User2 breaks for User1, unless we allow both to write to /tmp/mc_libs/ and sub-directories. Why is OpenModsLib even writing outside of the server directory? Shouldn't all writes be underneath the Minecraft server directory to avoid such conflicts?

No, I'm ignoring this exception, since throwing this exact one is documented behaviour (some other error occurs while opening or creating the file - includes permissions). In this case game will pick different directory for extracting this file and retry.

Now, as for "why": game needs to extract library somewhere. I've decided to always create or reuse unique file exclusively for every running instance (possibly started multiple times from the same directory) to prevent race conditions. Since Minecraft already creates files in /tmp (notice: jna/jna* and jansi*, or at least this is the case for Windows), I selected this location for my temporary files.

Awesome, thank you for the explanation. :) I haven't written Java code and didn't realize the failure exception would cause it to try again with a new name.

It doesn't. This commit just ignores exception and lets control flow return normally here.

It's up to caller to handle that and retry.